ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: [Proposal] Resolution for Ant top level project
Date Tue, 05 Nov 2002 20:45:37 GMT
Thanks to Stefan and Conor for clarifying things for me. I'm mostly in 
agreement now. Comments below.

At 09:24 AM 11/5/2002 +0100, Stefan Bodewig wrote:

>Make them emeritus and when they find time to contribute again, they
>can get back easily?

Perfect. I hadn't realized that was the point of emeritus status.

> > Another option would be to allow the PMC to nominate and elect the
> > chair from their number rather than taking a vote of committers
>I don't think this would work as board would need to appoint an
>officer when it passes the resolution.

If the chair needs to be appointed to a position within Apache as part of 
the resolution then I agree, it is clearly needed in the resolution.

> > Would the declaration in the resolution be binding on the terms
> > allowed in the bylaws?
>I'm not entirely sure, but I think the board would have to approve the
>bylaws - which would change part of the resolution in retrospect.

If the resolution's definition of the term of the chair isn't binding, no 
problem. It probably isn't a big deal either way since it is hard to 
imagine someone raising the issue anyway, but I spent a number of years 
working on a program that analyzed legal text and the cases I've read have 
made me overly cautious about such things. :-)

At 09:07 PM 11/5/2002 +1100, Conor MacNeill wrote:

>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?

My preference would be to keep it generic. As I said, the decision 
regarding specific subprojects should be kept separate from the resolution 
and this wording appears to already exclude many of them. The current goal 
of Ant is to create a build tool. That tool and anything that interacts 
with or supports it are at least potentially in scope, but I think the 
committers at the time should be able to decide case-by-case.

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

View raw message