From Thu Nov 20 22:06:12 2003 Return-Path: Delivered-To: Received: (qmail 93730 invoked from network); 20 Nov 2003 22:06:12 -0000 Received: from (HELO ( by with SMTP; 20 Nov 2003 22:06:12 -0000 Received: (qmail 85089 invoked by uid 500); 20 Nov 2003 22:05:53 -0000 Delivered-To: Received: (qmail 84943 invoked by uid 500); 20 Nov 2003 22:05:52 -0000 Mailing-List: contact; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: Delivered-To: mailing list Received: (qmail 84857 invoked from network); 20 Nov 2003 22:05:51 -0000 Received: from unknown (HELO ( by with SMTP; 20 Nov 2003 22:05:51 -0000 Received: from localhost ([]) by with SMTP id <>; Thu, 20 Nov 2003 22:06:12 +0000 X-Mailer: Openwave WebEngine, version (webedge20-101-191-105-20030415) From: Berin Lautenbach To: , CC: Subject: Re: XML PMC and Oversight Date: Fri, 21 Nov 2003 9:06:12 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <> X-Spam-Rating: 1.6.2 0/1000/N X-Spam-Rating: 1.6.2 500/1000/N > From: Shane Curcuru > I agree the main discussion should happen on general@, however everyone has > to forgive me for unpolished style writing in the airport. > > My feeling is xml should do two things, which hopefully both will make > sense, and will address the issue: > > -- Split the ASF organizational structure up into 3ish PMC's to cover all > the existing XML projects. > This should give the required level of oversight without overwhelming the > board. Maybe.... Sooner or later (and it looks like it's going to be sooner the way the ASF is adding projects :>), the board is going to hit the top limit of projects it can oversite adequately. If we can come up with a way of splitting our internal oversite up, but still have one report to the board for all of, then I think there is a win for everyone. So the feeling I got from Dirk's e-mail is that the board does not want to see us fragment into multiple TLPs that the board has to manage, as then we simply push the problem to them. However I think the split into three is probably about right, it's just a matter of how do we coordinate (do we coordinate?) those three groups. Two options that spring to mind (derived from Dirk's original e-mail) - 1. Three groups are there as oversite of the code and release processes defined by the current PMC. They simply document (in e-mail lists) the OK that occurs before code releases etc. in line with defined requirements. The current PMC remains, made up of members of the three groups, and is the group that actually defines the requirements that the Code Review Groups (CRG - feel free to re-name :>) follow, etc. So basically the PMC would do almost what it does today, but would devolve responsibility for immediate code oversite to the CRGs who would then *maybe* have a regular report back. (Possibly as input to the broader report to the board that we already do.) In the event of issues the CRG would escalate to the PMC that would then handle or escalate to the board. I.e. if there is a license problem or whatever, then it's still the responsibility of the PMC to address. The CRG is purely there to make sure our code is hygienic :>. I kind of like this, as I suspect that we can set these groups up and have minimal change within the sub-projects (other than those necessary to adapt to whatever the agreed processes are) and yet still meet the requirement of the board. 2. Push much more into the CRGs (they would be called something else, but I can't think of a name at the moment). oversite would be a very small number of people that simply co-ordinate the three groups at a very high level, and the three groups pretty much set their own standards etc. Problem here is that it becomes much harder to show to the board that we are all doing the right things, and risks starting to splinter into three different sets of processes etc. If we are going to go down this path, I think we would be better off simply recommending that we think it should be three TLPs and then move on. > Also, I'm feeling that we can find 3 useful groups to split into; > perhaps along functional lines like below (unless someone can point out > some obvious community lines that would fit better?) This is the bit that's been keeping me thinking. > The Xerces', Xalans, and xml-commons are the base of the XML stack. > Batik and graphics types in another project. > DB-related projects in another spot. > Where does forrest fit? This is an important one, because we use it for > the website, and is an important 'showpiece' of much of our technology > (yes, there's a reason we go through so much seeming rigamarole to build > our website: eating our own really cool dogfood). > Another method of doing the split (probably not as good :>) - The Xalan/Xerces thing seems like an obvious gathering to me. I was then thinking maybe we could look at grouping the "library" projects together. So for example, xml-commons and xml-security both provide library functions that are used by other apps. Finally have those that are pure applications in the final group. Axkit/Forrest etc. Don't know if it's as simple as that though :>. > Personally, I'd like to keep them all under since that's > simplest, but whatever is fine. > > -- Clearly document some procedures for subproject management. > This will both help with some committer confusion we've seen evidenced as > well as providing for better 'provable' oversight. > Note that here my feeling is that we should put some proposals on general@, > wait for feedback, and then the PMC should simply decide the policies and > codify them. > Given that the issue of oversight is an organizational one, the PMC is the > body that should decide the final polices. Yes, I want committer community > input: but both because oversight is the PMC's job, and because it'll take > a lot less time if we have a smaller group doing the work. (of course we > have the question of if it's the current PMC or the new 3 PMC's who set > this...) The PMC (in its current form) will need to agree and vote on the new processes and changes I think. And I think we would probably want a board OK before we did the change, so I was thinking around 1. Develop the new structure and formalise the processes that Neil discussed the other day. 2. Vote within the current PMC that we are comfortable with the suggested approach. I'd say at this point we don't develop a new charter, we just develop a position paper that we have all agreed on. 3. Present the position to the board (as requested by them). 4. Implement if the board is comfortable. (Note that implementation will include the required changes to the charter.) My feeling - the more people that input, the better. We may have to be arbitrary to get somewhere if it gets out of hand, but lets see how we go! Cheers, Berin This message was sent through MyMail --------------------------------------------------------------------- To unsubscribe, e-mail: For additional commands, e-mail: