Hi all,
as threatened, here is the proposal.
According to our bylaws it needs +1s froms two thirds of all active committers to pass. By my count that is 12 out of 18 (all PMC members listed on the contributors page plus all committers listed there plus Jose Alberto who hasn't added himself to the page yet). Even if I subtract the two PMC members who've stated they want to go to emeritus state (Costin and Magesh) two thirds would still mean more than 11.
Costin resigned some time ago as a PMC member. I need to update the website to reflect that.
Common Java libraries that only happen to provide Ant tasks as well are out of scope of the subproject. Providing the tasks or types has to be the primary goal of the library.
Agreed - don't want it to become a backdoor commons. One other concern I have is how we handle the third party task problem. In the early days of Ant we accepted tasks that targeted particular third party products (weblogic, starteam, perforce, etc) but transitioned to a policy of not allowing tasks which were not considered "core". Will this project open up that question again where vendors seek to have their tasks included in the antlibs project. I think we might need to think about a third party task policy.
(3.2) SVN repositories
Create <http://svn.apache.org/repos/asf/ant/>
If we are going to use SVN for this, I think we should migrate Ant to SVN as well and consider where to put it in your proposed structure.
(3.3) Bugzilla
New components under product "Ant" for each new library.
Just want to confirm we are sticking with BugZilla still.
Note:
* is, has, will, shall, must - required.
Have you been writing ITU specs lately? :-)
(4) Each library is treated as a product in its own right.
(4.1) Each library has its own status file, release schedule, version number, QA tests, documentation, bug category, and individual JAR.
(4.2) Each library must clearly specify any external dependencies, including any other libraries, and the earliest JDK version required.
(4.3) Each library must maintain a list of its active committers in its status file.
This sounds like an umbrella project. I think we should just have one subproject - the antlibs project and not partition below that. All antlibs active committers are committers for each library in antlibs.
(4.4) Each library will be hosted on its own page on the subproject Web site, and will also be indexed in a master directory.
(4.5) Volunteers become committers to this subproject in the same way they are entered to any Apache subproject.
Once the required infrastructure is in place, volunteers may become committers for a single Ant library only.
This may be true in practice but I would rather not state that in this proposal. We certainly won't enforce this with the standard karma system.
(4.6) New libraries may be proposed to the Ant dev mailing list. To be accepted, a library proposal must receive majority approval of the Ant PMC. Proposals are to identify the rationale for the library, its scope, the initial source from which the library is to be created, and the initial set of committers.
Again, I think this is layering a little too much. I would be happy to see the antlibs projects create libraries without requiring an explicit PMC action. I think this should only be required if it appears things are getting out of control. Start out with Lazy Approval?
(4.7) As stated in the Ant guidelines, an action requiring majority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes.
(4.8) Each Ant library needs at least three committers, at least one of them has to be an Ant PMC member.
Similar issue here, I think. I think we need to avoid two things. One would be lack of oversight - so make all committers responsible for everything. The other problem is libraries that atrophy. Again I think the solution is to keep access broad so we don't get the problem where libraries run out of active committers. If a library withers on the vine, the antlibs project should be able to cast it off if unreleased or to end-of-life it if released.
I'm pretty much +1 on your proposal and don't want to throw a spanner in the works but thought these issues were worth raising.
Conor
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
