qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: 0.30 release update - alpha is available
Date Fri, 08 Aug 2014 14:55:09 GMT
On 8 August 2014 11:33, Gordon Sim <gsim@redhat.com> wrote:

> 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?
I think for this release there should only be one, its all built as one big
thing. We can look to split things up further at the build level if we wish
later, and at that point start creating more source artifacts.

> 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

The Java QMF2 tools and GUI Fraser made will need an archive. They
currently live under tools, but are not included in the archive with the
other QMF tools.

> 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?
> The only thing I I'd say is that the common branch and schedule might
prove annoying if the actual items are considered independent releases,
because some bits are usually ready before the others and any time that
passes waiting for the sync up could probably be used to do a point release
with the intervening bugfixes rather than always merging them or deferring
them to the next big release as has happened previously.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message