httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: the wheel of httpd-dev life is surely slowing down, solutions please
Date Tue, 11 Nov 2003 01:50:46 GMT
--On Monday, November 10, 2003 17:14:35 -0800 Stas Bekman <> 

> 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

Why can't they subscribe to  I don't think throwing 
all of the bugs on dev@ is going to help matters.  I'd just add a procmail 
rule to toss them back into my bugs@httpd folder.

> In my personal opinion, the move to CTR from RTC had very bad
> implications on the design of httpd 2.1.

CTR is still in effect in 2.1.  Only RTC is in effect for 2.0, but, IMHO, 
that's to try to cover our butts that people don't break the server.  I 
believe that RTC is very good for maintenance branches that shouldn't break 
anything (like our stated goal for 2.0), and CTR is good for development 
branches (2.1).

> 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.

Do you have an example?

> 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.

I'm sorry, but when has this happened?

> 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.

We've been in CTR for the 'open' branches.  You have commit access, so you 
have been entrusted with doing the right thing.  If you do something wrong, 
someone will eventually chime in - as it is CTR.  ;-)

> 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.

I don't believe there was ever a plan for 2.0 either.  ;-)

I think 2.0 GA happened because, well, um, a few people that would have 
stopped it were out of town.  Yet, it happened, so at that point, we 
started to be committed to what 2.0 was.  When we adopted the binary 
compatibility rules, we were fixed even further as to what 2.0 was.  Until 
those points, I don't think any of us had a plan for 2.0...

I think the binary compatibility rules were essential and, in retrospect, 
we should have had them in place before we went GA in 2.0.  Yet, we know 
better now.  2.2 shouldn't have those same mistakes when we do that.

> 2d). CRT seemed to come as a replacement for design discussions. It's
> very easy to observe from the traffic numbers:

Not sure why you think there's a correlation here.  Statistics can be 
misleading.  =)

> You don't need a fancy graph to see a clear decline in the last 1.5
> years. Quite a few people suggested that this is due to the market
> decline. I won't doubt them, but it's quite possible that the market

People change jobs or whatnot.  Committers are only expected to contribute 
when they have time.  It's not like we're all getting paid to work on this. 
I'm certainly not.

I confess that I don't have the time I used to, but I'm also involved 
'behind the scenes' within the ASF more than I was a few years ago.  So, 
perhaps my time committment to the ASF is the same, but it's spread out 
amongst other projects/worthy causes.  Working on the same thing for years 
on end can be a tad disconcerting.  We all need a break at times.

> 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, since most contributions are simply ignored and


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.

> a. certain (most?) chunks of httpd lack owners. If httpd was to have

I really dislike this.  The least maintained modules are those that had 
'owners.'  When those owners left, they didn't send a notice saying, 'we're 
leaving.'  The code just rotted.

I firmly believe that httpd's group ownership is the right model.  Only 
recently have those modules that had 'owners' been cleaned up.  (Yay for 

> b. similar to the root rotation we have on the infrastructure, I
> suggest to have a voluntary weekly rotation of httpd-dev list champion


> c. turn the dealing with contributions and bugs into a sexy
> thing. Everybody wants to feed their ego, there is no better way to
> make your ego happy then getting a positive feedback from a person you
> have helped to resolve a bug or handhold to provide a good patch for
> the new feature, they spent so much time working on.

Sure, but that requires a time committment.  That's not always possible to 
expect from people with 'high list karma.'

> (even though that technically they are still committers and all) the
> those who join the project. Which obviously has clear effects on the
> productivity of the dev list.

>From my perspective, httpd-2.x does what I want it to at this point.  Are 
there some things that I'd like cleaned up?  Sure.  But, my personal 
opinion is that the codebase is in better quality now than it was 2+ years 
ago (or whenever I first joined).

Additionally, I'd say that we're best off *slowing* down 2.x development to 
let module authors write modules against 2.0.  Changing the world in 2.2 
would be detrimental, I think.

> all. It's very easy to see that questions from most known httpd
> developers almost always have a long thread with resolution. Other
> posters are usually lucky to get any responses at all, and if they do
> usually the thread would die out without any resolutions.

I'd say that's because we know we must be persistent, AND there's also a 
personal motivation to resolving the issues at hand ("scratch our own 

> do". I'd like to suggest that it's a very own httpd problem, because
> usually you get questions from 3rd party developers when something in
> httpd doesn't cooperate with those 3rd party modules and needs to be


> fixed. I think it's much less important to work on Apache 2.1 and much
> more important to polish 2.0 and make 3rd party developers
> happy. (wearing the 3rd party module developer hat) we don't need no

Um, 2.0 has fixed binary compat rules, so you can't make any changes that 
break that.

> demands. So telling them: "hey, we gave you a commit access, just go
> and code/fix it". is not always working.

(I realize I've probably told you that line you are quoting above on 
several occassions.)

In all seriousness, if that's the case then you shouldn't accept being  a 
committer.  Scratching your own itch is how I believe it should work.  I'm 
sorry to hear that you dislike that, but I don't know what we can do to 
help *you* specifically.  You've got commit access (and on the PMC, to 
boot).  Ultimately, I don't think there are any roadblocks that we're 
imposing on you.  And, I think that's the best we can do.  -- justin

View raw message