Re: [PATCH v2] make send-hooks work for batch mode
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. :-)
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.
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.
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.
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.
Rocco