Re: [DISCUSS] Setting up long term support mindset

2013-03-06 Thread Andrew Purtell
A lot of behavior among loosely coupled projects is emergent. So in that
sense some of what bigtop can produce is defined by something beyond direct
control. What you can do is try to influence the processes at work. So,
outreach to each component project. Also, constructive pressure. Publicize
bigtop as a vetted stable open packaging of Hadoop. Don't upgrade
components if there is an integration issue and an unresponsive community.
This would apply constructive pressure on the unresponsive community
commensurate with the influence of bigtop.

To grow the influence of bigtop, engaging vendors might be useful. For
those pursuing an open strategy or open core strategy then commoditizing
and amortizing the costs of baseline packaging and integration concerns
makes sense. Everybody wins because more bandwidth is available to focus on
differentiators. Such vendors typically employ committers for community
based development. If some of these vendors can publicly get behind bigtop
and invest in its credibility, then as an emergent consequence there will
be more community engagement on integration issues under its umbrella.
Everyone will win.

On some of the specific points, my humble opinion:

2. Hadoop 2 is the only long term viable option even if some parts may be
still unstable in terms of API.

3. This seems a case of build it and they will come. Iterate on a BOM
that (mostly) works. Publicize it. For integration blockers, track the
respective JIRAs on the bigtop wiki. Be polite. Be proactive. Mail the
respective dev lists with gentle reminders, but not too frequently.

4. See above.

5. You can't.

On Thursday, March 7, 2013, Roman Shaposhnik wrote:

 On Wed, Mar 6, 2013 at 10:10 AM, Konstantin Boudnik 
 c...@apache.orgjavascript:;
 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.



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)


Re: Building bigtop with patches

2013-03-06 Thread Bruno Mahé

On 03/01/2013 05:34 PM, Jagat Singh wrote:

Hello Roman,

Thank you for your answers.

I was trying to make hadoop deb with few patches and was wondering why
its not working :)

And now i know that with dep , rpm packages patches wont be picked from
patch folder. However if i want tar then i would get patches applied.

Any suggestions for making patched deb ?

Thanks once again.




Hi Jagat,

Sorry for the late reply and hope you fixed your issue by now, but in 
case you still need an answer, you can look at 
https://github.com/apache/bigtop/commit/d2d1df918406774ae3ad2489de4e2eccf8e54634


This coommit *remove* a patch to build. So the interested parts are in red.

Feel free to let us know if you need more information.

Thanks,
Bruno