Graduation process

[Matthieu Riou-5]

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

[Alex Boisvert-3]

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

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

[Matthieu Riou-5]

On Tue, Sep 23, 2008 at 8:59 AM, Alex Boisvert <boisvert@...> 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.

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

[Assaf Arkin]

On Tue, Sep 23, 2008 at 10:44 AM, Matthieu Riou <matthieu@...> wrote:

> On Tue, Sep 23, 2008 at 8:59 AM, Alex Boisvert <boisvert@...> 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.

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

[Matthieu Riou-5]

On Tue, Sep 23, 2008 at 11:08 AM, Assaf Arkin <arkin@...> wrote:

> On Tue, Sep 23, 2008 at 10:44 AM, Matthieu Riou <matthieu@...>
> wrote:
> > On Tue, Sep 23, 2008 at 8:59 AM, Alex Boisvert <boisvert@...>
> 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@...
> >> >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
> >> >
> >>
> >
>

[Victor Hugo Borja]

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@...>wrote:

> On Tue, Sep 23, 2008 at 11:08 AM, Assaf Arkin <arkin@...> wrote:
>
> > On Tue, Sep 23, 2008 at 10:44 AM, Matthieu Riou <matthieu@...>
> > wrote:
> > > On Tue, Sep 23, 2008 at 8:59 AM, Alex Boisvert <boisvert@...>
> > 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@...
> > >> >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.

[Tal Rotbart]

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 <vic.borja@...> 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@...>wrote:
>
>> On Tue, Sep 23, 2008 at 11:08 AM, Assaf Arkin <arkin@...> wrote:
>>
>> > On Tue, Sep 23, 2008 at 10:44 AM, Matthieu Riou <matthieu@...>
>> > wrote:
>> > > On Tue, Sep 23, 2008 at 8:59 AM, Alex Boisvert <boisvert@...>
>> > 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@...
>> > >> >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.
>

[Assaf Arkin]

On Tue, Sep 23, 2008 at 5:20 PM, Tal Rotbart <redbeard@...> 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@...> 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@...>wrote:
>>
>>> On Tue, Sep 23, 2008 at 11:08 AM, Assaf Arkin <arkin@...> wrote:
>>>
>>> > On Tue, Sep 23, 2008 at 10:44 AM, Matthieu Riou <matthieu@...>
>>> > wrote:
>>> > > On Tue, Sep 23, 2008 at 8:59 AM, Alex Boisvert <boisvert@...>
>>> > 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@...
>>> > >> >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.
>>
>

[Tal Rotbart]

"... 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@...> wrote:

> On Tue, Sep 23, 2008 at 5:20 PM, Tal Rotbart <redbeard@...> 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@...> 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@...>wrote:
>>>
>>>> On Tue, Sep 23, 2008 at 11:08 AM, Assaf Arkin <arkin@...> wrote:
>>>>
>>>> > On Tue, Sep 23, 2008 at 10:44 AM, Matthieu Riou <matthieu@...>
>>>> > wrote:
>>>> > > On Tue, Sep 23, 2008 at 8:59 AM, Alex Boisvert <boisvert@...>
>>>> > 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@...
>>>> > >> >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.
>>>
>>
>

[Assaf Arkin]

On Sep 23, 2008, at 6:17 PM, "Tal Rotbart" <redbeard@...> 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@...>  
> wrote:
>> On Tue, Sep 23, 2008 at 5:20 PM, Tal Rotbart <redbeard@...>  
>> 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@...
>>> > 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@...
>>>> >wrote:
>>>>
>>>>> On Tue, Sep 23, 2008 at 11:08 AM, Assaf Arkin  
>>>>> <arkin@...> wrote:
>>>>>
>>>>>> On Tue, Sep 23, 2008 at 10:44 AM, Matthieu Riou <matthieu@...
>>>>>> >
>>>>>> wrote:
>>>>>>> On Tue, Sep 23, 2008 at 8:59 AM, Alex Boisvert <boisvert@...
>>>>>>> >
>>>>>> 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@...
>>>>>>>>> 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.
>>>>
>>>
>>

[Jim Jagielski]

On Sep 23, 2008, at 9:50 PM, Assaf Arkin wrote:

>
> On Sep 23, 2008, at 6:17 PM, "Tal Rotbart" <redbeard@...> 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
>

We can't really be serious about that, right?

In general, the charter should not be recursive, but also
not so detailed that the project can't grow.

How about:

a scripting-based build system for applications with
sophisticated dependency management.

??

[Assaf Arkin]

On Fri, Sep 26, 2008 at 6:23 AM, Jim Jagielski <jim@...> wrote:

>
> On Sep 23, 2008, at 9:50 PM, Assaf Arkin wrote:
>
>>
>> On Sep 23, 2008, at 6:17 PM, "Tal Rotbart" <redbeard@...> 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
>>
>
> We can't really be serious about that, right?

I don't have a problem injecting a bit of humor.  Software should be,
besides all the other boring requirements, also fun to use, enjoyable,
something you look forward to on a Monday morning.

It should also have a philosophy, and a good charter would focus on
what the software is, rather than what it does.  BTW right now
Buildr's tagline is "a build system that doesn't suck".

Assaf

>
> In general, the charter should not be recursive, but also
> not so detailed that the project can't grow.
>
> How about:
>
> a scripting-based build system for applications with
> sophisticated dependency management.
>
> ??
>
>

[Matthieu Riou-5]

On Fri, Sep 26, 2008 at 5:58 PM, Assaf Arkin <arkin@...> wrote:

> On Fri, Sep 26, 2008 at 6:23 AM, Jim Jagielski <jim@...> wrote:
> >
> > On Sep 23, 2008, at 9:50 PM, Assaf Arkin wrote:
> >
> >>
> >> On Sep 23, 2008, at 6:17 PM, "Tal Rotbart" <redbeard@...> 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
> >>
> >
> > We can't really be serious about that, right?
>
> I don't have a problem injecting a bit of humor.  Software should be,
> besides all the other boring requirements, also fun to use, enjoyable,
> something you look forward to on a Monday morning.
>

I'm fine with humor too but the charter will stick around for quite a while
(as long as possible actually) and there are some jokes that tend to grow
old. So I liked the first version better:

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

Maybe the "convenience and flexibility" could be replaced by something a bit
more focused but until that I like it. Is "agile" too overloaded?

Matthieu

> It should also have a philosophy, and a good charter would focus on
> what the software is, rather than what it does.  BTW right now
> Buildr's tagline is "a build system that doesn't suck".
>
> Assaf
>
> >
> > In general, the charter should not be recursive, but also
> > not so detailed that the project can't grow.
> >
> > How about:
> >
> > a scripting-based build system for applications with
> > sophisticated dependency management.
> >
> > ??
> >
> >
>

[Alex Boisvert-3]

Here's another take...

"[...] that the Apache Buildr project be responsible for the creation and
maintenance of a Ruby-based build system that is quick and easy for small
jobs, extensible and customizable for do-it-yourself handywork, and yet
suitable for larger multi-lingual, multi-project constructions."

alex

[Jim Jagielski]

On Sep 26, 2008, at 8:58 PM, Assaf Arkin wrote:

> On Fri, Sep 26, 2008 at 6:23 AM, Jim Jagielski <jim@...>  
> wrote:
>>
>> On Sep 23, 2008, at 9:50 PM, Assaf Arkin wrote:
>>
>>>
>>> On Sep 23, 2008, at 6:17 PM, "Tal Rotbart" <redbeard@...>  
>>> 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
>>>
>>
>> We can't really be serious about that, right?
>
> I don't have a problem injecting a bit of humor.  Software should be,
> besides all the other boring requirements, also fun to use, enjoyable,
> something you look forward to on a Monday morning.
>
> It should also have a philosophy, and a good charter would focus on
> what the software is, rather than what it does.  BTW right now
> Buildr's tagline is "a build system that doesn't suck".
>

Recall that the resolution is a formal, legal vehicle which
creates the PMC within the ASF. The resolution isn't a place
for marketing the project or the codebase, but simply to
define what it is.

[Matthieu Riou-5]

I'm fine with this one, unless somebody objects (nobody hasn't so far), what
about using this one for the board resolution we'll vote on?

Cheers,
Matthieu

On Sat, Sep 27, 2008 at 12:02 AM, Alex Boisvert <boisvert@...>wrote:

> Here's another take...
>
> "[...] that the Apache Buildr project be responsible for the creation and
> maintenance of a Ruby-based build system that is quick and easy for small
> jobs, extensible and customizable for do-it-yourself handywork, and yet
> suitable for larger multi-lingual, multi-project constructions."
>
> alex
>

[Matthieu Riou-5]

On Tue, Oct 14, 2008 at 5:06 PM, Matthieu Riou <matthieu@...>wrote:

> I'm fine with this one, unless somebody objects (nobody hasn't so far),
> what about using this one for the board resolution we'll vote on?
>

:%s/nobody hasn't/nobody has/

>
> Cheers,
> Matthieu
>
>
> On Sat, Sep 27, 2008 at 12:02 AM, Alex Boisvert <boisvert@...>wrote:
>
>> Here's another take...
>>
>> "[...] that the Apache Buildr project be responsible for the creation and
>> maintenance of a Ruby-based build system that is quick and easy for small
>> jobs, extensible and customizable for do-it-yourself handywork, and yet
>> suitable for larger multi-lingual, multi-project constructions."
>>
>> alex
>>
>
>

[Assaf Arkin]

On Tue, Oct 14, 2008 at 5:06 PM, Matthieu Riou <matthieu@...> wrote:
> I'm fine with this one, unless somebody objects (nobody hasn't so far), what
> about using this one for the board resolution we'll vote on?

+1

Assaf

>
> Cheers,
> Matthieu
>
> On Sat, Sep 27, 2008 at 12:02 AM, Alex Boisvert <boisvert@...>wrote:
>
>> Here's another take...
>>
>> "[...] that the Apache Buildr project be responsible for the creation and
>> maintenance of a Ruby-based build system that is quick and easy for small
>> jobs, extensible and customizable for do-it-yourself handywork, and yet
>> suitable for larger multi-lingual, multi-project constructions."
>>
>> alex
>>
>

[lacton]

On Wed, Oct 15, 2008 at 2:11 AM, Assaf Arkin <arkin@...> wrote:
> On Tue, Oct 14, 2008 at 5:06 PM, Matthieu Riou <matthieu@...> wrote:
>> I'm fine with this one, unless somebody objects (nobody hasn't so far), what
>> about using this one for the board resolution we'll vote on?
>
> +1

+1

Lacton

> Assaf
>
>
>>
>> Cheers,
>> Matthieu
>>
>> On Sat, Sep 27, 2008 at 12:02 AM, Alex Boisvert <boisvert@...>wrote:
>>
>>> Here's another take...
>>>
>>> "[...] that the Apache Buildr project be responsible for the creation and
>>> maintenance of a Ruby-based build system that is quick and easy for small
>>> jobs, extensible and customizable for do-it-yourself handywork, and yet
>>> suitable for larger multi-lingual, multi-project constructions."
>>>
>>> alex
>>>
>>