On 08/07/2014 10:37 PM, Robbie Gemmell wrote:
On 7 August 2014 20:18, Justin Ross <[email protected]> wrote:
I'd personally be more in favor of
getting rid of the "full release" tarball and simply point folks at
subversion for that.
We can only do that once we stop it actually being 'the release'. From an
Apache point of view that archive is currently what constitutes our 'Qpid
release' and so is really what we vote on, with the other archives
(particularly the binaries) being conveniences.
We can certainly start to release e.g. the C++ or Java bits independently
in their own archives, with their own associated votes, removing those bits
from the overall archive until the point it no longer exists.
I agree that it is important to be very clear what the release is and
what a vote in its favour actually signifies, and that is perhaps a
little muddy at present.
However I doubt anyone verifies the svn export in full detail anyway, so
the ambiguity exists with or without that.
Perhaps we should move to a set of votes on specific artefacts (or sets
of artefacts) for 0.30? The vote is always on source, so any binary
artefacts are just for convenience as you say. But perhaps we could have
a separate vote for e.g. qpid-java (source release archive), qpid-cpp,
qpid-python+qpid-python-tests and qpid-tools+qpid-qmf or whatever
breakdown makes sense.
We would probably need separate tags applied for each of these, in case
the respective votes pass at different points, but I think we could live
with a single release branch for now.
An artefact that doesn't get the full 3 required +1s would not get released.
I think this would be a more accurate process for what we have now, as
well as being a useful step towards greater independence whatever that
might mean.
The extra overhead is limited to more involved - but more meaningful and
accurate - voting threads, and a more involved tagging scheme for the
release manager. I think it would be worth a try though. Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
