On Friday, 15 August 2008 at 10:20, Rocco Rutte wrote: > Hi, > > * Brendan Cully wrote: >> On Wednesday, 13 August 2008 at 11:28, Aron Griffis wrote: > >>> IMHO mutt should ditch the stable/devel concept and make releases >>> similar to kernel.org. We're never going to fix all the >>> outstanding bugs for 1.6, so we should release it *now*. Make > >> I am also quite frustrated by the long delay in releasing 1.6. But I >> don't think the answer is to simply cut a release on day X. We have a >> list of about 40 blocking bugs. We will probably have to be a bit more >> ruthless about moving the milestones for some of them to 2.0, but we >> should consider each of the handful of bugs we know about before we >> release. If we decide we can live with a segfault or two, fine, but we >> should have made a decision :) > > Well, software has bugs per definition. :-) good point :) > When filtering out all bugs with patches attached the situation for 1.6 > doesn't look that bad. It looks even better when you ignore some bugs on > that list. yes. > Though I think we should fix as many bugs as possible for any kind of > release, I think we need to ignore some of the blocking ones and focus on > those we know we can fix in the very near future. agreed. > For example, I really doubt that we can find a working fix for #2995 or > #2956 for 1.6... even if we do it'll maybe involve bigger changes which > will require one or to more devel releases for people to test the > changes. For others like #2960 or #3039 I agree that they're annoying, > but they're more like "nice to have" fixes that should be fixed in the > near future, but not exactly _now_; at least to me they aren't important > enough to delay 1.6 even longer. I agree about the latter two. I'd like to leave the former on the list, but if we get to the point where we've fixed everything but these bugs I think I may change my mind :) >>> point releases (1.6.1 etc) to fix Really Bad Bugs, but otherwise >>> concentrate on 1.7. To simplify from kernel.org, stop >>> maintaining 1.6 as soon as 1.7 is released. > >> The fundamental problem is that it takes years between releases. I >> like having a stable/unstable branch so that we can be a bit more >> liberal about what we accept in unstable, and so that users can have a >> more sane idea about how to distinguish between feature releases and >> point releases. Linux is a bit confusing in this regard. > > I agree. And I think something is wrong when it takes years for releases. > > Stable/Unstable branches are nice for long-term development of new > features or bigger scale changes, but minor releases should be cut way > more often. The list of new features for 1.6 since 1.4 will be long > enough for at least one major version inbetween, IMHO. > > I have no sound numbers, but from user agent headers and IRC questions I > think in fact the 1.5.x series can be seen as a stable series already and > 1.4.x as historic only. Many changes in 1.5.x are quite stable, even > completely new features are made stable until the next point release or > are simply inclusions of patches known be stable. > > I think a better model for mutt development would be to go with > kernel.org style plus additional branches (repositories) for long-term > development of new features and refactoring that are merged back and > forth with the stable repo. That way we can develop and refactor in > parallel to bug fixes and everybody can either grab the branch he wants > or easily merge together a new branch that contains what he wants. Long-term development branches have two problems for mutt: 1. Not enough testing. Only hard-core mutters (mainly devs) are going to bother to play with them before they are merged. This means that releases after merges are inevitably going to have immature code. Linux suffers less from this because it has far more people in the "hard-core" pool. But even then linux goes through long rc releases, which I'm not crazy about. 2. There's no good means of signalling major compatibility changes to users. Linux isn't allowed to break ABI compatibility any more (I think it still does occasionally, but only in minor ways or for recently introduced features, and it still catches a lot of flak for it), so it doesn't need this kind of signal as much. It's still pretty annoying to try to figure out which 2.6 point release does what though. For mutt, imagine we take on Rado's huge variable renaming patch in 1.5.19 (in this hypothetical world where there's no unstable branch). Distros pick it up because it looks like a point release, and users get annoyed. People have been taught that between major releases things may need changing, and between point releases they won't. In short, I don't think linux's current version system is actually any better than the old one, and I don't really want to adopt it for mutt. I think starting with 1.6 we just have to cut major releases much more frequently. As I said before, the more we allow into the dev tree between major releases, the longer it takes to freeze the tree. Of course the current situation where most distros have given up on 1.4 does imply that I'm being too perfectionist about 1.6 :)
Attachment:
pgpatY0fCrgMR.pgp
Description: PGP signature