On 2014/10/15 02:08 AM, Timothy Pearson wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
important)
- 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
v14.1.0"?
Cheers
Michele