Re: [PATCH v2] make send-hooks work for batch mode
Brendan Cully wrote: [Thu Aug 14 2008, 06:12:36PM EDT]
> 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 :)
Okay, you're right. :-)
> > 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.
This makes sense in theory. In practice the distros have been
providing 1.5 for a long time, because it's stable enough and
it's taken so long to release 1.6. So the theory is a bit
meaningless at the moment.
I'm not against the concept of unstable/stable branches, but
it doesn't seem like it's actually working, so it's hard to
imagine how things are going to change if we persist with this
approach after 1.6 is released.
Part of the reason I'd question the unstable/stable split is
that we have mercurial now. What's the point of unstable
releases when it's so easy to fetch and build the tree? Maybe
the mercurial tree meets the unstable requirement and releases
could always be *stable* now. That might put some momentum
behind the process... no development releases to ease the
pressure of making a stable release.
> > None of this is intended to be a diatribe against the mutt
> > maintainers. I have the utmost respect for the careful way they
> > maintain the tree. I'd be surprised if they don't share my
> > frustration with the current development model, though they might
> > have better ideas on how to fix it.
>
> I don't know. One thing I want to try after 1.6 is out is to be a bit
> more liberal about allowing commit access to the main repo -- we're
> always short of manpower.
Maybe this would help, hard to tell. It's not very hard
presently for interested contributors to submit patches to the
list or to trac. It seems to be hard to find people interested
in debugging.
> I definitely also agree that in the future
> the delta between major releases needs to be a lot shorter. Less code
> churn also means less time to stabilize, in general. One of the
> reasons this release is taking a long time to freeze (aside from the
> fact that we devs only do proper hacking sporadically), is that it has
> changed so much from the last stable version. It's a bit of a vicious
> circle.
*nod*
Aron