httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: the wheel of httpd-dev life is surely slowing down, solutions please
Date Tue, 11 Nov 2003 13:33:18 GMT
Stas Bekman wrote:

> 1) Bugs
> searching for NEW and REOPENED bugs in httpd-2.0 returns: 420 entries

yes, far too many :(

> Suggestion: make bugzilla CC bug-reports to the dev list. Most
> developers won't just go and check the bugs database to see if there
> is something to fix, both because they don't have time and because
> there are too many things to fix. Posting the reports to the list
> raises a chance for the developer to have a free minute and may be to
> resolve the bug immediately or close it.

That would reduce the number of subscribers to dev@, which is the opposite of 
what we need.  At least we have a monthy summary posted to dev@ which reminds 
folks that there is a bug db.  Also, it is my interpretation of bug db traffic 
that Joshua and Andre' already jump on the PRs that can be resolved 
immediately.  Many of the outstanding PRs are quite difficult to resolve.

Working the bug db is a noble effort, but many in our community have no time to 
work it.  The way to get more time being spent on the bug db is to take the 
kind of actions that increase the number of httpd developers.

> 2) Lack of Design
> 2a). Design of new on-going features (and changes/fixes) of the
> existing features is not discussed before it's put to the code. When
> it's committed it's usually too late to have any incentive to give a
> design feedback, after all it's already working and we are too busy
> with other things, so whatever.

We leave it up to the developer to judge whether some design issue needs to be 
discussed first.  If something is committed prior to being discussed, then the 
person with the objection must start the discussion at that point.  This is a 
tool against stagnation.  If somebody has the time/energy to work on something, 
we can't put up a roadblock just because nobody else has the time/skills to 
discuss it with them.  The only roadblock is the one to protect users of stable 

> The worst part is that it's now easy to sneak in code which otherwise
> would never be accepted (and backport it to 2.0). I don't have any
> examples, but I think the danger is there.

There is a barrier to getting things backported to 2.0 as a protection against 
possible drawbacks of C-T-R.

If three people are in favor of putting something in the stable branch, 
mistakes can still happen, but I don't see how we can refer to such a backport 
as sneaking in code.

> 2b). As a side-effect when someone asks a design question (e.g. me)
> it's not being answered because people tell: we are in the CRT mode,
> go ahead code it and commit it. But if the poster doesn't know what's
> the right design, if she did she won't have asked in first place.

Alternate opinion: If a question is not answered, it is because nobody has 

As mentioned above, I see the C-T-R mode for 2.1-dev as a tool that helps 
work-around a lack of energy/skills on the list.

> 2c). Future design. There is no clear roadmap of where do we go with
> Apache 2.1. People scratch their itches with new ideas which is cool,
> but if there was a plan to work on things, this may have invited new
> developers to scratch their itches.
> 2d). CRT seemed to come as a replacement for design discussions. It's
> very easy to observe from the traffic numbers:

As Bill said, it has been this way for some time.  At some point we created a 
stable branch for 2.0-dev, but 2.1-dev is handled in the same way that 2.x was 
handled all along.

> 3). Contributions
> I don't have numbers to support my clause, but I have a strong feeling
> that nowadays we see a much smaller number of posts with contributions
> from non-developers

I can believe it.

> Solutions:
> a. certain (most?) chunks of httpd lack owners. If httpd was to have
> clear owners of certain code bases then it'll be easy to take care of
> bug reports and contributions/patches. Even though httpd is
> collectively owned, it doesn't preclude champions in certain areas,
> who can see that good things happen to the areas they overlook.
> b. similar to the root rotation we have on the infrastructure, I
> suggest to have a voluntary weekly rotation of httpd-dev list champion
> whose responsibility is to make sure that most (all?) bug-reports and
> contributions are dealts with: assigned to those who those champions
> who know how to fix/review/adopt things (See (a) above), asking for
> more input if needed, etc. You don't have to know httpd as your five
> fingers to be able to do a great rewarding job.

Personally I'm very disinterested in a system that puts certain responsibility 
on a single person for an area of the code or for a period of time.  Work/life 
issues arise from time to time that force folks to disappear for a stretch.  To 
the greatest extent possible, any policies/procedures we have should have the 
goal of channelling volunteer efforts instead of placing certain 
responsibilities with a single person.

It would be good to have a single place other than the mailing list (2.1-dev 
STATUS or bug db or something else) where patches are tracked and where 
contributors can know the status.  Somebody brought up the idea of "patch 
manager."  I'm interested in hearing more about that.  Anything that focuses 
the available light on these contributions would be very helpful.

> 3a) I can hardly see new developers joining the team, should we blame
> the economy or the lack of encouragement for people to contribute.

perhaps some of both... One of these we can't take action on anyway.  All we 
can try to do is be gracious with contributions.  Sooner or later that will 
result in new people devoting significant time to httpd.

 > 4). Feedback Preference and List Karma

Without agreeing or disagreeing with anything you wrote here, I'm not sure what 
possible actions could be.  Any action should be consistent with the idea that 
httpd developers are all volunteers and any effort they are able to make is to 
be valued.  But it doesn't bring a healthy community to finish with saying

* If an httpd developer is only interested in 2.1-dev, so what?
* If an httpd developer is only interested in a certain functional area of the 
code, so what?
* If an httpd developer ignores the bug db, so what?
* If an httpd developer ignores dev@ posts that they don't think is something 
for httpd to worry about, so what?

Somehow as a group we have to help new folks who are willing to do the work to 
fix/enhance httpd in a way that is beneficial to others.  Having a better way 
to track patches and make sure that would-be contributers get feedback is a 
step in the right direction.

View raw message