Re: Staging Branches [REVISED]

[Kornel Benko]

Am Dienstag, 19. April 2016 um 21:05:57, schrieb Georg Baum 

> Richard Heck wrote:
> 
> > The other two 2.2.x-staging branches are entirely for book-keeping
> > purposes. It is just easier for me to have the various fixes that are
> > intended for 2.2.1 and 2.2.2 in git branches rather than to try to keep
> > track of them via milestones or keywords or whatever in trac. It's also
> > easier for people to backport these fixes around the same time they did
> > them than to do it weeks or months later.
> 
> Really? For me it does not make any difference whether I run the cherry-pick 
> command now or in two months. Testing has to be done in two months anyway, 
> it does not make sense to test something now that might be different from 
> what will be released. For me it does make a difference if I look at trac 
> and cannot relate a bug status to the different branches. It does also make 
> a difference whether I have to switch branches all the time locally (or 
> keeping five separate working trees to avoid switching) or not. I either 
> have to waste disk space (if I keep separate working copies) or time (for 
> recompiling after each switch if I do not keep separate working copies).
> 
> > We're not really "think[ing] about four stable releases in parallel",
> > and certainly I do not expect that the staging branches are going to get
> > any kind of testing. Once 2.2.x is created, it will get testing, and at
> > that point 2.2.1-staging will be merged into it, and then will politely
> > disappear. Same, eventually, for 2.2.2-staging.
> 
> Well, the questions on the list (e.g. "May I ask why this (and other) commit 
> goes to 2.2.2-staging? When will it make into 2.3-staging?") show that we 
> are thinking about these releases now.
> 
> I understand that these branches make it easier for you, but I believe that 
> they do also come at a cost (at least for me they do). If I could ignore 
> anything related to these branches I would be happy, but as it looks now 
> this is not possible (or I had to stop reading the mailing list, 
> investigating bugs, and fixing bugs, which I do not want).
>

+++1
 
> Georg
> 

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Staging Branches [REVISED]

[Richard Heck]

On 04/19/2016 03:05 PM, Georg Baum wrote:
> Richard Heck wrote:
>
>> The other two 2.2.x-staging branches are entirely for book-keeping
>> purposes. It is just easier for me to have the various fixes that are
>> intended for 2.2.1 and 2.2.2 in git branches rather than to try to keep
>> track of them via milestones or keywords or whatever in trac. It's also
>> easier for people to backport these fixes around the same time they did
>> them than to do it weeks or months later.
> Really? For me it does not make any difference whether I run the cherry-pick 
> command now or in two months. Testing has to be done in two months anyway, 
> it does not make sense to test something now that might be different from 
> what will be released. For me it does make a difference if I look at trac 
> and cannot relate a bug status to the different branches. It does also make 
> a difference whether I have to switch branches all the time locally (or 
> keeping five separate working trees to avoid switching) or not. I either 
> have to waste disk space (if I keep separate working copies) or time (for 
> recompiling after each switch if I do not keep separate working copies).
>
>> We're not really "think[ing] about four stable releases in parallel",
>> and certainly I do not expect that the staging branches are going to get
>> any kind of testing. Once 2.2.x is created, it will get testing, and at
>> that point 2.2.1-staging will be merged into it, and then will politely
>> disappear. Same, eventually, for 2.2.2-staging.
> Well, the questions on the list (e.g. "May I ask why this (and other) commit 
> goes to 2.2.2-staging? When will it make into 2.3-staging?") show that we 
> are thinking about these releases now.
>
> I understand that these branches make it easier for you, but I believe that 
> they do also come at a cost (at least for me they do). If I could ignore 
> anything related to these branches I would be happy, but as it looks now 
> this is not possible (or I had to stop reading the mailing list, 
> investigating bugs, and fixing bugs, which I do not want).

As far as I can see, there is only one extra question that anyone needs
to worry about, namely: Should a fix be committed that is committed to
2.3-staging also be committed to one of the two 2.2.x-staging branches?
The 2.3-staging branch is just playing the role of master now. The rules
for 2.1.x are as usual. So the only things that are really new are the
2.2.x-staging branches. I agree that it would be better if there were
only one of these, but the plans for 2.2.1 make it useful to have two.
But nothing is ever committed to both.

It seems to me worth remembering how things were before these branches:
No one commits anything except to 2.1.x until 2.2.0 is released. I
understand that just having 2.3-staging would have been an option. Maybe
I could have figured out some way to keep track of what needs to go
where. But 2.3-staging is already a messy mix of stuff for 2.3.x and bug
fixes, and it will only get harder to keep track of things. Mmaybe I
should just have created private 2.2.x branches for my own purposes. But
it seemed like a lot of work to cherry pick stuff.

Richard

Re: Staging Branches [REVISED]

[Georg Baum]

Richard Heck wrote:

> The other two 2.2.x-staging branches are entirely for book-keeping
> purposes. It is just easier for me to have the various fixes that are
> intended for 2.2.1 and 2.2.2 in git branches rather than to try to keep
> track of them via milestones or keywords or whatever in trac. It's also
> easier for people to backport these fixes around the same time they did
> them than to do it weeks or months later.

Really? For me it does not make any difference whether I run the cherry-pick 
command now or in two months. Testing has to be done in two months anyway, 
it does not make sense to test something now that might be different from 
what will be released. For me it does make a difference if I look at trac 
and cannot relate a bug status to the different branches. It does also make 
a difference whether I have to switch branches all the time locally (or 
keeping five separate working trees to avoid switching) or not. I either 
have to waste disk space (if I keep separate working copies) or time (for 
recompiling after each switch if I do not keep separate working copies).

> We're not really "think[ing] about four stable releases in parallel",
> and certainly I do not expect that the staging branches are going to get
> any kind of testing. Once 2.2.x is created, it will get testing, and at
> that point 2.2.1-staging will be merged into it, and then will politely
> disappear. Same, eventually, for 2.2.2-staging.

Well, the questions on the list (e.g. "May I ask why this (and other) commit 
goes to 2.2.2-staging? When will it make into 2.3-staging?") show that we 
are thinking about these releases now.

I understand that these branches make it easier for you, but I believe that 
they do also come at a cost (at least for me they do). If I could ignore 
anything related to these branches I would be happy, but as it looks now 
this is not possible (or I had to stop reading the mailing list, 
investigating bugs, and fixing bugs, which I do not want).


Georg

Re: Staging Branches [REVISED]

[Richard Heck]

On 04/19/2016 04:49 AM, Scott Kostyshak wrote:
> On Mon, Apr 18, 2016 at 11:07:01PM +0200, Vincent van Ravesteijn wrote:
>>> We should already be on 2.2 and not on master, which is the future: 2.3
>>>
>> Yes, that was also my proposal.
>>
>> However, people appear to be afraid to not have the 2.2.0 tag in master.
> Yes, I was the scared one. Without a lot of knowledge regarding git, I
> was hesitant to change what I thought was done in the past. Also we had just 
> released and tagged rc1. I do not feel comfortable releasing 2.2.0 or rc2 in 
> a different way from rc1.
>
> My guess is that Vincent's proposal is the best one and I hope we move
> towards that in the future.

Probably, but I agree that changing this sort of procedure so close to
release isn't a great idea.

rh

Re: Staging Branches [REVISED]

[Scott Kostyshak]

On Mon, Apr 18, 2016 at 11:07:01PM +0200, Vincent van Ravesteijn wrote:
> >
> > We should already be on 2.2 and not on master, which is the future: 2.3
> >
> 
> Yes, that was also my proposal.
> 
> However, people appear to be afraid to not have the 2.2.0 tag in master.

Yes, I was the scared one. Without a lot of knowledge regarding git, I
was hesitant to change what I thought was done in the past. Also we had
just released and tagged rc1. I do not feel comfortable releasing 2.2.0
or rc2 in a different way from rc1.

My guess is that Vincent's proposal is the best one and I hope we move
towards that in the future.

Scott


signature.asc
Description: PGP signature

Re: Staging Branches [REVISED]

[Pavel Sanda]

Peter Kümmel wrote:
> I also think these branches are overkill.

+1

Pavel

Re: Staging Branches [REVISED]

[Richard Heck]

On 04/18/2016 05:07 PM, Vincent van Ravesteijn wrote:
>
>
> >
> > We should already be on 2.2 and not on master, which is the future: 2.3
> >
>
> Yes, that was also my proposal.
>
> However, people appear to be afraid to not have the 2.2.0 tag in master.
>
> But note that if the 2.2-branch in this scenario is merged back into
> master after the release, it is equivalent to merging 2.3-staging to
> master in the current proposal. In both ways the tag ends up in
> master, and there is not a real difference between merging A into B
> anhd  merging B into A.
>

2.2.x-staging won't get merged into master, only into 2.2.x.

> 2.2.1-staging is not necessary as all changes are so important that
> they can probably go to 2.2.0 as well.
>

There are already commits to 2.2.1-staging. Nothing goes to master
(=2.2.0) now except what is absolutely critical.

> Changes for 2.2.2 can be cherry-picked from 2.3-staging (or master)
> when 2.1.1 is released.
>

Yes, it would be possible to do it this way. It is more confusing for
me, though, and I worry that some important commit would be missed.

rh

Re: Staging Branches [REVISED]

[Richard Heck]

On 04/18/2016 05:02 PM, Peter Kümmel wrote:
> Am 18. April 2016 22:56:06 MESZ, schrieb Richard Heck :
>> On 04/18/2016 04:32 PM, Peter Kümmel wrote:
>>> Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel"
>> :
 I also think these branches are overkill.

 I would only use master and 2.2. No 2.3, it is so far away that it
>> could be in master. 
 2.2 should be always stable so that at any time a short living 2.2.x
>> could be branched until the release is done. After the tag 2.2.x will
>> be deleted then.
 Similar to 
 https://wiki.qt.io/Branch_Guidelines

 Peter
>>> We should already be on 2.2 and not on master, which is the future:
>> 2.3 
>>
>> We discussed this sort of option: Branch 2.2.x now and continue
>> development towards 2.2.0 there. Then development targeted at 2.3 can
>> continue in master. But most people didn't like this option. Most
>> importantly, Scott didn't like it, or didn't feel comfortable with it,
>> and it's his call.
>>
>> So master is still what will become 2.2.0, and it is closed except for
>> absolutely essential fixes. But people wanted to be able to continue
>> development, so that's why we have 2.3-staging.
>>
>> The other two 2.2.x-staging branches are entirely for book-keeping
>> purposes. It is just easier for me to have the various fixes that are
>> intended for 2.2.1 and 2.2.2 in git branches rather than to try to keep
>> track of them via milestones or keywords or whatever in trac. It's also
>> easier for people to backport these fixes around the same time they did
>> them than to do it weeks or months later.
>>
>> We're not really "think[ing] about four stable releases in parallel", and 
>> certainly I do not expect that the staging branches are going to get any 
>> kind of testing. Once 2.2.x is created, it will get testing, and at that 
>> point 2.2.1-staging will be merged into it, and then will politely 
>> disappear. Same, eventually, for 2.2.2-staging.
>>
>> Richard
> But why are there fixes which should go only into 2.2.2 and not into an 
> unreleased 2.2.1? 

Because the plan (discussed in another thread) is currently to reserve
2.2.1, for the time being, only for serious bugs that emerge shortly
after release, if any do. I.e., 2.2.1 may be released very shortly after
2.2.0, and too soon for anything to get much testing. There are bugs for
which we now have fixes that aren't appropriate for 2.2.1, under that
plan, but will go into 2.2.x eventually, i.e., into 2.2.2. If things go
better than expected, and we don't need to do a "quick" release of
2.2.1, then we can merge 2.2.2-staging into 2.2.x as well and release
all that as 2.2.1.

Richard

Re: Staging Branches [REVISED]

[Vincent van Ravesteijn]

>
> We should already be on 2.2 and not on master, which is the future: 2.3
>

Yes, that was also my proposal.

However, people appear to be afraid to not have the 2.2.0 tag in master.

But note that if the 2.2-branch in this scenario is merged back into master
after the release, it is equivalent to merging 2.3-staging to master in the
current proposal. In both ways the tag ends up in master, and there is not
a real difference between merging A into B anhd  merging B into A.

2.2.1-staging is not necessary as all changes are so important that they
can probably go to 2.2.0 as well. Changes for 2.2.2 can be cherry-picked
from 2.3-staging (or master) when 2.1.1 is released.

Vincent

Re: Staging Branches [REVISED]

[Peter Kümmel]

Am 18. April 2016 22:56:06 MESZ, schrieb Richard Heck :
>On 04/18/2016 04:32 PM, Peter Kümmel wrote:
>> Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel"
>:
>>> I also think these branches are overkill.
>>>
>>> I would only use master and 2.2. No 2.3, it is so far away that it
>could be in master. 
>>>
>>> 2.2 should be always stable so that at any time a short living 2.2.x
>could be branched until the release is done. After the tag 2.2.x will
>be deleted then.
>>>
>>> Similar to 
>>> https://wiki.qt.io/Branch_Guidelines
>>>
>>> Peter
>> We should already be on 2.2 and not on master, which is the future:
>2.3 
>
>We discussed this sort of option: Branch 2.2.x now and continue
>development towards 2.2.0 there. Then development targeted at 2.3 can
>continue in master. But most people didn't like this option. Most
>importantly, Scott didn't like it, or didn't feel comfortable with it,
>and it's his call.
>
>So master is still what will become 2.2.0, and it is closed except for
>absolutely essential fixes. But people wanted to be able to continue
>development, so that's why we have 2.3-staging.
>
>The other two 2.2.x-staging branches are entirely for book-keeping
>purposes. It is just easier for me to have the various fixes that are
>intended for 2.2.1 and 2.2.2 in git branches rather than to try to keep
>track of them via milestones or keywords or whatever in trac. It's also
>easier for people to backport these fixes around the same time they did
>them than to do it weeks or months later.
>
>We're not really "think[ing] about four stable releases in parallel",
>and certainly I do not expect that the staging branches are going to
>get
>any kind of testing. Once 2.2.x is created, it will get testing, and at
>that point 2.2.1-staging will be merged into it, and then will politely
>disappear. Same, eventually, for 2.2.2-staging.
>
>Richard

But why are there fixes which should go only into 2.2.2 and not into an 
unreleased 2.2.1? 
Peter

Re: Staging Branches [REVISED]

[Richard Heck]

On 04/18/2016 04:32 PM, Peter Kümmel wrote:
> Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel" :
>> I also think these branches are overkill.
>>
>> I would only use master and 2.2. No 2.3, it is so far away that it could be 
>> in master. 
>>
>> 2.2 should be always stable so that at any time a short living 2.2.x could 
>> be branched until the release is done. After the tag 2.2.x will be deleted 
>> then.
>>
>> Similar to 
>> https://wiki.qt.io/Branch_Guidelines
>>
>> Peter
> We should already be on 2.2 and not on master, which is the future: 2.3 

We discussed this sort of option: Branch 2.2.x now and continue
development towards 2.2.0 there. Then development targeted at 2.3 can
continue in master. But most people didn't like this option. Most
importantly, Scott didn't like it, or didn't feel comfortable with it,
and it's his call.

So master is still what will become 2.2.0, and it is closed except for
absolutely essential fixes. But people wanted to be able to continue
development, so that's why we have 2.3-staging.

The other two 2.2.x-staging branches are entirely for book-keeping
purposes. It is just easier for me to have the various fixes that are
intended for 2.2.1 and 2.2.2 in git branches rather than to try to keep
track of them via milestones or keywords or whatever in trac. It's also
easier for people to backport these fixes around the same time they did
them than to do it weeks or months later.

We're not really "think[ing] about four stable releases in parallel",
and certainly I do not expect that the staging branches are going to get
any kind of testing. Once 2.2.x is created, it will get testing, and at
that point 2.2.1-staging will be merged into it, and then will politely
disappear. Same, eventually, for 2.2.2-staging.

Richard

Re: Staging Branches [REVISED]

[Peter Kümmel]

Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel" :
>Am 18. April 2016 21:28:04 MESZ, schrieb Georg Baum
>:
>>Richard Heck wrote:
>>
>>> We now have three staging branches. These are:
>>> 
>>> 2.3-staging
>>> 2.2.1-staging
>>> 2.2.2-staging
>>
>>That makes 5 active branches in total (please correct me if I
>>misunderstood 
>>something):
>>
>>2.1.x  => will become 2.1.5
>>master => will become 2.2.0
>>2.2.1-staging  => will become 2.2.1
>>2.2.2-staging  => will become 2.2.2
>>2.3-staging=> will become 2.3.0
>>
>>Am I the only one who thinks that this is too much? IMHO this results
>>in a 
>>lot of additional book keeping work that eats from our valuable
>>resources. 
>>In addition, there are the trac keyword problems. Currently it is not 
>>possible to map these branches to trac, if we wanted to do that we'd
>>need 
>>three additional keywords for the staging branches. If we do not add
>>these 
>>keywords then bugs might be closed for the wrong milestone and/or we
>>need 
>>manual work to find out from trac whether a particular bug will be
>>fixed 
>>e.g. for 2.2.1 or not.
>>
>>Such a structure is good for large organizations. It does not make
>>sense for 
>>such a small group of part time developers like us IMHO. We do not
>have
>>the 
>>resources to think about four stable releases in parallel. IMHO we
>>should 
>>concentrate on one branch for 2.2.0 and one for 2.3 development, and
>>refrain 
>>from big refactoring projects in 2.3 until 2.2.1 is out. Nobody will
>>try out 
>>all these different 2.2 branches, so these fixes won't get additional 
>>testing. In the contrary, I believe that they would get more testing
>if
>>they 
>>were all in one 2.3 branch.  Also, I doubt that we can now plan ahead
>>for 
>>2.2.2, these plans are likely to become obsolete. We have a simple
>tool
>>to 
>>schedule bug fixes: Milestones in trac. If we put all bug fixes in the
>>2.3 
>>branch and set the bug milestones it is easy to get a list of all
>fixes
>>that 
>>need backporting.
>>
>>
>>Georg
>
>I also think these branches are overkill.
>
>I would only use master and 2.2. No 2.3, it is so far away that it
>could be in master. 
>
>2.2 should be always stable so that at any time a short living 2.2.x
>could be branched until the release is done. After the tag 2.2.x will
>be deleted then.
>
>Similar to 
>https://wiki.qt.io/Branch_Guidelines
>
>Peter

We should already be on 2.2 and not on master, which is the future: 2.3 

Re: Staging Branches [REVISED]

[Peter Kümmel]

Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel" :
>Am 18. April 2016 21:28:04 MESZ, schrieb Georg Baum
>:
>>Richard Heck wrote:
>>
>>> We now have three staging branches. These are:
>>> 
>>> 2.3-staging
>>> 2.2.1-staging
>>> 2.2.2-staging
>>
>>That makes 5 active branches in total (please correct me if I
>>misunderstood 
>>something):
>>
>>2.1.x  => will become 2.1.5
>>master => will become 2.2.0
>>2.2.1-staging  => will become 2.2.1
>>2.2.2-staging  => will become 2.2.2
>>2.3-staging=> will become 2.3.0
>>
>>Am I the only one who thinks that this is too much? IMHO this results
>>in a 
>>lot of additional book keeping work that eats from our valuable
>>resources. 
>>In addition, there are the trac keyword problems. Currently it is not 
>>possible to map these branches to trac, if we wanted to do that we'd
>>need 
>>three additional keywords for the staging branches. If we do not add
>>these 
>>keywords then bugs might be closed for the wrong milestone and/or we
>>need 
>>manual work to find out from trac whether a particular bug will be
>>fixed 
>>e.g. for 2.2.1 or not.
>>
>>Such a structure is good for large organizations. It does not make
>>sense for 
>>such a small group of part time developers like us IMHO. We do not
>have
>>the 
>>resources to think about four stable releases in parallel. IMHO we
>>should 
>>concentrate on one branch for 2.2.0 and one for 2.3 development, and
>>refrain 
>>from big refactoring projects in 2.3 until 2.2.1 is out. Nobody will
>>try out 
>>all these different 2.2 branches, so these fixes won't get additional 
>>testing. In the contrary, I believe that they would get more testing
>if
>>they 
>>were all in one 2.3 branch.  Also, I doubt that we can now plan ahead
>>for 
>>2.2.2, these plans are likely to become obsolete. We have a simple
>tool
>>to 
>>schedule bug fixes: Milestones in trac. If we put all bug fixes in the
>>2.3 
>>branch and set the bug milestones it is easy to get a list of all
>fixes
>>that 
>>need backporting.
>>
>>
>>Georg
>
>I also think these branches are overkill.
>
>I would only use master and 2.2. No 2.3, it is so far away that it
>could be in master. 
>
>2.2 should be always stable so that at any time a short living 2.2.x
>could be branched until the release is done. After the tag 2.2.x will
>be deleted then.
>
>Similar to 
>https://wiki.qt.io/Branch_Guidelines
>
>Peter

We should already be on 2.2 and not on master, which is the future: 2.3 

Re: Staging Branches [REVISED]

[Peter Kümmel]

Am 18. April 2016 21:28:04 MESZ, schrieb Georg Baum 
:
>Richard Heck wrote:
>
>> We now have three staging branches. These are:
>> 
>> 2.3-staging
>> 2.2.1-staging
>> 2.2.2-staging
>
>That makes 5 active branches in total (please correct me if I
>misunderstood 
>something):
>
>2.1.x  => will become 2.1.5
>master => will become 2.2.0
>2.2.1-staging  => will become 2.2.1
>2.2.2-staging  => will become 2.2.2
>2.3-staging=> will become 2.3.0
>
>Am I the only one who thinks that this is too much? IMHO this results
>in a 
>lot of additional book keeping work that eats from our valuable
>resources. 
>In addition, there are the trac keyword problems. Currently it is not 
>possible to map these branches to trac, if we wanted to do that we'd
>need 
>three additional keywords for the staging branches. If we do not add
>these 
>keywords then bugs might be closed for the wrong milestone and/or we
>need 
>manual work to find out from trac whether a particular bug will be
>fixed 
>e.g. for 2.2.1 or not.
>
>Such a structure is good for large organizations. It does not make
>sense for 
>such a small group of part time developers like us IMHO. We do not have
>the 
>resources to think about four stable releases in parallel. IMHO we
>should 
>concentrate on one branch for 2.2.0 and one for 2.3 development, and
>refrain 
>from big refactoring projects in 2.3 until 2.2.1 is out. Nobody will
>try out 
>all these different 2.2 branches, so these fixes won't get additional 
>testing. In the contrary, I believe that they would get more testing if
>they 
>were all in one 2.3 branch.  Also, I doubt that we can now plan ahead
>for 
>2.2.2, these plans are likely to become obsolete. We have a simple tool
>to 
>schedule bug fixes: Milestones in trac. If we put all bug fixes in the
>2.3 
>branch and set the bug milestones it is easy to get a list of all fixes
>that 
>need backporting.
>
>
>Georg

I also think these branches are overkill.

I would only use master and 2.2. No 2.3, it is so far away that it could be in 
master. 

2.2 should be always stable so that at any time a short living 2.2.x could be 
branched until the release is done. After the tag 2.2.x will be deleted then.

Similar to 
https://wiki.qt.io/Branch_Guidelines

Peter

Re: Staging Branches [REVISED]

[Georg Baum]

Richard Heck wrote:

> We now have three staging branches. These are:
> 
> 2.3-staging
> 2.2.1-staging
> 2.2.2-staging

That makes 5 active branches in total (please correct me if I misunderstood 
something):

2.1.x  => will become 2.1.5
master => will become 2.2.0
2.2.1-staging  => will become 2.2.1
2.2.2-staging  => will become 2.2.2
2.3-staging=> will become 2.3.0

Am I the only one who thinks that this is too much? IMHO this results in a 
lot of additional book keeping work that eats from our valuable resources. 
In addition, there are the trac keyword problems. Currently it is not 
possible to map these branches to trac, if we wanted to do that we'd need 
three additional keywords for the staging branches. If we do not add these 
keywords then bugs might be closed for the wrong milestone and/or we need 
manual work to find out from trac whether a particular bug will be fixed 
e.g. for 2.2.1 or not.

Such a structure is good for large organizations. It does not make sense for 
such a small group of part time developers like us IMHO. We do not have the 
resources to think about four stable releases in parallel. IMHO we should 
concentrate on one branch for 2.2.0 and one for 2.3 development, and refrain 
from big refactoring projects in 2.3 until 2.2.1 is out. Nobody will try out 
all these different 2.2 branches, so these fixes won't get additional 
testing. In the contrary, I believe that they would get more testing if they 
were all in one 2.3 branch.  Also, I doubt that we can now plan ahead for 
2.2.2, these plans are likely to become obsolete. We have a simple tool to 
schedule bug fixes: Milestones in trac. If we put all bug fixes in the 2.3 
branch and set the bug milestones it is easy to get a list of all fixes that 
need backporting.


Georg

Re: Staging Branches [REVISED]

[Richard Heck]

On 04/16/2016 04:25 PM, Guillaume Munch wrote:
> Le 16/04/2016 20:44, Richard Heck a écrit :
>>
>> We now have three staging branches. These are:
>>
>>  2.3-staging
>>  2.2.1-staging
>>  2.2.2-staging
>>
>>
>> 2.3-staging can be treated as master usually is: It is for development
>> on what will become 2.3 and is now open for commits. This branch will be
>> merged into master after the release of 2.2.0.
>>
>> The 2.2.x-staging branches should be treated as 2.2.x usually is: They
>> are open for commits to what will become the 2.2.x branch. The
>> difference, obviously, is that 2.2.1-staging is for commits that will
>> become part of 2.2.1; 2.2.2-staging is for commits that may not become
>> part of 2.2.1 but will eventually go to 2.2.x. So commits to either of
>> these branches need my approval.
>>
>
> Thanks, it's clearer when there is a 2.2.2-staging branch available.
> But why did you create it at b9b49d1c (before rc1) and not at 3d5cae4e
> (master)?

Hmm. My master must not have been up to date. I've merged master into it
so it is. I've done the same with the other branches, as we might as
well start from as up to date as possible.

Richard

Re: Staging Branches [REVISED]

[Guillaume Munch]

Le 16/04/2016 20:44, Richard Heck a écrit :


We now have three staging branches. These are:

 2.3-staging
 2.2.1-staging
 2.2.2-staging


2.3-staging can be treated as master usually is: It is for development
on what will become 2.3 and is now open for commits. This branch will be
merged into master after the release of 2.2.0.

The 2.2.x-staging branches should be treated as 2.2.x usually is: They
are open for commits to what will become the 2.2.x branch. The
difference, obviously, is that 2.2.1-staging is for commits that will
become part of 2.2.1; 2.2.2-staging is for commits that may not become
part of 2.2.1 but will eventually go to 2.2.x. So commits to either of
these branches need my approval.



Thanks, it's clearer when there is a 2.2.2-staging branch available. But 
why did you create it at b9b49d1c (before rc1) and not at 3d5cae4e (master)?

Staging Branches [REVISED]

[Richard Heck]

We now have three staging branches. These are:

2.3-staging
2.2.1-staging
2.2.2-staging
 

2.3-staging can be treated as master usually is: It is for development
on what will become 2.3 and is now open for commits. This branch will be
merged into master after the release of 2.2.0.

The 2.2.x-staging branches should be treated as 2.2.x usually is: They
are open for commits to what will become the 2.2.x branch. The
difference, obviously, is that 2.2.1-staging is for commits that will
become part of 2.2.1; 2.2.2-staging is for commits that may not become
part of 2.2.1 but will eventually go to 2.2.x. So commits to either of
these branches need my approval.

At the moment, the plan is to reserve 2.2.1 for a fairly quick
bug-fixing release in response to problems that arise after the release
of 2.2.0. However, there are other sorts of "very safe" patches that
could go to 2.2.1---an example would be JMarc's patch moving the
documentation change logs---so I want to have this branch at least
available to keep track of them.

For the most part, then, fixes intended for 2.2.x that are now too late
for 2.2.0 should go to 2.2.2-staging. If things go really, really
smoothly, some of these might be good for 2.2.1.

The 2.2.1-staging branch will be merged into 2.2.x once that has been
branched from master. The 2.3-staging branch will be merged into master
once 2.2.0 is released.

We do not yet have an agreed policy for how fixes should be marked in
trac. I'll make a proposal in another thread.

Richard