Werner LEMBERG <w...@gnu.org> writes: >> 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. > > +1
Well, "next few months" is relative. I just put out the announcement because I feel we should now stop accumulating stuff that will require half a year to reach a stable state. We need to focus on dealing with what we have in the queue right now rather than heaving new things into master that will be beneficial to end users only in a long time frame. There has been a lot of stuff where I had the feeling "if we dump this into our code now, there won't be a chance for 2.18 in the next year". And there is a lot of code particular in connection with the skyline stuff where I don't see a coherent interface and no coherent strategy or desire to arrive at one. For a stable release, we need to focus on _reducing_ the complexity of what users are confronted with, not increasing it. And I see an alarming tendency to squeeze a few more user knobs in when their operation is in conflict with existing one and destabilizing not just the code base itself but also the consistency of how a user may use them. And i am really pissed at "oh, this can't be done right without doing x, so let us do it anyway, and if you are bothered about this being broken, file an issue about x and hope that somebody, sometime might address this at which time everything will stop working again and will require a redesign that we provided a hackish pseudo-interface for". That's not going to lead to a "stable" release. If we figure out the foundations are unsound, the solution is not to build a wobbly building on top, but to get the foundations fixed. And since it is clear that we need to get 2.18 out in some point of time, we need to change our focus from destabilizing work to stabilizing one. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
