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
