On 03/06/2013 01:27 PM, Roman Shaposhnik wrote:
On Wed, Mar 6, 2013 at 10:10 AM, Konstantin Boudnik <[email protected]> wrote:
I believe there's not much more to say about it, except that this is,
in my opinion, a good way to establish our project as de-facto go-to
place for community driven Hadoop based stacks and a focal point for
the integration in the ASF storage and analytics projects.

I like this idea very much! A couple of things that I'd love to hear other
chime in on:
   #1 I think it is too late to change the focus of Bigtop 0.6.0
   #2 Do we have a reasonable conviction that the beta
        release of Hadoop 2.X is withing reach?
   #3 How do we influence Hadoop community to help us
        produce the first ever LTS of Bigtop?
   #4 How do we get the downstream communities (pig, oozie, etc)
        on-board so that we can all work towards this common goal?
   #5 Suppose we do all the work in all of the downstream components,
        how can we at least make sure that there will be patch
        releases incorporating all the changes we've done?

Now, Bigtop (well, me personally at least ;-)) would be more than
willing to help on all of these with automation, testing, etc. But
we *have* to get all of the communities involved on-board with this.

Thanks,
Roman.


Hi,

It seems like there are at least two different topics meshed together:
1/ Offering a stable version of Apache Bigtop
2/ How can Apache Bigtop help raise the quality of downstream projects


Regarding 1/ I was under the impression this is what the branch 0.3.X is all about. There was some interest, but apparently not enough to get releases out. So I am all for it but I am not sure building the consensus for a LTS stamp will be enough if we don't get enough interest/people/time to have stable releases out in the first place.

As of 2/, isn't it just a matter to put in action what we talked about numerous time: having builds based of trunk/rc branches of downstream projects? But there again, this is very time consuming and we do not have that many volunteers/time. This would also not be an answer to all the issues, but that would cover quite a few. We would not be able to guarantee that issues would be fixed, but these communities would have some incentive to fix them anyway. And if they don't fix it, nothing forces us to update these projects.

Having downstream communities on board would also be very nice, but I am not sure it would be a requirement.


Thanks,
Bruno

Reply via email to