On Sun, Nov 30, 2008 at 11:22:25PM +0000, Lee Baylis wrote: > In the end, I opted for an approach which was closest to option 3: This sounds good. > I am doing a couple of final bug-fixes to this overallocation_prohibited > release, and should be able to send patches pending approval/comments on > the resource dialog patch I sent last week, which ties into the final > overload-checking algorithm and is a source of overload in itself (item 7 > above). I sent some comments on the patch earlier. I have also noticed some indentation inconsistencies in the patches. Do you have your indentation set to tabs? vim & emacs should be able to use the mode lines at the top. If you could also send the changes to multiple files in one patch, that would be easier for me. I was wondering, how do you plan to proceed from the overallocation-prohibited version? What kind of user interaction with the GUI would we eventually have? Now I was thinking on how to handle integration of your (future) changes into planner. There are disadvantages to each approach I can come up with: committing to trunk: - if it takes a long time to finish, it could be in the way for in-between releases - I wouldn't like to litter the code with ifdefs, especially in cases where you would rewrite large pieces of old code committing to a branch: - subversion < 1.5 doesn't have merge tracking. I haven't been able to figure out if Gnome's running 1.5 yet. distributed version control: - Gnome doesn't offer it - I've never worked with it (though I've always wanted to try Git) =) Regards, Maurice. -- Maurice van der Pot Gentoo Linux Developer griffon26 gentoo org http://www.gentoo.org Gnome Planner Developer griffon26 kfk4ever com http://live.gnome.org/Planner
Attachment:
pgpSD7w30Yo4B.pgp
Description: PGP signature