incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Mahé <>
Subject Re: Now that 0.2.0 is out...
Date Thu, 17 Nov 2011 06:27:36 GMT
1. I would actually be rather in favour of a faster release cycle. But a
quarterly one is probably a good middle ground. This assume we don't get
strict about it. For instance an important update of one of the
component may warrant a new release.

2. I only care about monotonically increasing numbers. But codenames are
fun :)
3. It depends on how we are planning releases (hence your email).
I only care about a stable release/branch one could trust to maintain a
production grade cluster and another one where we could go forward and
experiment. I was under the impression we would be heading toward a
0.3.0 based on a next gen hadoop, which would definitely not be
production ready.
So if the consensus is not to update hadoop version for the next bigtop
release, backporting patches to the 0.2.0 branch does not make sense.
But if we plan to update hadoop to a next gen version, I will definitely
maintain and backport patches to the 0.2.0 branch. But this is
implementation details.

4. I agree completely. Although I would like also to make sure that any
patch we apply on a branch should have an upstream JIRA as a
filename/identifier so anyone can follow up on any patch and we can
ensure they all get commited upstream by the time a new upstream version
gets released.
Note that I used the term "should" and not "must" in order to make it
more of a guideline instead of a constraint.

5. Please define requests.
It seems to be more of an infrastructure issue.
I am not sure this warrant any specific process or branch to do such
thing. Although we could always help making things easier by documenting
more the build and test processes in Bigtop as well as maybe trying to
provide some parametrized jobs on our jenkins instance (where parameters
could be specific patches).

On 11/16/2011 01:54 PM, Roman Shaposhnik wrote:
> 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.
> * 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
>          * 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
> * 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.
> Thanks,
> Roman.

View raw message