On 8 August 2014 09:58, Gordon Sim <[email protected]> wrote: > 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? > > > 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. Robbie
