Message: previous - next
Month: October 2014

Re: [trinity-devel] R14 hard freeze for RC1

From: Michele Calgaro <michele.calgaro@...>
Date: Wed, 15 Oct 2014 11:30:15 +0900
On 2014/10/15 02:08 AM, Timothy Pearson wrote:
> Hash: SHA224
> All,
> As you can probably see from the activity on the trinity-commits list
> there have been multiple updates to both the common cmake/admin modules
> and the icons across the entire tree over the past week or so.
> This ongoing activity has forced essentially a full archive rebuild for
> Debian/Ubuntu, our primary supported distributions.
> I am announcing a ***hard freeze*** for R14 to allow the Debian/Ubuntu
> rebuild to start generating our RC1 package sets.  There are currently
> three open bug reports blocking Bug 2014; patches that do not relate to
> those three reports must be discussed on this list and approved by me
> before being committed to GIT.  Additionally, only patches that do not
> affect the common cmake/admin modules will even be considered at this
> time.
> After the RC1 rebuilds are complete this soft freeze will thaw to accept
> patches for bugs discovered before and during RC1 testing.  This thaw will
> be short lived to allow time for RC2 rebuilds, so all patches should be
> ready within a week after RC1 release.
> Each rebuild cycle takes around 2-3 weeks due to the multitude of
> distributions supported.  If no common cmake/admin modules are updated for
> RC2 the resultant rebuild will take less time.
> Onwards to the much-fabled R14 release! :-)
> Tim

My two cents about bug and development through the freeze period.

1) About the remaining 3 bugs.

- bug 1850: I don't see it as fully blocking. WE could release v14.0.0 
even if not control module tabs have been updated to open the correct 
handbook. Of course it would be nice to fully close the bug, but if not 
we can leave the remaining things for the first subsequent maintenance 
release v14.0.1

- bug 1859: documentation is almost fully updated (I still have a few 
list to do, which I should be able (or at least I hope) to do within 
this week. I can push all the doc updates in one cumulative push when 
ready. After that there are two more things to do. One is sorting the 
top level list (not critical, but should not be too long) and one is to 
add a button for manually updating the top level list (this is more 

- bug 2152: I haven't look at the details, but based on the two commits 
already made by Slavek it should not take long to fix.

2) about freezing, development and v14.0.x
Tim, is it possible to create a GIT branch for v14.0.0 so that we can 
keep pushing patches *not to be in v14.0.0* to the main trunk? The main 
question here is actually "how are we going to maintain the v14.0.x 
branch when v14.0.0 has been release and the main trunk will be for