I would like to tag the current sources and binaries R14.0.0 RC1, as it appears that we have finally cleared the Blocker and Critical reports from the R14 Etherpad.
Are we ready for this or are there any objections?
The etherpad hasn't received updates in a while. We need some hacking.
Blocker: ========
http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd =Blocker
Critical: =========
http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd =Critical
Michele is working on 1825, but could use help. That is an ugly bug from a public relations perspective. The comments provide a lot of details.
1853 needs attention.
1821 hasn't been touched.
1813 can be closed after the last comment is implemented.
Regressions: ============
1825 is bad (already mentioned in Critical). The others should receive attention but probably could survive the R14.0.0 cut.
Patches Available: ==================
Lots of patches sitting out there that have not been reviewed. Likely many could be pushed.
Other: ======
* The new web site should be tested before moving toward a release date.
* There is a laundry list of items in the R14 checklist etherpad that need attention.
Darrell
On Wednesday 29 of January 2014 09:51:57 Darrell Anderson wrote:
I would like to tag the current sources and binaries R14.0.0 RC1, as it appears that we have finally cleared the Blocker and Critical reports from the R14 Etherpad.
Are we ready for this or are there any objections?
The etherpad hasn't received updates in a while. We need some hacking.
Blocker:
http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd =Blocker
Critical:
http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd =Critical
Michele is working on 1825, but could use help. That is an ugly bug from a public relations perspective. The comments provide a lot of details.
1853 needs attention.
1821 hasn't been touched.
1813 can be closed after the last comment is implemented.
Regressions:
1825 is bad (already mentioned in Critical). The others should receive attention but probably could survive the R14.0.0 cut.
Patches Available:
Lots of patches sitting out there that have not been reviewed. Likely many could be pushed.
Other:
- The new web site should be tested before moving toward a release
date.
- There is a laundry list of items in the R14 checklist etherpad
that need attention.
Darrell
I'm working hard on bug: 1597 [Regression] Pressing the power button shutdown computer, regardless of what I set in tdepowersave. I'm close to completion.
Slavek --
Darrell spent some time to write about outstanding issues. Not many fortunately.
What exactly is allowed on the source code after RC1 is tagged? Are we restricted to critical bug fixes and nominal patches, or we still have a good degree of freedom? Actually this is a question I have been asking myself for a while....
As Darrell said, I am working on bug 1825, which although not a blocker, messes up all documentation indexes, so IMO should be resolved before releasing R14 (even though technically a fix could be push even after RC1 is tagged).
Cheers MIchele
Darrell spent some time to write about outstanding issues. Not many fortunately.
What exactly is allowed on the source code after RC1 is tagged? Are we restricted to critical bug fixes and nominal patches, or we still have a good degree of freedom? Actually this is a question I have been asking myself for a while....
As Darrell said, I am working on bug 1825, which although not a blocker, messes up all documentation indexes, so IMO should be resolved before releasing R14 (even though technically a fix could be push even after RC1 is tagged).
Cheers MIchele
Source changes will be restricted to Blocker/Critical bug fixes only. Documentation changes will be restricted at the RC2 phase, similar to how Ubuntu handles releases.
Tim
Source changes will be restricted to Blocker/Critical bug fixes only. Documentation changes will be restricted at the RC2 phase, similar to how Ubuntu handles releases.
Thanks Tim. So at the same time are we starting a separate branch for RC1 so we are still free to work on the main trunk on other things?
Michele
Not sure how you guys are doing it here,
But some people recommend keeping the master branch stable and doing new development / patches in other branches. Merging is a breeze with git so usually when i work on features i do it in a new feature branch for that specifically, then when i'm tested and working with it, i merge it into my master banch.
On 29 January 2014 21:40, Michele Calgaro michele.calgaro@yahoo.it wrote:
Source changes will be restricted to Blocker/Critical bug fixes only. Documentation changes will be restricted at the RC2 phase, similar to how Ubuntu handles releases.
Thanks Tim. So at the same time are we starting a separate branch for RC1 so we are still free to work on the main trunk on other things?
Michele
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Source changes will be restricted to Blocker/Critical bug fixes only. Documentation changes will be restricted at the RC2 phase, similar to how Ubuntu handles releases.
Thanks Tim. So at the same time are we starting a separate branch for RC1 so we are still free to work on the main trunk on other things?
Michele
I had no plans concerning this. Before GIT we used to just freeze the source tree, then have the developers merge their patches in after the release was complete; now that we use GIT we need to give this some thought.
Right now the consensus from the main developers seems to be that we are not yet ready, so unfortunately we are not yet able to release R14.0.0 RC1.
Tim
On Friday 31 of January 2014 00:50:18 Timothy Pearson wrote:
Source changes will be restricted to Blocker/Critical bug fixes only. Documentation changes will be restricted at the RC2 phase, similar to how Ubuntu handles releases.
Thanks Tim. So at the same time are we starting a separate branch for RC1 so we are still free to work on the main trunk on other things?
Michele
I had no plans concerning this. Before GIT we used to just freeze the source tree, then have the developers merge their patches in after the release was complete; now that we use GIT we need to give this some thought.
Right now the consensus from the main developers seems to be that we are not yet ready, so unfortunately we are not yet able to release R14.0.0 RC1.
Tim
I assumed that git tag and branch for maintanance releases R14.0.x we will create with the final R14.0.0.
By the way, for several months I have unfinished proposal about using branches, but since I have devoted to other tasks at Trinity, I still have not finished it and not sent it...
Slavek --
On 01/30/2014 05:50 PM, Timothy Pearson wrote:
I had no plans concerning this. Before GIT we used to just freeze the source tree, then have the developers merge their patches in after the release was complete; now that we use GIT we need to give this some thought.
Right now the consensus from the main developers seems to be that we are not yet ready, so unfortunately we are not yet able to release R14.0.0 RC1.
Tim
Well, Darrell and others make a good argument for creating a 14.0.0 branch at RC1. Development continues on head/master and only critical/blocker fix commits (and any cherry picks from continued development) can be merged into the 14.0.0 branch for RC2 and then one more cycle for the release.
Has merit. The git gurus will have to figure out how to do it and manage it.
Well, Darrell and others make a good argument for creating a 14.0.0 branch at RC1. Development continues on head/master and only critical/blocker fix commits (and any cherry picks from continued development) can be merged into the 14.0.0 branch for RC2 and then one more cycle for the release.
Well, that was the idea basically. In more detail: 1) once we think we are ready, we tag RC1. 2) work can continue as usual on the main trunk, but new changes will not make it to R14.0.0 3) any patch that is related to R14.0.0 (blocker, critical bugs) will have to be backported to the RC1 branch. 4) once we are ready, RC1 will turn into RC2 and eventually RC3 5) once we are happy, we tag R14.0.0, then build and release (which is probably going to take one and half months anyway)
If this schema is in place, we could even tag RC1 today, even though I think Darrell still has some changes to the help handbook main structure that he would like to complete before that. Michele
Dne pá 31. ledna 2014 Michele Calgaro napsal(a):
Well, Darrell and others make a good argument for creating a 14.0.0 branch at RC1. Development continues on head/master and only critical/blocker fix commits (and any cherry picks from continued development) can be merged into the 14.0.0 branch for RC2 and then one more cycle for the release.
Well, that was the idea basically. In more detail:
- once we think we are ready, we tag RC1.
- work can continue as usual on the main trunk, but new changes will
not make it to R14.0.0 3) any patch that is related to R14.0.0 (blocker, critical bugs) will have to be backported to the RC1 branch. 4) once we are ready, RC1 will turn into RC2 and eventually RC3 5) once we are happy, we tag R14.0.0, then build and release (which is probably going to take one and half months anyway)
If this schema is in place, we could even tag RC1 today, even though I think Darrell still has some changes to the help handbook main structure that he would like to complete before that. Michele
Please, with RC1, I would suggest a few more days to wait. First, I'm briefly before completing the patch for tdepowersave (see bug 1597), I would like to incorporate this patch before RC1. Furthermore, we should check and fix all FTBFS caused by recent patches.
Slavek --
On 01/31/2014 10:43 AM, Slávek Banko wrote:
Please, with RC1, I would suggest a few more days to wait. First, I'm briefly before completing the patch for tdepowersave (see bug 1597), I would like to incorporate this patch before RC1. Furthermore, we should check and fix all FTBFS caused by recent patches.
Slavek
I Agree with Slavek, by Monday I should have had time to finish going through R14 and if there are any bugs with 'quick fixes', those should go in before R14 is frozen. A little more time won't kill us :)
But not too much more time -- we had this same discussion in 2012 and......
then gcc 4.52, 4.6 and 4.7....
...
On Friday 31 of January 2014 08:43:34 Michele Calgaro wrote:
Well, that was the idea basically. In more detail:
- once we think we are ready, we tag RC1.
- work can continue as usual on the main trunk, but new changes will not
make it to R14.0.0 3) any patch that is related to R14.0.0 (blocker, critical bugs) will have to be backported to the RC1 branch. 4) once we are ready, RC1 will turn into RC2 and eventually RC3 5) once we are happy, we tag R14.0.0, then build and release (which is probably going to take one and half months anyway)
Yes, exactly this way I also intended.
However, there's a technical hitch. Nightly-builds are designed to "always" built from "master" branch. This means that for the "stable" builds I'll need now create a new PPA - as was the 'axis' for v3.5.13-sru branch. For release the final R14.0.0 packages would then be used packages from my PPA, not packages from nightly-builds.
Because armel and armhf now building very fast, building 'stable' packages is not a fundamental problem. Unfortunately I do not know if is now on the build-farm enough space to be able to create a new 'stable' PPA in my account.
Tim, please, what do you think about this?
Slavek --
However, there's a technical hitch. Nightly-builds are designed to "always" built from "master" branch.
Slavek, can't we modify the script to build from a given tag instead? We could use a text file to contain either "master" or the tag name, then the script will read the config file and checkout the version from git according to the settings. This way, we can switch between master and other tags seemlessly and we don't need a separate PPA for building R14.
Michele
Dne út 4. února 2014 Michele Calgaro napsal(a):
Slavek, can't we modify the script to build from a given tag instead? We could use a text file to contain either "master" or the tag name, then the script will read the config file and checkout the version from git according to the settings. This way, we can switch between master and other tags seemlessly and we don't need a separate PPA for building R14.
No, it is definitely not a good idea to change nightly-builds. First, it would cause confusion for users who use these apt sources and at the same time it would be a mess for QuickBuild. QuickBuild assumes that the version of the package is still increases - if it were in the same PPA alternated nightly-builds and stable-builds, packages version would jump up and down - just mess.
Look how it worked now, with v3.5.13-sru branch. We have basically three groups of users:
1) ordinary users using only stable versions 2) testers for updates stable version - my ppa 3) testers on the edge of development - nightly-builds
Each of these users has set apt sources for the required PPA. It is not possible to be in 'nightly-builds' alternated packages "testing" and packages "updates". It would be undesirable for both users and maintainers.
Therefore, we 'need' new PPA, but the question is 'when'. One possibility is that the development in the master branch (and nightly-builds) will continue up to R14.0.0. The second possibility is that the finalization stable release after RC1 will continue in the new PPA. In this PPA will then continue maintanance updates.
Slavek --
Therefore, we 'need' new PPA, but the question is 'when'. One possibility is that the development in the master branch (and nightly-builds) will continue up to R14.0.0. The second possibility is that the finalization stable release after RC1 will continue in the new PPA. In this PPA will then continue maintanance updates.
Ok, I see. Then I think the second option is better, to prevent stopping development on the master branch. Business on the master branch will continue as usual, while RC1 will have its own PPA, which later will be the R14.0.0 PPA. Bug fixes related to R14.0.0 will then need to be backported to that PPA.
Michele
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Michele Calgaro -
Slávek Banko -
Timothy Pearson