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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Perhaps.
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 nd!)
b. similar to the root rotation we have on the infrastructure, I suggest to have a voluntary weekly rotation of httpd-dev list champion
+1
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. Arethere 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 itch").
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
Sure.
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
