Based on Alex's suggestion and the following comments, how about: "... that the Apache Buildr project be responsible for the creation and maintenance of a scripting-based build system based on the principles of DRY (Don't Repeat Yourself), convenience and flexibility."
Short and sweet? Cheers, Tal On Wed, Sep 24, 2008 at 5:08 AM, Victor Hugo Borja <[EMAIL PROTECTED]> wrote: > Buildr builds your own build tool. > > The thing I like most of Buildr is that It's pure ruby, and as Assaf > mentioned, I think it is the > best selling point for it. Having the syntax+power of ruby to build complex > projects is awesome. > Also we get the most by having access to any Java API and ruby tools out > there. > > On Tue, Sep 23, 2008 at 1:35 PM, Matthieu Riou <[EMAIL PROTECTED]>wrote: > >> On Tue, Sep 23, 2008 at 11:08 AM, Assaf Arkin <[EMAIL PROTECTED]> wrote: >> >> > On Tue, Sep 23, 2008 at 10:44 AM, Matthieu Riou <[EMAIL PROTECTED]> >> > wrote: >> > > On Tue, Sep 23, 2008 at 8:59 AM, Alex Boisvert <[EMAIL PROTECTED]> >> > wrote: >> > > >> > >> Charter by triangulation: >> > >> >> > >> "... that the Apache Buildr project be responsible for the creation >> and >> > >> maintenance of build system, software configuration and software >> > lifecycle >> > >> management related tools." >> > >> >> > > >> > > I would say the net is too wide. Maven, Ant, Make or Rake could all >> > qualify. >> > > A bit of overlap is not necessarily a problem but that would be a >> > complete >> > > overlap. I'd look for something a bit more discriminating with wordings >> > like >> > > scripting based, multi-language or dependency management. >> > >> > +1 >> > >> > Instead of aspiring to be another TLA, I think we should focus on what >> > makes Buildr better. Scripting is the big differentiator, not any >> > specific feature (multi-lingual, dependency management, etc). But >> > it's not a goal, it's the way we cut down on the boring and tedious >> > work, and make the rest easier and fun. >> > >> > Builds tend to be very repetitive for the most part, but also very >> > specific with a lot of one-of and ad hoc customization. No two builds >> > are the same, snowflakes and such. >> > >> > So one thing you need in a build system: convenience, framework that >> > does the heavy lifting, defaults, reusable components, all standard >> > fare that cuts down on repetitive work and boilerplate. When you >> > write compile.with my_depends there's a lot of stuff happening in the >> > background to take care of business. >> > >> > On the other hand, Buildr is very self-service: you should be able to >> > solve every build problem without waiting for the next release, >> > without struggling with pre-fab components and their limited >> > configuration. That's why underneath there's a scripting language, >> > let imagination be the limit. >> > >> >> Thats going to be a long charter ;) >> >> >> > >> > Assaf >> > >> > > >> > > Ant has its resolution on its web site and I fished the Maven one from >> > what >> > > feels like another century, when the board meetings where much shorter >> > than >> > > now: >> > > >> > > http://ant.apache.org/mission.html >> > > >> > >> http://www.apache.org/foundation/records/minutes/2003/board_minutes_2003_02_26.txt >> > > >> > > IMO they're both very good examples of what we shouldn't do :) Both >> > reflect >> > > an older time when the foundation was much smaller, we should know >> better >> > > now. >> > > >> > > Matthieu >> > > >> > > >> > > >> > >> alex >> > >> >> > >> PS: I don't like the definitions of SCM and SLM in wikipedia. They >> > sound >> > >> like they were written by vendors with a very narrow vision. You >> could >> > >> say >> > >> SLM has almost become a euphemism for Enterprise Grade DRM <tm>. >> > >> >> > >> >> > >> On Tue, Sep 23, 2008 at 8:54 AM, Matthieu Riou < >> [EMAIL PROTECTED] >> > >> >wrote: >> > >> >> > >> > Hi guys, >> > >> > >> > >> > So it seems that everybody agrees it's time to get ready for >> > graduation. >> > >> > There's a nice guide that details the whole process here: >> > >> > >> > >> > http://incubator.apache.org/guides/graduation.html >> > >> > >> > >> > The trickiest part is to prepare a resolution for the board to >> adopt. >> > >> > Ultimately, that's what we will vote on, what the incubator PMC will >> > vote >> > >> > on >> > >> > and what the board adopts. And the trickiest parts in the resolution >> > >> itself >> > >> > are: >> > >> > >> > >> > - The target: Top Level Project or subproject of another TLP. For >> > >> buildr >> > >> > I think it would be TLP but if someone things otherwise it's a >> good >> > >> time >> > >> > to >> > >> > mention it. >> > >> > - The charter: this should define the scope of the project. It >> > should >> > >> be >> > >> > short, sweet and non ambiguous but sufficiently large in scope to >> > cover >> > >> > further expansion of the project. So getting the proper wording >> can >> > be >> > >> > tough. There are example here [1] and if you want more I can point >> > you >> > >> to >> > >> > others. >> > >> > - The project chair: I'll send another e-mail about that. >> > >> > - The future PMC: actually that's the easiest, it's usually the >> same >> > >> > composition as the PPMC. >> > >> > >> > >> > So at this point, it would be nice if someone drafted a first >> charter >> > >> > paragraph so we can increment from it. The rest of the resolution >> can >> > >> > easily >> > >> > be created using the charter and a few names. >> > >> > >> > >> > Thanks, >> > >> > Matthieu >> > >> > >> > >> > [1] >> http://incubator.apache.org/guides/graduation.html#tlp-resolution >> > >> > >> > >> >> > > >> > >> > > > > -- > vic > > Quaerendo invenietis. >
