Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
To: dev@ant.apache.org
Subject: [PROPOSAL] Antlib Subproject
From: Stefan Bodewig <bodewig@apache.org>
Date: Fri, 11 Feb 2005 12:16:31 +0100
Message-ID: <m3mzub5ots.fsf@bodewig.bost.de>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
 Obscurity, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi,

as I threatened, here is the proposal.  This is not a vote yet and I'm
going to also put it up the Wiki so we can work on it together.

I've kept it rather formal since a subproject deserves it IMHO.  The
scope definition has been kept rather tight and at least I want to
keep it that way.

The structure and parts of the text as well as some ideas here heavily
borrowed from Jakarta Commons[1] or the Incubator.

Stefan

Footnotes: 
[1]  http://jakarta.apache.org/commons/charter.html

So here we go

Proposal to Create a Ant-Libraries Sub-Project in Apache Ant
============================================================

(0) rationale

Ant itself has accumulated lots and lots of tasks over time.  So many,
that Ant developers have become reluctant to adding new task.
Furthermore any new task in Ant would be tied to Ant's release
schedule which is too slow for a thriving, fresh piece of code.

The proposal allows Ant tasks and types to be developed under the Ant
umbrella by Ant developers but have much shorter release cycles than
Ant itself.  In addition it would new committers who would have commit
access to a single Ant library instead of the whole of Ant.

(1) scope of the subproject

The subproject shall create and maintain libraries of Ant tasks and
types.  Each library will be managed in the same manner as the Ant
project itself, the PMC is ultimately responsible for it.

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.

To further this goal, the subproject shall also host a workplace for
Ant committers.

(1.5) interaction with other subprojects

(1.5.1) the sandbox

The subproject will host a SVN repository available to all Ant
committers as a workplace for new Ant libraries.

Before a library can have a public release it has to get promoted to
the "proper" Ant libraries subproject.  This also means it has to
match the requirements of an Ant library as defined in section (4)
under Guidelines below.

The status of any library developed in the sandbox shall be reviewed
after six months and the library gets either promoted or removed - or
it has to be re-evaluated after another six months.

(2) identify the initial source from which the subproject is to be
    populated

Some Ant committers have developed tasks or libraries inside of the
Ant CVS module under the proposal/sandbox directory.  Committers are
free to move them over to the new sandbox subproject or remove them
completely.

Libraries expected to move to the sandbox subproject initially are

* the .NET tasks under proposal/sandbox/dotnet

* the Subversion support tasks under proposal/sandbox/svn (work here
  will start soon)

(3) identify the initial Apache resources to be created

(3.1) mailing list(s)

None.  At least at the beginning we don't expect too much traffic and
the existing mailing lists of the Ant projects will be used.

(3.2) SVN repositories

Create <http://svn.apache.org/repos/asf/ant/>

Expected are sub-directories

antlibs/
   |
   -----> proper/
   |        |
   |        -----> library1
   |        |        |
   |        |        -----------> trunk
   |        |        -----------> tags
   |        |        -----------> branches
   |        -----> library2
   |                 |
   |                 -----------> trunk
   |                 -----------> tags
   |                 -----------> branches
   |
   -----> sandbox/
            |
            -----> library1
            |        |
            |        -----------> trunk
            |        -----------> tags
            |        -----------> branches
            -----> library2
                     |
                     -----------> trunk
                     -----------> tags
                     -----------> branches

And potentially collections of all-trunks using svn:external as shown
by the current Jakarta Commons structure.

(3.3) Bugzilla

New components under produce "Ant" for each new library.

(4) identify the initial set of committers

All current Ant PMC members plus the active committers who are not PMC
members yet.

Guidelines
----------

Note:

* is, has, will, shall, must - required.

* may, should, are encouraged - optional but recommended.

(1) The primary unit of reuse and release is the Ant library.

(2) The library is not a framework or a general library but a
    collection of Ant tasks and types.

(3) Each library must have a clearly defined purpose,
    scope, and API.

(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.

(4.4) The libraries should use a standard scheme for versioning,
      QA tests, and directory layouts, and a common format for
      documentation and Ant build files.

(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.

(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.

(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.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org