Re: [PATCH v2] make send-hooks work for batch mode
On Wednesday, 13 August 2008 at 11:28, Aron Griffis wrote:
> Kyle Wheeler wrote: [Wed Aug 13 2008, 10:52:29AM EDT]
> > Well, I imagine anyone currently using mutt in batch mode on a regular
> > basis (e.g. with cron) already has a working setup, and enabling hooks
> > by default has the potential at least to break those setups.
>
> Well... this *is* mutt-1.5.x, the devel series, but considering
> that the distros are providing 1.5, you could make an argument
> for waiting for 1.7 to apply this patch.
>
> On the other hand, mutt releases are so miserably far apart that
> I don't want to wait for 1.7 for anything. I'm even considering
> re-proposing my sendbox patch prior to 1.6 because the thought of
> waiting for 1.7 is so depressing. I don't want to wait a decade
> for these features in distros (and that doesn't seem like an
> unrealistic estimate).
>
> 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 :)
> 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.
> 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. 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.
> > Perhaps it'd be better to have a flag for enabling hooks?
>
> Really rather not.
agreed here. Either they're safe (in terms of not causing mutt to
crash, rather than not surprising the grizzled mutt veteran who
expected his settings to be ignored in batch mode), or they're
not. Users that want different settings for batch mode could use a
different muttrc for that case.