On Tue, 08 Mar 2005, Conor MacNeill <[EMAIL PROTECTED]> wrote: > 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 guess it will. This part of the reason why I brought finer grained access control and a minimum number of committers into the proposal. A vendor initiated antlib under our rules (which means the vendor doesn't have more influence than any other committer) developed by enough people to keep it maintained is fine with me (but maybe not with all of us). > Stefan Bodewig wrote: >> (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. Actually I consider this a first step for the migration since more committers will get their feet wet with SVN. IMHO Ant itself fits in there as http://svn.apache.org/repos/asf/ant/ant/ >> (3.3) Bugzilla >> New components under product "Ant" for each new library. > > Just want to confirm we are sticking with BugZilla still. see my response to Steve. I'm not sure what our infrastructure team would prefer these days. >> Note: >> * is, has, will, shall, must - required. > > Have you been writing ITU specs lately? :-) Nope, verbatiom copy from the Jakarta Commons Charter, which has been written by Ted Husted IIRC 8-) >> (4) Each library is treated as a product in its own right. > > 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. This would be a quite different proposal than the one we are voting on. Shall we cancel the vote, discuss this and come back to this or a new proposal after that? I don't have the slightest problem with doing so. > I think we need to avoid two things. One would be lack of oversight > - so make all committers responsible for everything. That's why I required at least one PMC member as committer. > 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. Does that work? We don't have enough active committers for quite a few optional Ant tasks right now. > 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. Absolutely, yes. > 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. Yes they are. Thank you for doing so Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
