incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: Now that 0.2.0 is out...
Date Thu, 17 Nov 2011 07:12:56 GMT
1. date-driven realease schedule is a double-edge sword, really. 
   What if time for a release came but there's no significant changes in the
   upstream component worthy adding? Are we then switch to one-off
   feature-driven schedule and postpone one at hands?

2. Ubuntu's +04 and +10 versions have different maintanance model behind.
   Unless you are proposing something similar I don't a real compelling reason
   to do that. It's gonna be confusing IMO, however I don't feel strongly one
   way or another if you guys want to be fancy like that ;)

   As for code names: I never been able to say what the hell is Lucis and
   which one is Merkat. However, I know that I am running 10.04 on most of my
   hosts and 11.04 of a laptop. And this is information enough, in my opinion.
   I'd say having internal code names are fun - making them public is - again
   - simply confusing.

   Also, Greece is a place which now has a bad stench of "Democracy: the god
   which failed" and with all due respect Roman - not everyone believe in your gods :D

and more below...

On Wed, Nov 16, 2011 at 01:54PM, Roman Shaposhnik wrote:
> ...it is time to start thinking about 0.3.0 (and beyond!) ;-)
> 
> I will list some ideas I have in this email thread and if there's
> traction, we can put a few of them up to a VOTE.
> 
> * Bigtop release model
> 
>    1. I really would like Bigtop to have a quarterly release schedule.
>    It is true that date-driven release are frowned upon by Apache
>    in general, but I think this model works well for Bigtop.
> 
>    2. For any project that follows a fixed date-driven schedule the
>    versioning model that Ubuntu has come up with makes the most
>    sense as far as I'm concerned (year.month). I've also grown fond
>    of given releases names (e.g. "Lucid Lynx").  Perhaps we can name
>    Bigtop releases by Greek/Roman gods. Or may be it should be animals
>    (since it is Bigtop after all!) -- chime in if you have a good suggestion
> 
>    3. On a more serious note, I would like to propose that we reserve
> backporting
>    activity (and any  chance of releasing from an already released branches) to
>    dealing with catastrophic events. Things like security breaches,
> etc. Basically, no
>    backports unless absolutely necessary.

3. +1 on that: backport are for critical fixes only and only as a thing of last resort

> * Bigtop and Hadoop 0.23/0.22-based distributions
> 
>     1. Given the uncertainty around release of  downstream components compatible
>     with the MR2 APIs it is highly unlikely that the next *release* of
> Bigtop will be
>     in a position to use 0.23/0.22.
> 
>     2. That said, we will continue working on those releases in two
> long lived branches
>     hadoop-0.23/hadoop-0.22. So far we haven't had any clear policy on how to
>     handle commits going into those branches. So far I'm aware of 3
> major things that
>     we need to agree upon (chime in, if there's more):
>          * how frequently to rebase them on trunk
>                    >>> I propose weekly

I'd say it doesn't really matter and the rebases should be happening whenever
one commits to these branches, really.

>          * what's the JIRA version for filing issues against them
>                    >>> I propose esignated versions hadoop-0.23/hadoop-0.22
>          * what's the review/commit policy
>                    >>> I propose the usual one we have for Bigtop:
> file a JIRA, get a +1

Yup, makes sense.

> * Bigtop as a place for integration testing of RCs
> 
>     1. We are getting a reasonable traction with downstream
> communities turning to
>     Bigtop for integration testing of their RCs. It would be nice to
> have a formal policy
>     on how we can accommodate these requests. So far, I've been using a fork of
>     Bigtop on Github to do ad-hoc builds and validation, but perhaps
> we can have
>     long-lived branch for that, or may be there's a better option. Let
> me know what
>     do you think.

can we do a parametrized stack where we can set the versions of included
components separately from BigTop's pom and read them at the runtime?  I guess
Gradle would solve this problem for us but for now we might have to go with
some inlined Groovy hacks.

Cos

> Thanks,
> Roman.

Mime
View raw message