You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Konstantin Boudnik <co...@apache.org> on 2012/09/03 23:14:48 UTC
Re: [VOTE] Bigtop 0.3.1: target release date, supported platforms,
bill of materials
As per another comment in that thread, I am not sure if it is a good idea to
include branch-new components to a maintenance release. I believe, the
question is similar to "shall we introduce new OS versions in a maintenance
release".
Thoughts!
I'd appreciate some feedback from the community because I want to restart
voting thread for 0.3.1 release.
With regards,
Cos
On Fri, Aug 31, 2012 at 11:10AM, Arun C Murthy wrote:
> Sorry, missed this. A vote is currently in progress. Thanks.
>
> On Aug 27, 2012, at 10:14 AM, Konstantin Boudnik wrote:
>
> > Do you happen to know their release time-frame, Arun?
> >
> > Cos
> >
> > On Sun, Aug 26, 2012 at 11:56PM, Arun C Murthy wrote:
> >>
> >> On Aug 26, 2012, at 11:54 PM, Arun C Murthy wrote:
> >>
> >>> Looks great Cos. May I suggest bumping up to Flume 1.x ? x=2?
> >>>
> >>
> >> Also, we maybe able to convince Ambari folks to make a release by then - how abt including that too?
> >>
> >> thanks,
> >> Arun
> >>
> >>>
> >>> On Aug 24, 2012, at 11:23 AM, Konstantin Boudnik wrote:
> >>>
> >>>> Please vote on the proposed content for 0.3.1 release. The vote will
> >>>> close on Friday 08/31/12 11:59pm PST. This is just a VOTE thread.
> >>>>
> >>>> Release date:
> >>>> * Sep 2012
> >>>>
> >>>> Supported platforms
> >>>> * CentOS 6
> >>>> * Ubuntu LTS Lucid 10.04
> >>>> * OpenSUSE 11.4
> >>>> * Fedora 16
> >>>>
> >>>> Proposed bill of materials:
> >>>> * HCatalog 0.2.0
> >>>> * Sqoop 1.4.1
> >>>> * Zookeeper 3.4.3
> >>>> * Hadoop 1.1 (contingent on the component release)
> >>>> * HBase 0.92
> >>>> * Oozie 3.1.3 (upgrade, contingent on OOZIE-810)
> >>>> * Whirr 0.7.1
> >>>> * Hive 0.8.1
> >>>> * Pig 0.9.2
> >>>> * Mahout 0.6.1
> >>>> * Flume 0.9.3
> >>>
> >>> --
> >>> Arun C. Murthy
> >>> Hortonworks Inc.
> >>> http://hortonworks.com/
> >>>
> >>>
> >>
> >> --
> >> Arun C. Murthy
> >> Hortonworks Inc.
> >> http://hortonworks.com/
> >>
> >>
>
> --
> Arun C. Murthy
> Hortonworks Inc.
> http://hortonworks.com/
>
>
Re: [VOTE] Bigtop 0.3.1: target release date, supported platforms,
bill of materials
Posted by Konstantin Boudnik <co...@apache.org>.
On Thu, Sep 06, 2012 at 08:09AM, Alan Gates wrote:
>
> On Sep 5, 2012, at 5:50 PM, Roman Shaposhnik wrote:
>
> > On Tue, Sep 4, 2012 at 6:00 PM, Alan Gates <ga...@hortonworks.com> wrote:
> >> Doing this leaves new projects wedged. Not many people are on Hadoop 2.0 yet.
> >> Thus a lot of projects (including new ones like Ambari) are focussed on Hadoop 1.0.
> >> If you say you will only take new projects on your trunk, but your trunk is focussed
> >> on code most people haven't migrated to yet it seems you're limiting both Bigtop and new projects.
> >
> > Two comments:
> > * it would be very nice if Hadoop offered MapReduce independently
> > of HDFS. At this
> > point I'd say that users are way better off with HDFS coming
> > from Hadoop 2.0 codeline,
> > while the jury is still out on YARN wrt. operational stability
> > as compared to Hadoop 1.0.
> > Thus, if only we had an option of mixing and matching the 2 --
> > that would have offered
> > the best of both worlds.
> All that's being hashed out in the Hadoop community at the moment, though
> the momentum seems to be with staying together for now. Even if they split
> the project tomorrow there are still a lot of people using Hadoop 1.x (and
> 20.x, and ...) who will be in no hurry to upgrade, thus there will be
> projects wanting to target that line for a while.
>
> > * I agree with Cos/Bruno that perhaps it is not worth upsetting
> > Bigtop 0.3.0 line, if only
> > because of optics and perception. Perhaps the right question to
> > ask (on a different
> > thread) is whether Bigtop needs to accommodate a sort of
> > even/odd release mentality of a
> > Linux kernel.
> I'm not sure what optics you're worried about here. Just add new projects
> and mark them as alpha or experimental or whatever until they've gone
> through a few releases. But whatever. If we believe it's better to have a
> Bigtop 5.x that is Hadoop 1.x plus newer projects that seems fine. We just
> need some way to push out newer projects that are based on older Hadoop.
I think the optics in question is how stable a release line looks to the
outside world. Adding experimental or unstable components might not be
favorably perceived by the potential consumers of the artifacts.
However, I see the danger of a potential isolation if nothing new but updates
are added up to a stack. So, perhaps a balanced approach like one Roman has
mentioned earlier is a very good way forward.
Cos
Re: [VOTE] Bigtop 0.3.1: target release date, supported platforms, bill of materials
Posted by Alan Gates <ga...@hortonworks.com>.
On Sep 5, 2012, at 5:50 PM, Roman Shaposhnik wrote:
> On Tue, Sep 4, 2012 at 6:00 PM, Alan Gates <ga...@hortonworks.com> wrote:
>> Doing this leaves new projects wedged. Not many people are on Hadoop 2.0 yet.
>> Thus a lot of projects (including new ones like Ambari) are focussed on Hadoop 1.0.
>> If you say you will only take new projects on your trunk, but your trunk is focussed
>> on code most people haven't migrated to yet it seems you're limiting both Bigtop and new projects.
>
> Two comments:
> * it would be very nice if Hadoop offered MapReduce independently
> of HDFS. At this
> point I'd say that users are way better off with HDFS coming
> from Hadoop 2.0 codeline,
> while the jury is still out on YARN wrt. operational stability
> as compared to Hadoop 1.0.
> Thus, if only we had an option of mixing and matching the 2 --
> that would have offered
> the best of both worlds.
All that's being hashed out in the Hadoop community at the moment, though the momentum seems to be with staying together for now. Even if they split the project tomorrow there are still a lot of people using Hadoop 1.x (and 20.x, and ...) who will be in no hurry to upgrade, thus there will be projects wanting to target that line for a while.
> * I agree with Cos/Bruno that perhaps it is not worth upsetting
> Bigtop 0.3.0 line, if only
> because of optics and perception. Perhaps the right question to
> ask (on a different
> thread) is whether Bigtop needs to accommodate a sort of
> even/odd release mentality of a
> Linux kernel.
I'm not sure what optics you're worried about here. Just add new projects and mark them as alpha or experimental or whatever until they've gone through a few releases. But whatever. If we believe it's better to have a Bigtop 5.x that is Hadoop 1.x plus newer projects that seems fine. We just need some way to push out newer projects that are based on older Hadoop.
Alan.
>
> Thanks,
> Roman.
Re: [VOTE] Bigtop 0.3.1: target release date, supported platforms,
bill of materials
Posted by Konstantin Boudnik <co...@apache.org>.
On Wed, Sep 05, 2012 at 05:50PM, Roman Shaposhnik wrote:
> On Tue, Sep 4, 2012 at 6:00 PM, Alan Gates <ga...@hortonworks.com> wrote:
> > Doing this leaves new projects wedged. Not many people are on Hadoop 2.0 yet.
> > Thus a lot of projects (including new ones like Ambari) are focussed on Hadoop 1.0.
> > If you say you will only take new projects on your trunk, but your trunk is focussed
> > on code most people haven't migrated to yet it seems you're limiting both Bigtop and new projects.
>
> Two comments:
> * it would be very nice if Hadoop offered MapReduce independently
> of HDFS. At this
> point I'd say that users are way better off with HDFS coming
> from Hadoop 2.0 codeline,
> while the jury is still out on YARN wrt. operational stability
> as compared to Hadoop 1.0.
> Thus, if only we had an option of mixing and matching the 2 --
> that would have offered
> the best of both worlds.
> * I agree with Cos/Bruno that perhaps it is not worth upsetting
> Bigtop 0.3.0 line, if only
> because of optics and perception. Perhaps the right question to
> ask (on a different
> thread) is whether Bigtop needs to accommodate a sort of even/odd
> release mentality of a Linux kernel.
I actually like the idea about even/releases. On one hand it gives us a way of
keeping a stable releases line (updates only); and having a line where new
components (in alpha version or whatever) can be added for those who are
willing to experiment.
In the hind side, locking the line forever doesn't look like viable approach
in the long run.
Cos
Re: [VOTE] Bigtop 0.3.1: target release date, supported platforms,
bill of materials
Posted by Roman Shaposhnik <rv...@apache.org>.
On Tue, Sep 4, 2012 at 6:00 PM, Alan Gates <ga...@hortonworks.com> wrote:
> Doing this leaves new projects wedged. Not many people are on Hadoop 2.0 yet.
> Thus a lot of projects (including new ones like Ambari) are focussed on Hadoop 1.0.
> If you say you will only take new projects on your trunk, but your trunk is focussed
> on code most people haven't migrated to yet it seems you're limiting both Bigtop and new projects.
Two comments:
* it would be very nice if Hadoop offered MapReduce independently
of HDFS. At this
point I'd say that users are way better off with HDFS coming
from Hadoop 2.0 codeline,
while the jury is still out on YARN wrt. operational stability
as compared to Hadoop 1.0.
Thus, if only we had an option of mixing and matching the 2 --
that would have offered
the best of both worlds.
* I agree with Cos/Bruno that perhaps it is not worth upsetting
Bigtop 0.3.0 line, if only
because of optics and perception. Perhaps the right question to
ask (on a different
thread) is whether Bigtop needs to accommodate a sort of
even/odd release mentality of a
Linux kernel.
Thanks,
Roman.
Re: [VOTE] Bigtop 0.3.1: target release date, supported platforms, bill of materials
Posted by Alan Gates <ga...@hortonworks.com>.
Doing this leaves new projects wedged. Not many people are on Hadoop 2.0 yet. Thus a lot of projects (including new ones like Ambari) are focussed on Hadoop 1.0. If you say you will only take new projects on your trunk, but your trunk is focussed on code most people haven't migrated to yet it seems you're limiting both Bigtop and new projects.
Alan.
On Sep 3, 2012, at 2:14 PM, Konstantin Boudnik wrote:
> As per another comment in that thread, I am not sure if it is a good idea to
> include branch-new components to a maintenance release. I believe, the
> question is similar to "shall we introduce new OS versions in a maintenance
> release".
>
> Thoughts!
>
> I'd appreciate some feedback from the community because I want to restart
> voting thread for 0.3.1 release.
>
> With regards,
> Cos
>
> On Fri, Aug 31, 2012 at 11:10AM, Arun C Murthy wrote:
>> Sorry, missed this. A vote is currently in progress. Thanks.
>>
>> On Aug 27, 2012, at 10:14 AM, Konstantin Boudnik wrote:
>>
>>> Do you happen to know their release time-frame, Arun?
>>>
>>> Cos
>>>
>>> On Sun, Aug 26, 2012 at 11:56PM, Arun C Murthy wrote:
>>>>
>>>> On Aug 26, 2012, at 11:54 PM, Arun C Murthy wrote:
>>>>
>>>>> Looks great Cos. May I suggest bumping up to Flume 1.x ? x=2?
>>>>>
>>>>
>>>> Also, we maybe able to convince Ambari folks to make a release by then - how abt including that too?
>>>>
>>>> thanks,
>>>> Arun
>>>>
>>>>>
>>>>> On Aug 24, 2012, at 11:23 AM, Konstantin Boudnik wrote:
>>>>>
>>>>>> Please vote on the proposed content for 0.3.1 release. The vote will
>>>>>> close on Friday 08/31/12 11:59pm PST. This is just a VOTE thread.
>>>>>>
>>>>>> Release date:
>>>>>> * Sep 2012
>>>>>>
>>>>>> Supported platforms
>>>>>> * CentOS 6
>>>>>> * Ubuntu LTS Lucid 10.04
>>>>>> * OpenSUSE 11.4
>>>>>> * Fedora 16
>>>>>>
>>>>>> Proposed bill of materials:
>>>>>> * HCatalog 0.2.0
>>>>>> * Sqoop 1.4.1
>>>>>> * Zookeeper 3.4.3
>>>>>> * Hadoop 1.1 (contingent on the component release)
>>>>>> * HBase 0.92
>>>>>> * Oozie 3.1.3 (upgrade, contingent on OOZIE-810)
>>>>>> * Whirr 0.7.1
>>>>>> * Hive 0.8.1
>>>>>> * Pig 0.9.2
>>>>>> * Mahout 0.6.1
>>>>>> * Flume 0.9.3
>>>>>
>>>>> --
>>>>> Arun C. Murthy
>>>>> Hortonworks Inc.
>>>>> http://hortonworks.com/
>>>>>
>>>>>
>>>>
>>>> --
>>>> Arun C. Murthy
>>>> Hortonworks Inc.
>>>> http://hortonworks.com/
>>>>
>>>>
>>
>> --
>> Arun C. Murthy
>> Hortonworks Inc.
>> http://hortonworks.com/
>>
>>
Re: [VOTE] Bigtop 0.3.1: target release date, supported platforms,
bill of materials
Posted by Konstantin Boudnik <co...@apache.org>.
s/branch-new/brand-new/ - sorry
On Mon, Sep 03, 2012 at 02:14PM, Konstantin Boudnik wrote:
> As per another comment in that thread, I am not sure if it is a good idea to
> include branch-new components to a maintenance release. I believe, the
> question is similar to "shall we introduce new OS versions in a maintenance
> release".
>
> Thoughts!
>
> I'd appreciate some feedback from the community because I want to restart
> voting thread for 0.3.1 release.
>
> With regards,
> Cos
>
> On Fri, Aug 31, 2012 at 11:10AM, Arun C Murthy wrote:
> > Sorry, missed this. A vote is currently in progress. Thanks.
> >
> > On Aug 27, 2012, at 10:14 AM, Konstantin Boudnik wrote:
> >
> > > Do you happen to know their release time-frame, Arun?
> > >
> > > Cos
> > >
> > > On Sun, Aug 26, 2012 at 11:56PM, Arun C Murthy wrote:
> > >>
> > >> On Aug 26, 2012, at 11:54 PM, Arun C Murthy wrote:
> > >>
> > >>> Looks great Cos. May I suggest bumping up to Flume 1.x ? x=2?
> > >>>
> > >>
> > >> Also, we maybe able to convince Ambari folks to make a release by then - how abt including that too?
> > >>
> > >> thanks,
> > >> Arun
> > >>
> > >>>
> > >>> On Aug 24, 2012, at 11:23 AM, Konstantin Boudnik wrote:
> > >>>
> > >>>> Please vote on the proposed content for 0.3.1 release. The vote will
> > >>>> close on Friday 08/31/12 11:59pm PST. This is just a VOTE thread.
> > >>>>
> > >>>> Release date:
> > >>>> * Sep 2012
> > >>>>
> > >>>> Supported platforms
> > >>>> * CentOS 6
> > >>>> * Ubuntu LTS Lucid 10.04
> > >>>> * OpenSUSE 11.4
> > >>>> * Fedora 16
> > >>>>
> > >>>> Proposed bill of materials:
> > >>>> * HCatalog 0.2.0
> > >>>> * Sqoop 1.4.1
> > >>>> * Zookeeper 3.4.3
> > >>>> * Hadoop 1.1 (contingent on the component release)
> > >>>> * HBase 0.92
> > >>>> * Oozie 3.1.3 (upgrade, contingent on OOZIE-810)
> > >>>> * Whirr 0.7.1
> > >>>> * Hive 0.8.1
> > >>>> * Pig 0.9.2
> > >>>> * Mahout 0.6.1
> > >>>> * Flume 0.9.3
> > >>>
> > >>> --
> > >>> Arun C. Murthy
> > >>> Hortonworks Inc.
> > >>> http://hortonworks.com/
> > >>>
> > >>>
> > >>
> > >> --
> > >> Arun C. Murthy
> > >> Hortonworks Inc.
> > >> http://hortonworks.com/
> > >>
> > >>
> >
> > --
> > Arun C. Murthy
> > Hortonworks Inc.
> > http://hortonworks.com/
> >
> >