Hello Bruno. I appreciate the detailed explanation. Yes, you right - we have picked 1.0.3 because it was the most advanced 1.x release at the date - I missed that part.
As for the formalities and the procedure - I don't have an educated opinion on these matters, because I am not a part of ASF in any way. So, I am sure you are painting a correct picture here. We are going to be offering our support for BigTop in the form of patches in the future. But I am not sure we can stick the same release pace or set of comprising components. Thanks for the information, at any rate. Good luck! Alef Magna Tempus Group On Wed, Aug 29, 2012 at 11:02PM, Bruno MahИ wrote: > Hi Alef, > > Please see my reply inline. > > > >Bruno, > > > >the reason we have put this patch (OOZIE-810) and another one fixing > >dependencies in the Hadoop (HADOOP-8417) because without these the stack > >wasn't functional. > > > >We could not publish non-working bits - it would completely negate the > >purpose > >of it. > > > > I completely understand your need for backporting patches, but Magna > Tempus Group release contains a different version of Apache Hadoop > to which HADOOP-8417 only seems to apply to (the ticket only lists > Apache Hadoop 1.0.3). And Apache Bigtop (incubating) 0.3.0 only > ships with Apache Hadoop 1.0.1. So this issue may or may not apply. > > But I don't recall anyone mentioning on our mailing-lists/ticket > tracking system any of these issues since the release of Apache > Bigtop (incubating) [Except on Cos' bom]. > Instead of asking the Apache Bigtop (incubating) community to > advertise your fork as the convenience artefacts of Apache Bigtop > (incubating) releases, I would rather recommend to open tickets so > we can keep track of these issues and help us cut a release. This > way, we can all help you and you don't have the burden of > maintaining your own fork. > > > > >I see your point about not referring a derivatives of BigTop through the > >Apache dist. Now, if I remember correctly (and I am in no position to lecture > >people here), Apache project releases consist of source code; binaries are > >published pretty much as a courtesy of a release manager. If so - and please > >correct me if I am wrong - then Magna Tempus Group release is equivalent to > >that of BigTop and only provides convenience artifacts for the consumption > >of > >the end users. > > > > Magna Tempus Group releases are not equivalent to that of Apache > Bigtop (incubating). You are not building from a release of Apache > Bigtop (incubating), you are building a fork of Apache Bigtop > (incubating). > You have components of different versions as well as backported > patches. Backported patches also do go against Apache Bigtop > (incubating) practices. > > > >At any rate, it is up to the people in the project to make the decision. > > > >Regards, > > Alef. > > > > This is not really up to the people in the project to make the > decision since by definition, the convenience artefacts are about > the release, not random bits. > See http://www.apache.org/dev/release.html#what : > "In some cases, binary/bytecode packages are also produced as a > convenience to users that might not have the appropriate tools to > build a compiled version of the source. In all such cases, the > binary/bytecode package must have the same version number as the > source release and may only add binary/bytecode files that are the > result of compiling that version of the source code release." > > > Thanks, > Bruno
