incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <...@apache.org>
Subject Now that 0.2.0 is out...
Date Wed, 16 Nov 2011 21:54:56 GMT
...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.

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

Mime
View raw message