incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Mahé <bm...@apache.org>
Subject Re: Strategy/Planning Meetup?
Date Thu, 18 Aug 2011 20:37:17 GMT
See comments inline.

On 08/18/2011 06:47 AM, James Page wrote:
> Hi All
>
> On Thu, 2011-08-11 at 14:11 -0700, Andrew Bayer wrote:
>> Given that a bunch of us on the project are in the Bay Area, would
>> there be
>> interest in actually meeting up in person to start figuring out what
>> we want
>> to do with Bigtop going forward? Cloudera should be able to host. If
>> there
>> is interest, it'd be great if we could meet up fairly soon, I think. 
> As I won't be able to make the meeting later today here are a few of my
> thoughts on what I would like to see from Bigtop going forwards;
> apologies in advance if this is a little Ubuntu centric...
>
> 1) Standardized set of reference platforms
>
> So at the moment the website states 'Ubuntu 10.10, CentOS 5 and openSUSE
> 11.4'.  I can't speak authoritatively for CentOS or openSUSE but from an
> Ubuntu perspective having reference packages from the Bigtop suite for
> the following pattern of releases makes sense:
>
>         a) Current and Previous Long Term Support releases - currently
>         Hardy and Lucid; this allows folks using bigtop on these
>         releases of Ubuntu (every two years) to have a good support and
>         upgrade story.
>         
>         b) Current and Previous Interim/LTS releases - currently Natty
>         and Maverick - but should shift to Oneiric and Natty once the
>         next Ubuntu release is out of the door. Most people who don't
>         use LTS releases tend to upgrade more regularly so maintaining
>         more than that does not make sense - so having a good upgrade
>         path is important.
>
> Obviously where this overlaps with an LTS we can reduce the number of
> reference platforms.
>
> Adopting such a policy may mean we need to consider how packaging is
> maintained for different releases of a platform.

This seems perfectly reasonable and applicable to other GNU/Linux
distributions.
BigTop is also a volunteer driven project, so we need to make sure we
have enough people volunteering to help with these distributions. I can
help with some, but will not have time for all of them. My personal
focus would be on latest ubuntu, debian, centos, fedora, mageia and
openSUSE.

Given we can't patch for build or security issues, we may also need to
decide what to do if a new release of a project can't be built on some
of the platforms we care about. My guess is we would work with upstream
project to fix it for next release and skip that broken release in BigTop.

> 2) Alternative architectures
>
> ARM on server is getting alot of attention ATM even though 'real'
> hardware is not currently in production - this is probably just one
> example but maybe we should give consideration to testing Bigtop on non-
> x86 architectures as well.

Sounds like fun. I would be interested in helping with that.

You may also be interested in this thread:
http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201105.mbox/ajax/%3CBANLkTi=0Duq1YO48Jj+bxMQ1F_Qo3Tt_Fg@mail.gmail.com%3E


> 3) Published Packages
>
> For the reference platforms and architectures that we build for/test
> should we publish the resulting package artefacts officially?

>From my understanding and discussions with some mentors, Apache only
cares about the source artifact. So packages would be some convenience
artifacts.
But this sounds like a great idea.


> Anyway - that was just a few of the things I had swilling around in my
> head.
>
> Hope that todays meeting is productive (and that I can join the next
> one!).
>
> Cheers
>
> James
>


Mime
View raw message