David Kastrup wrote Tuesday, July 10, 2012 12:21 PM >> tdaniels...@gmail.com: Repeat Dots and >> Staff Size in 2.15.41 >> http://code.google.com/p/lilypond/issues/detail?id=2648 >> >> This bug first appeared in 2.15.40, so is a critical regression. > > I mean, we have too few categories for regressions. I can see the > following: > > a) Precludes work (patchy/staging catches most of those) > b) Precludes releases > c) Precludes a stable release > d) An eventual fix should be backported to last stable > > My personal opinion is that we overuse category c) because we don't want > to think about d). It's nice aiming for a stable release that will > never need a single backport or regression fix in its life time.
I would have no problem with making a new stable release with the expectation that it _might_ contain regressions, but it would be wrong to make a stable release containing _known_ regressions. After all, that is the point of making release condidates, isn't it - to identify new bugs so they can be fixed before the stable is released? > But that nicety pales against the garishness of not giving the users > anything ever. I agree with your general sentiment - we need to find a way of controlling the introduction of new bugs as a new stable become due. We have the technology to identify the commits that introduce bugs fairly easily. Perhaps once the first release candidate is made we simply say any commit that introduced a critical regression bug after that is simply reverted, and the originator invited to resubmit after the next stable is released. Trevor _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
