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.
