On 08/08/2014 10:46 AM, Robbie Gemmell wrote:
I am in favour of having targeted source release archives, each with the
own votes and tags.
I would have preferred to reorganise the tree a bit first before beginning
this, so that what goes in each archive is better reflected in the layout
(again something I was planning to bring after 0.30 went out), but the main
benefit would come from actually deciding what individual things we will
release.
I'd suggest we take the separate source bundles from the previous
release as a starting point.
We would need to add a specific java source bundle to that list. Would
there be one bundle or would e.g. the 1.0 JMS client be in its own
source bundle?
There may be other things we can consider adding if they don't require
much work to get them ready. (E.g. if possible I'd quite like to see the
qpid-python-tests released, but it certainly is not a blocking issue for
0.30).
We should also remove anything we think is either unlikely to get the
requisite votes or has not changed significantly. I'd suggest that would
include the qpid-wcf zip.
So something like:
qpid-cpp-0.30.tar.gz
qpid-python-0.30.tar.gz
qpid-qmf-0.30.tar.gz
qpid-tools-0.30.tar.gz
+ whatever we need for java
+ anything else
In terms of process we could proceed through beta as before to the first
release candidate considered ready for voting. The vote would then
actually be a set of votes on (for arguments sake) each specific bundle
above. Each would require three binding +1s to be released.
If any artefact doesn't get sufficient votes, but has no explicit issues
identified with it preventing a vote, it would get dropped. Hopefully
this won't happen if we choose the release artefacts up front, but its
there as a backstop anyway.
If we have sufficient testing prior to calling the vote we should be
able to avoid having blocking issues raised in the vote itself. However
if this were to occur we would then have two options open.
In the first we would cancel all votes and discard all artefacts, make
the changes to the release branch then produce a complete new set of
artefacts and restart the vote on each.
Alternatively, we could tag the revision from which those artefacts that
passed their votes were generated, and only produce new candidates of
those in which issues were identified. This would obviously be less work
for the testers, so if feasible from the release managers point of view
would be my preference.
I think we would want to have a time limit in which all artefacts were
ready for their 0.30 release, or else dropped (this is something that
could be relaxed for subsequent releases). When we have the final set of
voted artefacts we can announce the release and push them up to the
appropriate location.
Does this sound feasible/agreeable?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
