Just to clarify:
Dennis & Greg are using the 2.2.0 branch from last release to fix Levels
and release 2.2.1
trunk started failing tests after some unrelated changes exposed
synchronization errors in the qa tests, since then
skunk/qa-refactoring is being used to fix synchronization issues before
merging back with trunk,
trunk is presently unstable. After the merge, 2.3.0 is scheduled for
release.
Having had some time to think, I'd recommend back-porting JERI from
skunk/qa-refactoring into the 2.2.1 release, as there are some very
important fixes included for issues seen by downstream users.
Regards,
Peter.
Dan Creswell wrote:
On 6 April 2013 14:44, Dennis Reedy <dennis.re...@gmail.com> wrote:
On Apr 6, 2013, at 532AM, Dan Creswell wrote:
Right so we're into brutal tradeoffs aren't we?
It's beginning to smell like none of the available branches are suitable
for doing releases from. So we need a branch that is.
AFAIK we are going to be releasing 2.2.1 from the 2.2 branch. Once
everything passes muster (Greg is running tests) we will tag the branch
2.2.1 and release.
i.e. We shouldn't just pick a branch we have, we should get one sorted
and
right now.
What are our chances of pulling just qa changes out of qa-refactoring?
Have
we at least got changesets that don't mix concurrency fixes with anything
other than concurrency related changes to tests?
You are talking 2.3.0 here? I though qa-trunk was being used for that?
Peter is having some comms trouble looks like so I'll leave it at an open
question:
Have we got a shared, agreed view of what unreleased code changes are in
which branch?
