On Mon, Oct 07, 2013 at 08:59:32AM +0200, jpac...@redhat.com wrote:
> >> Let me propose a fairly minor change in the development process.
> >>
> > you are proposing a fork on mutt's own infrastructure.
>
> Not at all. Look at many other projects. Even huge projects like Fedora
> ("not guaranteed to work in a production environment") and RHEL
> ("everything bundled is guaranteed to work together at the expense of
> providing old versions") are using this approach.
>
the difference is that these branches are maintained by the same people,
or at least that those maintaining the stable branch are *paid* to
actively cherry-pick from the unstable branch.
you proposed an open-for-all branch with very low quality criteria, and
basically maintaining the status quo of the master branch. but mutt
already has that anything-goes branch: it's called trac. when you make
an actual hg branch of it, it will be a fork, and master will be
abandoned for good.
> > nope, what it takes to make a project alive is a leader: somebody with
> > the competence and time to deliver results. and in the case of reviving
> > a stale project, it must also be somebody with the balls and inclination
> > to push beyond the incredible stop power (be it passive or active) found
> > in the existing (non-)maintainer community.
>
> This was the usual approach to manage projects in the past. Such
> person(s) is a bottleneck. In reality, much more people are working on
> stable releases than on any other (nightly builds, minor releases,
> releases proving/contradicting usability of new features etc.) and
> therefore today many projects are moving away from this kind of hierarchy.
>
this is a complete distraction from the actual problem.
we're not at QA or even releasing yet. we are at (not) developing. you
can't release something that simply isn't there (this is also where your
analogy to distros fails).
now you may argue that the current unstable branch should be simply
promoted to stable. maybe you're right. so release. what then?
as for the orga theory: when you look at all those big projects with
many involved people, you'll always find teams with (informal) internal
hierarchies: a leader (or a few of them) and possibly a bunch of lesser
qualified (or more time-constrained) minions. the point is that you
don't get anywhere with just minions.
> > that means that anyone who'd want to make major functionality
> > improvements would have to start with substantial refactoring.
>
> Well, then he should be aware of the fact, that this is not mutt's goal
> if I'm not mistaken. Today one can create a simple MUA in python in
> about one day satisfying his own needs. So, it would be a bit ill-judged
> if someone really wanted to make a huge refactorization or alike of mutt.
>
hmmm? do you even know what refactoring is?
when you start refactoring you already acknowledged the worth of the
code base. otherwise you'd start from scratch.
