I'm not sure what I think about patch review on the trunk. One one hand the mailer seems to get less functional daily, but on the other I'm not sure we can afford to have large but well tested patches get bogged down by review. Right before you sent this I committed a very large change to the gtkhtml table parsing code that I've been working on bit by bit for months that would have been a real time sink for Radek to review. I guess I'm OK either way but I suspect that people will end up approving patches simply because they don't have time to do anything else.
I agree wholeheartedly that we need to pin down what our 2.0 plans are very quickly or things will tumble out of control. Lets start by going over the lists the maintainers have brought up and winnowing them down to something that that we can expect to actually achieve in the next cycle. As for discussing things on this list, for the time being I'm planning on working on refactoring gtkhtml's html parser more to make it more flexible and easier to maintain. I may also spend some time on the stream interfaces to allow specific mime type handling and improve error reporting. I've already integrated some drawing changes into head that should improve redraw speed for editing and selection. There used to be several (at least four that I can think of off hand) redraw queues in gtkhtml that all had different endpoints. I merged all the endpoints so that the all redraws are handled by the gtk expose loop, but I left the queues in place for the time being. Hopefully I'll find some time go back and merge the redundant queues soon. that is all I can think of right now... --Larry On Thu, 2003-07-17 at 10:46, Ettore Perazzoli wrote: > Hello, > > there has been a bit of patching activity on HEAD. I am afraid we are > going to have trouble tracking down what is going on, especially given > that we don't have a plan in place yet. > > So, how about sending all the patches for the trunk in for review on > evolution-patches as well? > > We should also be discussing all the changes on this list, so we don't > unexpectedly break things and keep the quality of the trunk under > control and not cause regressions. > > The plans for 2.0 are already quite ambitious (with the possible UI > revamp and all), so we should try to be conservative on the changes we > are making to the trunk right now. > > Thoughts? > > -- Ettore > _______________________________________________ > evolution-hackers maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution-hackers _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
