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
