buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Victor Hugo Borja" <vic.bo...@gmail.com>
Subject Re: Graduation process
Date Tue, 23 Sep 2008 19:08:12 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message