Stas Bekman wrote:
1) Bugs
searching for NEW and REOPENED bugs in httpd-2.0 returns: 420 entries
http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=REOPENED&product=Apache+httpd-2.0
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
releases.
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
time/skills.
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.