1. Why do this?
Many of you may not be aware of recent discussions on the reorg and community mailing lists. Many issues have come up about the management of container projects (such as Jakarta and XML) and the concepts of project oversight and legal protection for work done on Apache projects. A model where all or most committers are on the PMC apparently solves these issues. This is the model used for the httpd project. I don't really want to replay those discusions here on ant-dev. The issues are certainly not clear cut. If you are interested in following discussions, please join the community list (open to all Apache committers).
We are not doing this to leave Jakarta or somehow isolate Ant from the Jakarta project. Ant's committers will continue to be involved in other Jakarta sub-projects and Ant will continue (I hope) to be used by most Jakarta projects for building its code. I hope Henri will continue to build our RPMs :-)
Jakarta will be changing, I think, over time for the same reasons as above. Ant is a very mature and successful Jakarta project so it is natural that would be one of the first to make such a change. Whether Jakarta ends up as some sort of federation of top-level Java projects, I can't really say at this stage.
We are not doing this because we have problems with the Jakarta project management, its PMC or because we feel powerless or shielded from the rest of Apache by the Jakarta PMC. We are not doing this to remove our dependence on the Jakarta PMC because that dependence, such as it is, has not been an issue to date. This may apply to other sub-projects in Jakarta, but not, IMHO to Ant.
In terms of the day to day development of Ant, I expect nothing to change. The way we develop code and make decisions about the code, releases, bugs, etc will not change. These are Apache wide principles and will continue to work as they always have. It will be up to us, as the Ant PMC to resolve any conflicts within the Ant project.
So, from my point of view, this is about establishing a structure which gives us legal protection and meets the board's requirements for the oversight of the codebase.
Scope
The proposed scope was "the creation and maintenance of open-source software related to the Apache Ant build tool" which is, as I indicated, a little recursive. It is definitely not intended that Ant would grow to a tools container project as we would just come back to where we are now. So, tools such as Gump and maven which build upon Ant would not be part of the Ant project. OTOH, a series of projects for a set of task libraries would be in scope. IMHO, Antidote would be in scope as would ant-contrib.
So how about this "the creation and maintenance of open-source software related to the Apache Ant build tool and supporting task libraries"? Not sure if that is better - does anyone have any better words?
It is important to get the scope right, without it being too narrow. Another of the issues raised about the Jakarta project is how out of scope many of the Jakarta subprojects are, Ant being used as a prime example.
PMC Chair
We will need to choose a chair for the board resolution. The chair becomes an officer of the ASF and therefore needs to be approved by the board as part of the resolution. Ideas about how we can choose the chair are welcome although the process might depend on how many candidates there are.
The term of the chair and the mode of future elections would be covered by the bylaws of the Ant project. The development of these would b the first task of the new PMC. I would expect the chair to be elected by the PMC annually as is currently done for the Jakarta PMC. I don't think some sort of lifetime appointment is the way to go.
The chair will need to report quarterly to the board on the progress and issues of the Ant project.
Bylaws
As I said above we will need to come up with a set of bylaws that govern the operation of the Ant project. These will cover things such as the terms of the Chair, how the chair is elected, how the PMC is composed, how PMC decisions are made, concepts such as emeritus status, adding new members, etc. Here I would expect that we would not have anything peculiar to Ant, something like Jakarta or httpd would be a good basis.
I'd be happy to have a discussion now, to try and capture the essential elements of the bylaws if there is interest.
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
