On Wed, Apr 10, 2013 at 09:52:03PM +0200, Fredrik Gustafsson wrote: > I think that with a mature product as mutt is, we should always have a > stable version, always "be ready to ship".
I more or less agree... the 1.5.x line IMO basically IS the defacto
stable branch now:
- There hasn't been an official "stable" release (not counting
patch-level releases in the 1.4 line) in NINE YEARS.
- The last 1.5.x release was ~2.5 years ago!
How much more stable could you possibly be, without being considered
ABANDONED?
I'm rather inclined to think that what we have now should be treated
as stable, and released as such... whether that be 1.5.21, or some
minimally cleaned up version of head. This is not so unreasonable; If
you look at David's statistics, you'll see that the amount of
development that's been committed in the 1.5 line is huge. There
aren't (to my knowledge) any serious showstoppers in the 1.6 bug list
that are preventing people from using Mutt in a stable fashion for
day-to-day use. So, what's the hold-up?
I'm somewhat inclined to think that the "pretty unobtainable" list of
outstanding issues in the 1.6 line should be considered a major
release, i.e. 2.0. Although, to be honest, I'm also somewhat inclined
to think that release numbers are extremely arbitrary and mostly
uninteresting.
But, if you want to stick with the "odd is devel, even is stable"
scheme, then I think roughly this is what should happen, essentially
right now:
- Something like head should be released as 1.6
- The less "unobtainable" outstanding issues identified for 1.6
should be reassigned to 1.7
- The more unobtainable outstanding issues in 1.6 should be
relegated to 2.0
- Releases (of the stable variety) should generally be kept smaller,
have specific goals assigned to them, and be attempted at least
annually
- There should be a clear statement, in some form or other, what is
intended to be done in the next minor release, the next major
release, and some broad statements about what the goal is for
beyond that. Except for the last (or perhaps even the last), this
can very well take the form of a bug list. However if so, bugs
should be opened that identify the overall main goals of the
release to which they're assigned. Where appropriate, all other
bugs should be identified as dependencies of those larger bugs.
And then, if someone were feeling really ambitious:
- Ideally, larger bits (like the planned new mail overhaul) should
have a doc that describes how they should work overall, as well as
describing the data structures and interfaces of any libraries
etc. required to make it happen. This would help identify units
of coding that can be broken down and assigned to people willing
to do that work.
I'd also suggest that committers should never commit their own code;
they should be peer reviewed and (ideally) tested by someone else, and
committed by that person (or even some other third person). This
isn't strictly required, and may be impractical.
> I like the model used by the git project:
> https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt
Glanced at this; seems fine to me, but what matters most is who is
going to be the primary maintainer, and what works for them. I think
they should decide on the process. But I think there should BE a
process, even if it's a relatively informal one... The point, I
think, is that people who want to contribute should not feel unwelcome
to do so; they should have a clear indication when their contributions
are being attended to and when they are not; and they should know who
to poke at when the bad thing happens. Everything else is details
that probably won't really ever be strictly enforced.
> A testsuite would make us be able to track regressions faster and
> therefore be able to lower the time between releases (don't have to wait
> for people testing that old features still work...).
I think everyone sees the merit of this, but it is a lot of work, and
as pointed out by (I believe it was) David, it's hard to do. I'm not
saying it should be dropped as impractical; I'm just saying there's
going to be a lot more to making it happen than just saying we should
have it. Like, finding someone who wants to do it. BUT, it's a fine
thing to add to the list.
> As I see it mutt is a vital part of many peoples daily worklife and an
> improved mutt would be able to speed up other work. Maybe there's
> companies that actually are willing to sponsor mutt-development? For
> example with donating coding time...
As with many OSS projects, finding people willing to write code is not
that hard. Finding people to write the specific code you (the
maintainer) wants written is a bit harder, but mostly still not that
hard. Finding people with the time, desire, and the skill to manage
the process AND to set the tone of future development, as a real
leader would, is what's hard. This, I think, is what sets the
successful major OSS projects apart from the rest: guys like Linus and
Guido who have a vision, and the motivation to drive that vision.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgpxllS6INkrR.pgp
Description: PGP signature
