Re: Staging Branches

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
>>> can we merge the painting branch into 2.3.1 staging?  I'm inclusively
>>> working on master without larger issues for quite some time now. That does
>>> not say anything about mac/win arch, but the sooner we start testing the
>>> better.
>> I'd be happy to have it in 2.3.2-staging. At this point, 2.3.1 is reserved
>> for emergencies, more or less.
>
> Fine, I have done that now. Please test and complain.

Cool, I am switching from master to 2.3.2 from now on.
Pavel

Re: Staging Branches

[Jean-Marc Lasgouttes]

Le 14/02/2018 à 18:54, Richard Heck a écrit :

can we merge the painting branch into 2.3.1 staging?
I'm inclusively working on master without larger issues for quite some time
now. That does not say anything about mac/win arch, but the sooner we start
testing the better.


I'd be happy to have it in 2.3.2-staging. At this point, 2.3.1 is
reserved for emergencies, more or less.


Fine, I have done that now. Please test and complain.

JMarc

Re: Staging Branches

[Pavel Sanda]

Pavel Sanda wrote:
> Richard Heck wrote:
> > If we don't need to do anything
> > super-fast, then I'll just merge 2.3.2-staging into 2.3.1-staging.
> 
> I see, sounds good. Pavel

When I think more about it though, if *getting the branch tested* from other
devs is important goal of yours, then the best is just to have single branch
2.3.x (after releasing 2.3.0) and nothing else.
If *critical* thing appear (I can rember only one case of that during all the
years) then you can branch out directly from 2.3.0 and fix it there.

Pavel

Re: Staging Branches

[Pavel Sanda]

Richard Heck wrote:
> If we don't need to do anything
> super-fast, then I'll just merge 2.3.2-staging into 2.3.1-staging.

I see, sounds good. Pavel

Re: Staging Branches

[Scott Kostyshak]

On Wed, Feb 14, 2018 at 06:40:28PM +, Richard Heck wrote:
> On 02/14/2018 01:09 PM, Pavel Sanda wrote:
> > Richard Heck wrote:
> >>> can we merge the painting branch into 2.3.1 staging?
> >>> I'm inclusively working on master without larger issues for quite some 
> >>> time
> >>> now. That does not say anything about mac/win arch, but the sooner we 
> >>> start
> >>> testing the better.
> >> I'd be happy to have it in 2.3.2-staging. At this point, 2.3.1 is
> >> reserved for emergencies, more or less.
> > If you plan to wait for couple months with 2.3.1 release as stated then 
> > I'm afraid I'm lost why to introduce this 2.3.1 vs 2.3.2 bifurcation, but
> > whatever leads to paintbranch merge is good for me.
> 
> We don't really know how long 2.3.1 will be.

+1 depends on whether a critical bug is discovered soon after the 2.3.0
release.

> There have been times in
> the past did a release within a month. If we don't need to do anything
> super-fast, then I'll just merge 2.3.2-staging into 2.3.1-staging.

+1 I think this is a good plan.

Scott


signature.asc
Description: PGP signature

Re: Staging Branches

[Richard Heck]

On 02/14/2018 01:09 PM, Pavel Sanda wrote:
> Richard Heck wrote:
>>> can we merge the painting branch into 2.3.1 staging?
>>> I'm inclusively working on master without larger issues for quite some time
>>> now. That does not say anything about mac/win arch, but the sooner we start
>>> testing the better.
>> I'd be happy to have it in 2.3.2-staging. At this point, 2.3.1 is
>> reserved for emergencies, more or less.
> If you plan to wait for couple months with 2.3.1 release as stated then 
> I'm afraid I'm lost why to introduce this 2.3.1 vs 2.3.2 bifurcation, but
> whatever leads to paintbranch merge is good for me.

We don't really know how long 2.3.1 will be. There have been times in
the past did a release within a month. If we don't need to do anything
super-fast, then I'll just merge 2.3.2-staging into 2.3.1-staging.

Richard

Re: Staging Branches

[Pavel Sanda]

Richard Heck wrote:
> > can we merge the painting branch into 2.3.1 staging?
> > I'm inclusively working on master without larger issues for quite some time
> > now. That does not say anything about mac/win arch, but the sooner we start
> > testing the better.
> 
> I'd be happy to have it in 2.3.2-staging. At this point, 2.3.1 is
> reserved for emergencies, more or less.

If you plan to wait for couple months with 2.3.1 release as stated then 
I'm afraid I'm lost why to introduce this 2.3.1 vs 2.3.2 bifurcation, but
whatever leads to paintbranch merge is good for me.

Pavel

Re: Staging Branches

[Richard Heck]

On 02/14/2018 12:17 PM, Pavel Sanda wrote:
> Richard Heck wrote:
>> I've just created two staging branches: 2.3.1-staging and 2.3.2-staging.
>> Rules for committing to these are the same as for stable branch, i.e.,
>> clear it with me first.
> Richard/JMarc,
>
> can we merge the painting branch into 2.3.1 staging?
> I'm inclusively working on master without larger issues for quite some time
> now. That does not say anything about mac/win arch, but the sooner we start
> testing the better.

I'd be happy to have it in 2.3.2-staging. At this point, 2.3.1 is
reserved for emergencies, more or less.

Richard

Re: Staging Branches

[Richard Heck]

On 02/14/2018 11:13 AM, Jürgen Spitzmüller wrote:
> Am Mittwoch, den 14.02.2018, 10:15 -0500 schrieb Richard Heck:
>> I've just created two staging branches: 2.3.1-staging and 2.3.2-
>> staging.
>> Rules for committing to these are the same as for stable branch,
>> i.e.,
>> clear it with me first.
>>
>> As usual, the reason to create these is that we have some fixes
>> piling
>> up already, and I don't want to forget them.
> So we now have 5 branches to care for? (2.2.x, 2.3.x, the two stagings, and 
> master)

Not for very long. And things committed to 2.3.x (which is all but
closed) do not also need to be committed to the staging branches. I'll
deal with merging everything when the time comes.

Richard

Re: Staging Branches

[Pavel Sanda]

Richard Heck wrote:
> I've just created two staging branches: 2.3.1-staging and 2.3.2-staging.
> Rules for committing to these are the same as for stable branch, i.e.,
> clear it with me first.

Richard/JMarc,

can we merge the painting branch into 2.3.1 staging?
I'm inclusively working on master without larger issues for quite some time
now. That does not say anything about mac/win arch, but the sooner we start
testing the better.

Pavel

Re: Staging Branches

[Jürgen Spitzmüller]

Am Mittwoch, den 14.02.2018, 10:15 -0500 schrieb Richard Heck:
> I've just created two staging branches: 2.3.1-staging and 2.3.2-
> staging.
> Rules for committing to these are the same as for stable branch,
> i.e.,
> clear it with me first.
> 
> As usual, the reason to create these is that we have some fixes
> piling
> up already, and I don't want to forget them.

So we now have 5 branches to care for? (2.2.x, 2.3.x, the two stagings,
and master)

Jürgen


> 
> Richard
> 
> 
> 

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

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)?

Re: Staging Branches

[Richard Heck]

On 04/16/2016 01:45 PM, Jean-Marc Lasgouttes wrote:
> Le 16/04/16 19:31, Scott Kostyshak a écrit :
>> On Sat, Apr 16, 2016 at 08:34:47AM -0400, Richard Heck wrote:
>>
>>> As usual, fixes for bugs committed to 2.2.1-staging (=2.2.x) should
>>> first be
>>> committed to 2.3-staging (=master). These should be marked
>>> "fixedinmaster"
>>> in trac but NOT "fixedinstable" and tagged with milestone 2.2.1.
>>
>> So now "fixedinmaster" does not necessarily mean "fixed in the next
>> major release" (2.2.0). This is confusing I think. But on the other hand
>> creating another category (e.g. fixedinstaging) would also be confusing.
>
> I am not sure what the point of 2.2.1-staging is. What are the urgent
> fixes for 2.2.1 that one would not want to have in 2.2.0? A
> 2.2.2-staging branch would make more sense to me.

Yes, I agree, but for some reason didn't create it. I'll resend the message.

Richard

Re: Staging Branches

[Richard Heck]

On 04/16/2016 01:31 PM, Scott Kostyshak wrote:
> On Sat, Apr 16, 2016 at 08:34:47AM -0400, Richard Heck wrote:
>
>> As usual, fixes for bugs committed to 2.2.1-staging (=2.2.x) should first be
>> committed to 2.3-staging (=master). These should be marked "fixedinmaster"
>> in trac but NOT "fixedinstable" and tagged with milestone 2.2.1.
> So now "fixedinmaster" does not necessarily mean "fixed in the next
> major release" (2.2.0). This is confusing I think. But on the other hand 
> creating another category (e.g. fixedinstaging) would also be confusing.

Oh, sorry, yes, you are right. But probably we can do this with
keywords. I'm about to send a revised message

Richard

Re: Staging Branches

[Scott Kostyshak]

On Sat, Apr 16, 2016 at 07:04:01PM +0100, Guillaume Munch wrote:
> Le 16/04/2016 18:55, Scott Kostyshak a écrit :
> > On Sat, Apr 16, 2016 at 07:45:29PM +0200, Jean-Marc Lasgouttes wrote:
> > > Le 16/04/16 19:31, Scott Kostyshak a écrit :
> > > > On Sat, Apr 16, 2016 at 08:34:47AM -0400, Richard Heck wrote:
> > > > 
> > > > > As usual, fixes for bugs committed to 2.2.1-staging (=2.2.x) should 
> > > > > first be
> > > > > committed to 2.3-staging (=master). These should be marked 
> > > > > "fixedinmaster"
> > > > > in trac but NOT "fixedinstable" and tagged with milestone 2.2.1.
> > > > 
> > > > So now "fixedinmaster" does not necessarily mean "fixed in the next
> > > > major release" (2.2.0). This is confusing I think. But on the other hand
> > > > creating another category (e.g. fixedinstaging) would also be confusing.
> > > 
> > > I am not sure what the point of 2.2.1-staging is. What are the urgent 
> > > fixes
> > > for 2.2.1 that one would not want to have in 2.2.0? A 2.2.2-staging branch
> > > would make more sense to me.
> > 
> > This is a good question I've been trying to understand. Georg used the
> > phrase "really critical" and Richard "absolutely critical" and although
> > I at first disagreed slightly (wanting to remove the adverbs), the more
> > I think about it the more I agree.
> > 
> >  From what I understand, the idea is that we will hopefully release 2.2.0
> > soon, and so we have less time to catch something if it is wrong before
> > release. We will release 2.2.1 later than 2.2.0, so we have more time to
> > catch a problematic commit, and thus we can allow (slightly) riskier
> > commits to 2.2.1-staging.
> > 
> > I have not fully convinced myself of the above, but it is making more
> > and more sense to me. I'd be curious about the opinions of others.
> > 
> 
> 
> So not critical enough to be in 2.2.0, but critical enough that it
> cannot wait 2.2.2?

Yes. With every commit there is a risk. The risk is attenuated by
testing. The less time we have for testing, the higher the risk.
Whether to commit a patch or not depends on the benefit outweighing the
risk. The benefit for committing to 2.2.0 is the same as 2.2.1 (although
this could be argued), but the risk is higher for 2.2.0 than for 2.2.1
because the time before release is shorter.

Scott


signature.asc
Description: PGP signature

Re: Staging Branches

[Guillaume Munch]

Le 16/04/2016 18:55, Scott Kostyshak a écrit :

On Sat, Apr 16, 2016 at 07:45:29PM +0200, Jean-Marc Lasgouttes wrote:

Le 16/04/16 19:31, Scott Kostyshak a écrit :

On Sat, Apr 16, 2016 at 08:34:47AM -0400, Richard Heck wrote:


As usual, fixes for bugs committed to 2.2.1-staging (=2.2.x) should first be
committed to 2.3-staging (=master). These should be marked "fixedinmaster"
in trac but NOT "fixedinstable" and tagged with milestone 2.2.1.


So now "fixedinmaster" does not necessarily mean "fixed in the next
major release" (2.2.0). This is confusing I think. But on the other hand
creating another category (e.g. fixedinstaging) would also be confusing.


I am not sure what the point of 2.2.1-staging is. What are the urgent fixes
for 2.2.1 that one would not want to have in 2.2.0? A 2.2.2-staging branch
would make more sense to me.


This is a good question I've been trying to understand. Georg used the
phrase "really critical" and Richard "absolutely critical" and although
I at first disagreed slightly (wanting to remove the adverbs), the more
I think about it the more I agree.

 From what I understand, the idea is that we will hopefully release 2.2.0
soon, and so we have less time to catch something if it is wrong before
release. We will release 2.2.1 later than 2.2.0, so we have more time to
catch a problematic commit, and thus we can allow (slightly) riskier
commits to 2.2.1-staging.

I have not fully convinced myself of the above, but it is making more
and more sense to me. I'd be curious about the opinions of others.




So not critical enough to be in 2.2.0, but critical enough that it
cannot wait 2.2.2? I would need more than these adverbs to make sense of 
this.


In addition there is nowhere to backport commits from 2.3.0 intended for
2.2.2. I agree with Jean-Marc here, I think there is more use for a
2.2.2-staging branch, possibly later merged with 2.2.1 if it is decided
that no emergency 2.2.1 release is necessary.

Re: Staging Branches

[Scott Kostyshak]

On Sat, Apr 16, 2016 at 07:45:29PM +0200, Jean-Marc Lasgouttes wrote:
> Le 16/04/16 19:31, Scott Kostyshak a écrit :
> > On Sat, Apr 16, 2016 at 08:34:47AM -0400, Richard Heck wrote:
> > 
> > > As usual, fixes for bugs committed to 2.2.1-staging (=2.2.x) should first 
> > > be
> > > committed to 2.3-staging (=master). These should be marked "fixedinmaster"
> > > in trac but NOT "fixedinstable" and tagged with milestone 2.2.1.
> > 
> > So now "fixedinmaster" does not necessarily mean "fixed in the next
> > major release" (2.2.0). This is confusing I think. But on the other hand
> > creating another category (e.g. fixedinstaging) would also be confusing.
> 
> I am not sure what the point of 2.2.1-staging is. What are the urgent fixes
> for 2.2.1 that one would not want to have in 2.2.0? A 2.2.2-staging branch
> would make more sense to me.

This is a good question I've been trying to understand. Georg used the
phrase "really critical" and Richard "absolutely critical" and although
I at first disagreed slightly (wanting to remove the adverbs), the more
I think about it the more I agree.

From what I understand, the idea is that we will hopefully release 2.2.0
soon, and so we have less time to catch something if it is wrong before
release. We will release 2.2.1 later than 2.2.0, so we have more time to
catch a problematic commit, and thus we can allow (slightly) riskier
commits to 2.2.1-staging.

I have not fully convinced myself of the above, but it is making more
and more sense to me. I'd be curious about the opinions of others.

Scott


signature.asc
Description: PGP signature

Re: Staging Branches

[Jean-Marc Lasgouttes]

Le 16/04/16 19:31, Scott Kostyshak a écrit :

On Sat, Apr 16, 2016 at 08:34:47AM -0400, Richard Heck wrote:


As usual, fixes for bugs committed to 2.2.1-staging (=2.2.x) should first be
committed to 2.3-staging (=master). These should be marked "fixedinmaster"
in trac but NOT "fixedinstable" and tagged with milestone 2.2.1.


So now "fixedinmaster" does not necessarily mean "fixed in the next
major release" (2.2.0). This is confusing I think. But on the other hand
creating another category (e.g. fixedinstaging) would also be confusing.


I am not sure what the point of 2.2.1-staging is. What are the urgent 
fixes for 2.2.1 that one would not want to have in 2.2.0? A 
2.2.2-staging branch would make more sense to me.


JMarc

Re: Staging Branches

[Scott Kostyshak]

On Sat, Apr 16, 2016 at 08:34:47AM -0400, Richard Heck wrote:

> As usual, fixes for bugs committed to 2.2.1-staging (=2.2.x) should first be
> committed to 2.3-staging (=master). These should be marked "fixedinmaster"
> in trac but NOT "fixedinstable" and tagged with milestone 2.2.1.

So now "fixedinmaster" does not necessarily mean "fixed in the next
major release" (2.2.0). This is confusing I think. But on the other hand
creating another category (e.g. fixedinstaging) would also be confusing.

Scott


signature.asc
Description: PGP signature

Re: Staging Branches

[Scott Kostyshak]

On Sat, Apr 16, 2016 at 10:33:46AM -0400, Richard Heck wrote:
> On 04/16/2016 09:30 AM, Kornel Benko wrote:
> > Does it mean, the master is closed? Or in other words, what happens if 
> > someone commits in master?
> 
> My understanding is that master is still closed, except for absolutely
> critical fixes with Scott's approval, and that it will remain that way
> until 2.2.0 is released.

Yes, my understanding is the same. I think Georg described the same
philosophy and no one else objected.

> The point of having 2.3-staging is so that
> development can continue under those conditions, i.e., development that
> is targeted at 2.3. JMarc is doing some painting work (I think), for
> example.

> We talked about branching 2.2.x now and doing 2.2.0 development there,
> but this path wasn't the one chosen, because it was thought to be
> important that the 2.2.0 tag be in master, as all other such tags have been.

Indeed, I'm sure there is a better way than what we do but this way is
simple and clear to everyone and is consistent with what we did in the
past.

Scott


signature.asc
Description: PGP signature

Re: Staging Branches

[Richard Heck]

On 04/16/2016 09:30 AM, Kornel Benko wrote:
> Am Samstag, 16. April 2016 um 08:34:47, schrieb Richard Heck 
>> I have just created two staging branches, as discussed in a previous 
>> thread. These are:
>>
>>   2.3-staging
>>   2.2.1-staging
>>
>> The former 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 latter should be treated as 2.2.x usually is: It is open for commits 
>> to what will become the 2.2.x branch and is particularly intended for 
>> commits to that branch that will become part of 2.2.1. So commits to 
>> this branch need my approval. For the moment, only fixes for pretty 
>> serious bugs will be considered, as the current plan is for 2.2.1 to be 
>> a quick release that contains only fixes for serious bugs that emerge 
>> after release. This branch will be merged into 2.2.x once that has been 
>> branched from master.
>>
>> As usual, fixes for bugs committed to 2.2.1-staging (=2.2.x) should 
>> first be committed to 2.3-staging (=master). These should be marked 
>> "fixedinmaster" in trac but NOT "fixedinstable" and tagged with 
>> milestone 2.2.1.
>>
>> Fixes for other 2.2.x bugs should be committed to 2.3-staging and marked 
>> with milestone 2.2.2 in trac.If there's no bug report already, then 
>> create one. This will allow me to keep track of such bugs so that they 
>> can be committed to 2.2.x at a later date.
>>
>> Richard
> Does it mean, the master is closed? Or in other words, what happens if 
> someone commits in master?

My understanding is that master is still closed, except for absolutely
critical fixes with Scott's approval, and that it will remain that way
until 2.2.0 is released. The point of having 2.3-staging is so that
development can continue under those conditions, i.e., development that
is targeted at 2.3. JMarc is doing some painting work (I think), for
example.

We talked about branching 2.2.x now and doing 2.2.0 development there,
but this path wasn't the one chosen, because it was thought to be
important that the 2.2.0 tag be in master, as all other such tags have been.

Any commits made to master will still be in master once 2.3-staging is
merged into it, so there is no issue there.

Richard

Re: Staging Branches

[Kornel Benko]

Am Samstag, 16. April 2016 um 08:34:47, schrieb Richard Heck 
> 
> I have just created two staging branches, as discussed in a previous 
> thread. These are:
> 
>   2.3-staging
>   2.2.1-staging
> 
> The former 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 latter should be treated as 2.2.x usually is: It is open for commits 
> to what will become the 2.2.x branch and is particularly intended for 
> commits to that branch that will become part of 2.2.1. So commits to 
> this branch need my approval. For the moment, only fixes for pretty 
> serious bugs will be considered, as the current plan is for 2.2.1 to be 
> a quick release that contains only fixes for serious bugs that emerge 
> after release. This branch will be merged into 2.2.x once that has been 
> branched from master.
> 
> As usual, fixes for bugs committed to 2.2.1-staging (=2.2.x) should 
> first be committed to 2.3-staging (=master). These should be marked 
> "fixedinmaster" in trac but NOT "fixedinstable" and tagged with 
> milestone 2.2.1.
> 
> Fixes for other 2.2.x bugs should be committed to 2.3-staging and marked 
> with milestone 2.2.2 in trac.If there's no bug report already, then 
> create one. This will allow me to keep track of such bugs so that they 
> can be committed to 2.2.x at a later date.
> 
> Richard

Does it mean, the master is closed? Or in other words, what happens if someone 
commits in master?

Kornel

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