httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: the wheel of httpd-dev life is surely slowing down, solutions please
Date Thu, 13 Nov 2003 01:51:46 GMT
--On Wednesday, November 12, 2003 16:38:11 -0800 Aaron Bannert 
<aaron@clove.org> wrote:

>> I believe Sander's suggested that we start a patch manager role
>> (discussion  at AC Hackathon!).  A few other projects I'm involved with
>> do this.  It'd  be goodness, I think.  But, the problem is finding a
>> volunteer willing to  shepherd patches.
>
> -1
>
> Creating roles like this is just as bad as having chunks of httpd "owned"
> by one particular developer. (See below)

I don't think you understand the role of 'patch manager.'  On the projects 
I'm involved with, that person's only responsibility is for ensuring that 
the patches posted to the mailing list are entered into the right tool.

I think that can easily be a volunteer, rotating job as you don't need to 
do anything more than that.

> How is this different than "owners" above? You can't expect developers
> on this list to think ahead of time when they might have extra time
> to contribute to this project. Most of the time it is on a whim
> late at night when all of the important chores are taken care of.
> If you ask for people to sign up for a slotted amount of time,
> you'll only end up excluding people who don't work on Apache at
> their day job.

In the patch manager role, nothing would preclude others from adding 
patches to the right tool.  But, having someone whose responsibility it is 
to ensure that patches get inputted into the tool on a timely basis is 
goodness.  On other projects I'm involved with, that person isn't an even a 
committer.  They don't have to understand what the patch does - just make 
sure it is recorded and allow for annotation.

And, it doesn't have to be on a 'timely' basis - once a week, you go 
through and ensure that all [PATCH] messages are in the right patch 
management tool.  This lessens the number of dropped patches that we'd 
have.  (Bugzilla sucks at this, so I think we'd need a new tool.)

> Woah woah woah. Are you discouraging people from thinking about big
> changes for the 2.2 timeframe? If someone has a revolutionary idea for
> the next generation of Apache HTTPD, who will stand in their way? Not I.

Frankly, yes.

I think our changes that we already have in the tree is about 'right' for 
2.2 (no big architecture changes, but lots of modules have been rewritten 
and improved).  It's just that no one has time or desire to shepherd 2.2 to 
a release.  And, I think we need APR 1.0 out the door before 2.2 can be 
rationally discussed.

If we did any major changes from this point that require modules to rewrite 
themselves, we'd need to go to 3.0 per our versioning rules.  And, I'd 
*strongly* discourage that.  I don't think it's in anyone's best interest 
to revamp our architecture at this stage.

We don't need to give a moving target to our poor module developers.  Only 
by producing a series of high-quality releases can we ensure that module 
writers will be confident in writing against 2.0 or 2.2.  If we come out 
with 3.x now, I think we'll just end up hurting ourselves in the long run 
even worse than we are now.  -- justin

Mime
View raw message