buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@intalio.com>
Subject Re: Graduation process
Date Wed, 24 Sep 2008 01:50:37 GMT

On Sep 23, 2008, at 6:17 PM, "Tal Rotbart" <redbeard@gmail.com> wrote:

> "... 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

+1

Assaf

>
>
> 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