Hi Berin,
can you elaborate on the consequences of this change? At least for me it's not completely clear what it means. This is what I understood:
- If the "yes" wins, a new PMC needs to be created, overseeing the releases of Xerces-J, Xerces-C and Xerces-P. Who would be on this board? I guess it will be made of people involved in these 3 projects; but this would mean that, when one of these projects releases a version, a part of that board will have no control on what has been released (granted, this percentage will be lower - let's say 66% - than the current percentage in the XML PMC - probably closer to 90%); or does it mean that the entire Xerces PMC will need to be involved in all three projects?
Yes - a new PMC would be required. The membership would be at the discretion of the committers of the new TLP. This is often done by just adding all committers who expresses an interest at the time of project creation.
Theoretically, the PMC should be making all major code decisions, along with release decisions. Personally I think that makes sense in the case of Xerces - I know there are a few people who are common accross C and J, and in any case there is enough knowledge of the general problem that people should be able to realistically comment on issues in the "other" Xerces flavours.
- If the "no" wins, the current XML PMC should be "getting involved in code changes": what does this imply? Monitoring xerces-cvs to spot license problems or something else?
The way the ASF is setup, it is the PMCs that have the "authority" to make decisions on behalf of the foundation (in fact the project chair has that authority, but it's "shared" with the PMC in the normal course of events).
Decisions include things such as allowing a particular commit to CVS or making a release. So it's far more than just checking license. In theory (and in other projects) members of a PMC are intimately involved in all code changes, because they are all direct committers.
To use a theoretical example - it's the PMC who should decide whether Xerces should support XML-Schema - Xerces committers should not do so in isolation.
Now, we don't do that in XML - it's just plain impractical, and at the end of the day you guys know far more about parsing and related issues than I will ever hope to. So what we have in effect done is allow each of the sub-projects to act as a TLP, making it's own decision when to change direction, or make code releases etc.
The board has indicated they are not comfortable with this. Projects are supposed to be guided by a group of people explicitly authorised to do so by the board - a PMC. So we *have* to fix it.
The Federation was seen as the best way to get a middle ground. Set (for example) Xerces up as a TLP, but allow it to keep using the XML resources unless it decides to "go it alone" with its own web site etc. In effect, we are legitimising what is already being done. If you are acting as a TLP, and it's working, why change it? Just give you the authority to do so, in line with the ASF bylaws, and everyone is happy. You would have to report direct to the board, but then you have to write a report once a quarter anyway, so it's not that big a deal.
If we don't do this, then the XML PMC is going to have to work out how to ensure decisions are being made by the people authorised by the board - the PMC. I don't think it's workable, which is why I am pushing so hard to get people to move to TLPs. But if people really don't want to, then the PMC is going to have to become more active inside all the sub projects.
Cheers,
Berin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
