BAD MSG: silence does not mask a certain sort of inertia. However bear in mind that HTTP is small, has very easy and almost 'objective' external requirements in the form of RFCs and had a relatively small code base. Even the rewrite of 1.3 to 2.0 to address some fairly well known issues is/was relatively simple compared to some of the major engineering and dust being through around elsewhere.
Now if this would be all - no worries. However I personally think that the transition from that one HTTP crowd to one for HTTP, one for APR, etc, etc was already showing that something is a bit amiss in the scaling; even though the group of peopple is nearly overlapping; long term goal, feature creep in APR, versioning issues between APR/HTTP and even getting release notes out with some sort of coordination with php/perl treading-aint-work warnings, required a fair amount of noise in order to get the coordination they required. I cannot help to think that a much smaller group of people across those projects whould have done better than the current cabal keeping things on track simply by being a smaller focal point who know that they cannot dodge the issue. However it is not here where I see the major issues exposed right now - but when scaling up and over to: > > It is the jakarta/xml ones which worry me; as they are so much bigger and > > deal with some much more code; a lot of which does not have a nice RFC or > > clear set of requirements to easily compare options or provide guidance. > > Yes, many agree with you in this vision and I think Sam's proposal goes > in the direction of creating an evolutionary escape path or, at least, a > way to have spread the word about things for those who won't make it > here on [EMAIL PROTECTED] Right. > Moreover, I don't think a PMC with a hundred of members will behave any > worse than a PMC with just a few of them. And I do think it is; as a PMC of a hundred members will never act quicker or more focused/quick as a group of 5-10 people recruited out of those 100 who have a task (say investigate a license issue) and know that there are a 100 people looking at them to get it done. Now having said that; perhaps we need to cycle those 5-10 people much more ofter; as I agree something is amiss. But I think making them a 100 is not the right track - and that is where I see the main flaw. And I also think that too large a cabal will simply create 'chair's whose job is much bigger than a volunteer can handle. It is that task I'd like to split among 5-10 people. As ultimately the board will continue to chase chairs to get things done. And it is easier for a chair to prod a few people nearby than to galvanize the populus as a whole for the sort of boring tasks asked. > I really don't think that it can be worse than we have today, so +1 from me. Aye - as I said - short term it is our best option - I think; and if I where a jakarta-head I'd certainly give it a +0 or +0.5. Dw
