"... that the Apache Buildr project be responsible for the creation and maintenance of a scripting-based build system based on the principles of DRY, DIY and doesn't make you cry."
:-P On Wed, Sep 24, 2008 at 11:01 AM, Assaf Arkin <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2008 at 5:20 PM, Tal Rotbart <[EMAIL PROTECTED]> wrote: >> 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? > > Yep. > > I expect that the charter would constrain us in the direction we want > to go. If the charter says "buildr system", then it's pretty clear > we're not going to build a 3D graphics engine. But to constrain it > has to be somewhat generic, which is why I'd like to avoid discussing > specific features. Multi-lingual is a feature we pay attention to > right now, but maybe we'll decide to stop at four languages and go > attend to something more important? > > So the charter has to be a bit more generic, but that brings a second > problem: is it testable? If it's not testable, how do we know we're > on the right path? "Build system" is broad but testable. > "Scripting-based" is broad and testable. It does open up the > possibility for other scripting language, so maybe it should be > "Ruby-based" or maybe it should remain no more specific than > "scripting-based"? > > But something about the last three "DRY, convenience and flexibility", > I'm not 100% sure about. > > I like the fact that in Buildr, if you need to copy a file and add an > SHA1 digest you just write a couple of lines to do that. You don't > need to search for a pre-defined task or plugin or write one yourself. > There's a bit more of the scripting/DIY/self-service/UNIX mentality > to it, that you won't see in XML-based build tools. That's why it's > using a scripting language. > > It's trying to minimize what you have to write to only that which is > "interesting" or specific to your build. Buildr is not the first to > aspire to that goal, we just know it does a better job than Ant and > Maven. That comes from being DRY, CoC, sane defaults, and using a > language that lets you express things concisely and dynamically. I > think there's a bigger principle for that. > > Like all other build system, we spend a lot of effort reducing your > buildfile into the shortest declarative definition of the build. But > unlike other build system, we're not afraid to mix it with imperative > code. The goal is to use declarative style when it adds value, not to > eliminate it altogether, and certainly not to force you into a mess of > configuration/profiles/goals/phases/plugins/properties all so you can > implement a simple if/else. > > So to begin with, we need to decide if there are some general and > testable goals in these statements, if we think they capture the > spirit of Buildr -- I'm proposing these because that's what got me > started -- and is there any way we can write them into the short/sweet > statement you proposed? > > Assaf > >> >> 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. >>> >> >
