No, I meant stability of the framework itself: packaging, iTest, etc. Perhaps
stability is too overloaded... robustness, perhaps?

On Tue, Jul 09, 2013 at 10:57AM, Bruno Mahe wrote:
> Bigtop as a framework? You mean stable api of its projects?
> 
> Sent from my HTC EVO 4G LTE exclusively from Sprint
> 
> ----- Reply message -----
> From: "Konstantin Boudnik" <[email protected]>
> To: <[email protected]>
> Cc: "Sean Mackrory" <[email protected]>
> Subject: [DISCUSS] BOM for release 0.7.0 of Bigtop
> Date: Tue, Jul 9, 2013 10:40
> 
> 
> Bruno,
> 
> just to clarify my stance of 'stability': it is more about stability of the
> Bigtop as a framework than a stability of the stack.
> 
> I am not sure we have resources to do maintenance releases at this point. May
> be it is just me.
> 
> Cos
> 
> On Tue, Jul 09, 2013 at 10:10AM, Bruno MahИ wrote:
> > On 07/09/2013 09:47 AM, Sean Mackrory wrote:
> >> Without wanting to detract from the spirit of focussing on system
> >> stability, I'd like to suggest a few changes I think it's time we at least
> >> discuss seriously:
> >>
> >> JDKs: I've seen a lot of people ask about JDK 7. Perhaps time to add
> >> support for Oracle JDK 7? It's working pretty well in my experience, and
> >> although it's less tested upstream, the only JDK we officially support is
> >> officially EOL, so we're not exactly in a good position now IMO.
> >>
> >> Debian 7 has also been out for a while, and I think we should do at least
> >> one release on it. It's likely very little work but I think there's value
> >> in certifying the stack will work well there. (On the topic of OS's - are
> >> we specifically talking SP3 of SLES 11?). I don't feel strongly on this,
> >> but I'm just curious if there's a reason you're suggesting staying with
> >> 12.10 and not 13.04 - other than wanting less change in this release?
> >> Again, I hardly have an opinion on that one.
> >>
> >> Other components that have recently had releases that I don't consider to
> >> impact the
> >> - Hue 2.4.0
> >> - Whirr 0.8.2
> >> - Flume 1.4.0
> >>
> >> There's also been a ticket to package Avro for a long time and I'd like to
> >> get to that soon. Perhaps Parquet as well? Although like Phoenix and
> >> DataFu, I would suggest doing just the libraries for now, not all the CLI
> >> tools.
> >>
> >> Again - I don't mean to take away from the focus on stability, but I also
> >> don't think we shouldn't stretch to stay up to date either.
> >>
> >> +1 to everything else as suggested, however.
> >>
> >>
> >> On Tue, Jul 9, 2013 at 8:59 AM, Andrew Purtell <[email protected]> wrote:
> >>> Would you be willing to consider Phoenix, only BIGTOP-993? Installing the
> >>> package produced by 993 only drops a library for HBase into
> >>> /usr/lib/phoenix, essentially the same relationship between the DataFu
> >>> package and Pig. There is follow up work that is more ambitious, for
> >>> example BIGTOP-1007, but that is not required by any means and could come
> >>> in if/whenever you are comfortable with it.
> >>>
> >>>
> >>> On Mon, Jul 8, 2013 at 8:50 PM, Konstantin Boudnik <[email protected]> 
> >>> wrote:
> >>>
> >>>> Guys,
> >>>>
> >>>> I wanna kick-off the discussion on the content of 0.7.0 BOM
> >>>> Release 0.6.0 was all about stabilization of the stack and I think we
> >> got a
> >>>> great headway on that. The following components/OS were in the frame of
> >> the
> >>>> discussion:
> >>>>      http://is.gd/H52iVe
> >>>>
> >>>> My personal take that we need to spend this release cycle working on the
> >>>> improvements in Bigtop itself: we got enough "technical debts" in the
> >>>> pipeline that have to be addressed. To name a few:
> >>>>    - testability/test coverage
> >>>>    - test framework
> >>>>    - package improvements
> >>>>    - build improvements (including performance)
> >>>>
> >>>> In order to be able to deliver a solid stack again yet improve all things
> >>>> Bigtop I'd like to focus on the latter, hence keeping the former at bay
> >> and
> >>>> limiting the component updates to the bugfix releases only (if
> >> warranted).
> >>>> E.g.
> >>>>
> >>>>      Hadoop 2.0.5 or later (stabilization branch of Hadoop 2)
> >>>>      HBase 0.94.9 (update from the Bigtop 0.6.0)
> >>>>      HCatalog 0.5.0 (same as 0.6.0, as well as following...)
> >>>>      Zookeeper 3.4.5
> >>>>      Pig 0.11.1
> >>>>      Hive 0.10.0
> >>>>      Sqoop 2
> >>>>      Oozie 3.3.2
> >>>>      Whirr 0.8.1
> >>>>      Mahout 0.7
> >>>>      Flume 1.3.1
> >>>>      Giraph 0.2.0
> >>>>      Hue 2.2.0
> >>>>      Datafu 0.0.6
> >>>>      Solr 4.2.1
> >>>>      Crunch 0.5.0
> >>>>      Tomcat 6.0.36
> >>>>      Spark 0.7.3    (it has been in the queue for a long time)
> >>>>
> >>>> Also, I'd suggest to keep the same set of OSes as last time:
> >>>>
> >>>>      CentOS/RHEL5
> >>>>      CentOS/RHEL6
> >>>>      SLES11
> >>>>      Ubuntu 12.04 (LTS)
> >>>>      Fedora 18
> >>>>      OpenSUSE 12.3
> >>>>      Ubuntu 12.10
> >>>>
> >>>> To reiterate, with a known stable version of the stack we can safely
> >> focus
> >>>> on
> >>>> the improvements to the framework and the overall system usability.
> >>>>
> >>>> Please jump on the discussion  Also, I have opened up the following JIRA
> >> to
> >>>> track the BOM update https://issues.apache.org/jira/browse/BIGTOP-1023
> >>>>
> >>>> Thanks,
> >>>>    Cos
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>>
> >>>     - Andy
> >>>
> >>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> >>> (via Tom White)
> >>
> >
> >
> > +1 to what Andrew and Sean said.
> > I would also like to add:
> > * I would also like to keep the door open for Apache Gora to come in.  
> > Someone is already working on it
> > * Fedora 19 is out and maybe 20 will be out by the time we release 0.7.0
> >
> > With regard to stability, if included all the changes listed so far seem  
> > a little bit too much, what about dedicating a 0.6.1 to stability so  
> > 0.7.0 can include all the shiny things listed above? A 0.6.1 would  
> > enable us to be more strict with the patches/fixes/updates being  
> > included as well as signaling a more stable version to users.
> >
> >
> > Thanks,
> > Bruno

Reply via email to