buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tal Rotbart" <redbe...@gmail.com>
Subject Re: Graduation process
Date Wed, 24 Sep 2008 01:17:10 GMT
"... 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 <arkin@intalio.com> wrote:
> On Tue, Sep 23, 2008 at 5:20 PM, Tal Rotbart <redbeard@gmail.com> 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 <vic.borja@gmail.com> 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 <matthieu@offthelip.org>wrote:
>>>
>>>> On Tue, Sep 23, 2008 at 11:08 AM, Assaf Arkin <arkin@intalio.com> wrote:
>>>>
>>>> > On Tue, Sep 23, 2008 at 10:44 AM, Matthieu Riou <matthieu@offthelip.org>
>>>> > wrote:
>>>> > > On Tue, Sep 23, 2008 at 8:59 AM, Alex Boisvert <boisvert@intalio.com>
>>>> > 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 <
>>>> matthieu@offthelip.org
>>>> > >> >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.
>>>
>>
>

Mime
View raw message