ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: [VOTE] Start a subproject for Ant libraries
Date Tue, 08 Mar 2005 12:04:35 GMT
Stefan Bodewig wrote:
> 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 <>

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message