On 10 mars 2013, at 18:54, David Kastrup <d...@gnu.org> wrote: > "m...@mikesolomon.org" <m...@mikesolomon.org> writes: > >> On 10 mars 2013, at 18:32, David Kastrup <d...@gnu.org> wrote: >> >> Ok folks, it is this time of the year again: I am trying to make >> myself >> unpopular. >> >> There's a time of the year for that? >> >> It also means that commits of the "this really does nothing, but >> it >> prepares the ground for $xxx, and I don't know just where this is >> going, >> so quite a bit of it might be changed into something different >> yet" >> should happen in a branch. Actually, I am of the opinion that most >> of >> these changes should happen in a branch anyway. A "commit" implies >> commitment, and if one has taken a bad path, redoing it is much >> harder >> if the dead end has already ended in the main code base. >> >> As the world champion of this style of coding, I can conclusively say >> that I have no problem freezing all my experiments except the large >> translate_axis call patch, as I am sure that I know where its going >> and I almost have it wrapped up after many rounds of revision and >> review. > > What's it good for with regard to the current feature set? It does not > matter how good it is going to be for future tasks for the question of > whether one wants to see it in 2.18. What ends up in 2.18 is something > that people can expect to depend on in 2.20 as well. If it is > preparation for future work, it is unlikely that it will stay identical > once the future work is getting tackled.
I _completely_ agree with you that it is high time for 2.18. I also think it is important to not start big projects after a freeze date is announced. Given that the translate_axis patch is fresh on my and other's minds (i.e. the reviewers on Rietveld, the most recent being Keith), I'd rather push it in the next couple weeks and then fix any bugs in the next 4-6 weeks rather than waiting. Not only will it save time for me and reviewers, but it will also help me start doing the brainwork for the next big thing. Perfect timing, for me, would be like what we did for 2.16 in Waltorp. If I know when a freeze is arriving, I can coordinate my work so that, again, I can make my next large change ready right after the stable release comes out. So, to resume, I agree that a freeze is important. When the freeze kicks in, I'd rather that we say something like "no new big projects starting on date X will be part of 2.18" so that developers can plan out their next few months accordingly. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
