xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Lautenbach <be...@wingsofhermes.org>
Subject Re: [VOTE]: motion to transform Xerces into a top-level project as a member of the "federation" of XML projects
Date Sat, 01 May 2004 10:30:22 GMT
Alberto Massari wrote:

> 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 

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 

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 


To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message