29 Jan
2014
29 Jan
'14
8:51 a.m.
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
29 Jan
29 Jan
9:24 a.m.
New subject: [trinity-devel] R14 RC1 ready?
On Wednesday 29 of January 2014 09:51:57 Darrell Anderson wrote:
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
--
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
12:05 p.m.
New subject: [trinity-devel] R14 RC1 ready?
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
5:44 p.m.
New subject: [trinity-devel] R14 RC1 ready?
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
30 Jan
30 Jan
2:40 a.m.
New subject: [trinity-devel] R14 RC1 ready?
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
3:26 a.m.
New subject: [trinity-devel] R14 RC1 ready?
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(a)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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)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
11:50 p.m.
New subject: [trinity-devel] R14 RC1 ready?
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
31 Jan
31 Jan
12:19 a.m.
New subject: [trinity-devel] R14 RC1 ready?
On Friday 31 of January 2014 00:50:18 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
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
--
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 
1:30 a.m.
New subject: [trinity-devel] R14 RC1 ready?
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.
--
David C. Rankin, J.D.,P.E.
7:43 a.m.
New subject: [trinity-devel] R14 RC1 ready?
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
4:43 p.m.
New subject: [trinity-devel] R14 RC1 ready?
Dne pá 31. ledna 2014 Michele Calgaro napsal(a):
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
--
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
4:57 p.m.
New subject: [trinity-devel] R14 RC1 ready?
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....
...
--
David C. Rankin, J.D.,P.E.
3 Feb
3 Feb
8:58 p.m.
New subject: [trinity-devel] R14 RC1 ready?
On Friday 31 of January 2014 08:43:34 Michele Calgaro wrote:
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)
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
--
4 Feb
4 Feb
6:11 a.m.
New subject: [trinity-devel] R14 RC1 ready?
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
5:05 p.m.
New subject: [trinity-devel] R14 RC1 ready?
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
--
5 Feb
5 Feb
3:35 a.m.
New subject: [trinity-devel] R14 RC1 ready?
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
3942
days inactive
3949
days old
15 comments
6 participants
participants (6)
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Michele Calgaro -
Slávek Banko -
Timothy Pearson