You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@yahoo.com> on 2009/01/12 19:50:37 UTC

RANT: what a dead project looks like

Dead projects typically have a bus-factor of 1,
where committers have all gotten into the habit
of waiting for one another to come along for the
ride.  It's true that somebody has to drive the
bus, but the driver should rotate (and is named
RM).  The only person allowed to set a schedule
for a healthy project is an RM, everyone else
is only allowed to block progress by using their
voting rights.  This bs we tell each other about
things we all plan to do "soon" needs to come
to a close if we're ever going to be able to handle
the support load httpd may be asking us to take on.


      

Re: RANT: what a dead project looks like

Posted by Issac Goldstand <ma...@beamartyr.net>.
Without diminishing your point (because it's valid, and you're right),
let's also consider how many of us are in development-centric (or at
least httpd-centric) jobs as compared to the rest of the httpd project
developers...  I think there are substantially less of us working jobs
around apreq as there are httpd developers around httpd.   (There also
isn't much advancement of the project feature-wise lately either; we
should release faster, but there's not much to release lately)

PMC members should, however, at least put more effort into making time
to test releases and vote. 

  Issac

Joe Schaefer wrote:
> Dead projects typically have a bus-factor of 1,
> where committers have all gotten into the habit
> of waiting for one another to come along for the
> ride.  It's true that somebody has to drive the
> bus, but the driver should rotate (and is named
> RM).  The only person allowed to set a schedule
> for a healthy project is an RM, everyone else
> is only allowed to block progress by using their
> voting rights.  This bs we tell each other about
> things we all plan to do "soon" needs to come
> to a close if we're ever going to be able to handle
> the support load httpd may be asking us to take on.
>