ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject AW: Where should the dotnet sandbox go?
Date Fri, 17 Sep 2004 12:06:32 GMT
On the same reasons I would say (3). Especially we had spoken about
breaking Ant into modules and moving to SVN ... (last year at your home,
Stefan :)
I think a new subproject would be the right place because Ant targets a
with Java while these new tasks targets a development for .NET. 
Same as on Log4J/Log4C/... all under the logging-project, but individual
... and ... why do we have a top level project ;-)

It´s ever the same if a committer has an idea about an addition to Ant. So
the only
way is to ask the rest of committers. 


> -----Ursprüngliche Nachricht-----
> Von: Stefan Bodewig []
> Gesendet am: Freitag, 17. September 2004 13:49
> An:
> Betreff: Where should the dotnet sandbox go?
> Hi
> it seems as if my little experiment with <nunit> and friends has found
> at least a few people who want to use it, so I'm now at the point to
> decide on its future.
> I see a couple of options and want to hear your opinions:
> (1) add them to Ant's CVS HEAD
> (2) move them to a different place outside of the ASF
> (3) start a new Antlibs subproject of Ant and make this (one of) its
>     founding component(s).
> My opinions:
> (1) isn't fair considering the number of people we send away.  I'd
> feel like abusing my committer power.  The target audience for the
> tasks simply isn't big enough.
> (2) works for me.
> (3) works for me as well and would be my preference.  In particular if
> Steve or anybody else of the committers want to work on it as well.
> This would require thinking about that new subproject's agenda and how
> we'd decide which components get added or how to distribute commit
> access, but I don't want to go into detail here, without knowing
> whether this is something the rest of the committers/PMC would like to
> see happen.
> Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message