[URGENT RFC] Branching and reopening -unstable

[URGENT RFC] Branching and reopening -unstable

[Wei Liu]

Hi all

RC1 is going to be tagged this week (maybe today). We need to figure
out when to branch / reopen -unstable for committing and what rules
should be applied until 4.6 is out of the door.

Ian, Ian and I had a conversation IRL. We discussed several things,
but figured it is necessary to have more people involved before making
any decision.

Here is my recollection of the conversation.

Branching should be done at one of the RC tags. It might not be enough
time for us to reach consensus before tagging RC1, so I would say lets
branch at RC2 if we don't observe blocker bugs.

Maintainers should be responsible for both 4.6 branch and -unstable
branch.

As for bug fixes, here are two options.

Option 1: bug fixes go into -unstable, backport / cherry-pick bug
fixes back to 4.6. This seems to leave the tree in half frozen status
because we need to reject refactoring patches in case they cause
backporting failure.

Option 2: bug fixes go into 4.6, merge them to -unstable. If merge has
conflict and maintainers can't deal with that, the authors of those
changes in -unstable which cause conflict is responsible for fixing up
the conflict.

Ian and Ian, anything I miss? Anything to add?

Others, thoughts?

Wei.

Re: [URGENT RFC] Branching and reopening -unstable

[Ian Jackson]

Wei Liu writes ("[URGENT RFC] Branching and reopening -unstable"):
> Branching should be done at one of the RC tags. It might not be enough
> time for us to reach consensus before tagging RC1, so I would say lets
> branch at RC2 if we don't observe blocker bugs.
> 
> Maintainers should be responsible for both 4.6 branch and -unstable
> branch.
> 
> As for bug fixes, here are two options.

I think this conflates the three questions which should be answered:

 Q1: What is the status of the newly branched -unstable ?  Should
     we avoid (some or all) big sets of changes ?
      (a) Don't branch
      (b) Branch but don't allow /any/ big changes.
          Seems to make branching rather pointless.
      (c) Branch but allow /some/ big changes.
          Tree is `half open', which is not ideal.
      (d) Branch and allow /all/ changes.

 Q2: If we don't avoid such changes, and a bugfix has a conflict
     with a change in the new unstable, who is responsible for fixing
     it up ?  Options include:
      (a) the relevant maintainers (double whammy for maintainers)
      (b) the submitter of the bugfix (very undesirable)
      (c) the submitter of the big set of changes (but what do
            we do if they don't respond?)
      (d) the stable tree maintainers (already ruled out, so included
            in this list for completeness; out of the question IMO)

 Q3: What workflow should we use, for bugfixes for bugs in 4.6-pre ?
    There are three options, not two:

      (a) Bugfixes go to 4.6 first, cherry pick to unstable
          This keeps our focus on 4.6, which is good.

      (b) Bugfixes go to 4.6 first, merge 4.6 to unstable.
          Not tenable if we have big changes in unstable.

      (c) Bugfixes to to unstable, cherry pick to 4.6.
          Undesirable IMO because it shifts focus to unstable.

Of these 2(c)/3(a) would be ideal but we don't have a good answer to
the problem posted in Q2(c).  I think that leaves us with 2(a):
maintainers have to deal with the fallout.

That makes 1(d) untenable in my view.  As a maintainer, I do not want
that additional workload.  That leaves us with 1(a) or 1(c)/2(a)/3(a).

With 1(c), who should decide on a particular series ?  Well, who is
taking the risk ?  The maintainer, who will have to pick up the
pieces.  I therefore conclude, we have two options:

A "1(a)/-/-"

  Do not branch yet: defer divergence until the risk of bugfixes is
  much lower.

B "1(c)(maintainer)/2(a)/3(a)"

  Branch.

  Maintainers may choose to defer patch series based on risk of
  conflicts with bugfixes required for 4.6.  Clear communication with
  submitters is required.

  Bugfixes for bugs in 4.6 will be accepted onto the 4.6 branch.
  Maintainers are required to cherry pick them onto unstable.

  Bugfixes will not be accepted for unstable unless it is clear that
  the bug was introduced in unstable since 4.6 branched.

I am happy with B because it gives the relevant maintainers the
option.

Ian.

Re: [URGENT RFC] Branching and reopening -unstable

[Wei Liu]

CCing Hongyang, I missed him when I copy-n-paste emails from MAINTAINERS.

On Tue, Aug 11, 2015 at 11:44:07AM +0100, Wei Liu wrote:
> Hi all
> 
> RC1 is going to be tagged this week (maybe today). We need to figure
> out when to branch / reopen -unstable for committing and what rules
> should be applied until 4.6 is out of the door.
> 
> Ian, Ian and I had a conversation IRL. We discussed several things,
> but figured it is necessary to have more people involved before making
> any decision.
> 
> Here is my recollection of the conversation.
> 
> Branching should be done at one of the RC tags. It might not be enough
> time for us to reach consensus before tagging RC1, so I would say lets
> branch at RC2 if we don't observe blocker bugs.
> 
> Maintainers should be responsible for both 4.6 branch and -unstable
> branch.
> 
> As for bug fixes, here are two options.
> 
> Option 1: bug fixes go into -unstable, backport / cherry-pick bug
> fixes back to 4.6. This seems to leave the tree in half frozen status
> because we need to reject refactoring patches in case they cause
> backporting failure.
> 
> Option 2: bug fixes go into 4.6, merge them to -unstable. If merge has
> conflict and maintainers can't deal with that, the authors of those
> changes in -unstable which cause conflict is responsible for fixing up
> the conflict.
> 
> Ian and Ian, anything I miss? Anything to add?
> 
> Others, thoughts?
> 
> Wei.

Re: [URGENT RFC] Branching and reopening -unstable

[Lars Kurth]

> On 11 Aug 2015, at 12:13, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> 
> Wei Liu writes ("[URGENT RFC] Branching and reopening -unstable"):
>> Branching should be done at one of the RC tags. It might not be enough
>> time for us to reach consensus before tagging RC1, so I would say lets
>> branch at RC2 if we don't observe blocker bugs.
>> 
>> Maintainers should be responsible for both 4.6 branch and -unstable
>> branch.
>> 
>> As for bug fixes, here are two options.


What do other projects that are similar to us do? And how does it work for them? Any reference points?

> I think this conflates the three questions which should be answered:
> 
> Q1: What is the status of the newly branched -unstable ?  Should
>     we avoid (some or all) big sets of changes ?
>      (a) Don't branch
>      (b) Branch but don't allow /any/ big changes.
>          Seems to make branching rather pointless.
>      (c) Branch but allow /some/ big changes.
>          Tree is `half open', which is not ideal.
>      (d) Branch and allow /all/ changes.
> 
> Q2: If we don't avoid such changes, and a bugfix has a conflict
>     with a change in the new unstable, who is responsible for fixing
>     it up ?  Options include:
>      (a) the relevant maintainers (double whammy for maintainers)
>      (b) the submitter of the bugfix (very undesirable)
>      (c) the submitter of the big set of changes (but what do
>            we do if they don't respond?)
>      (d) the stable tree maintainers (already ruled out, so included
>            in this list for completeness; out of the question IMO)
> 
> Q3: What workflow should we use, for bugfixes for bugs in 4.6-pre ?
>    There are three options, not two:
> 
>      (a) Bugfixes go to 4.6 first, cherry pick to unstable
>          This keeps our focus on 4.6, which is good.
> 
>      (b) Bugfixes go to 4.6 first, merge 4.6 to unstable.
>          Not tenable if we have big changes in unstable.
> 
>      (c) Bugfixes to to unstable, cherry pick to 4.6.
>          Undesirable IMO because it shifts focus to unstable.
> 
> Of these 2(c)/3(a) would be ideal but we don't have a good answer to
> the problem posted in Q2(c).  I think that leaves us with 2(a):
> maintainers have to deal with the fallout.
> 
> That makes 1(d) untenable in my view.  As a maintainer, I do not want
> that additional workload.  That leaves us with 1(a) or 1(c)/2(a)/3(a).
> 
> With 1(c), who should decide on a particular series ?  Well, who is
> taking the risk ?  The maintainer, who will have to pick up the
> pieces.  I therefore conclude, we have two options:
> 
> A "1(a)/-/-"
> 
>  Do not branch yet: defer divergence until the risk of bugfixes is
>  much lower.
> 
> B "1(c)(maintainer)/2(a)/3(a)"
> 
>  Branch.
> 
>  Maintainers may choose to defer patch series based on risk of
>  conflicts with bugfixes required for 4.6.  Clear communication with
>  submitters is required.
> 
>  Bugfixes for bugs in 4.6 will be accepted onto the 4.6 branch.
>  Maintainers are required to cherry pick them onto unstable.
> 
>  Bugfixes will not be accepted for unstable unless it is clear that
>  the bug was introduced in unstable since 4.6 branched.
> 
> I am happy with B because it gives the relevant maintainers the
> option.
> 
> Ian.

It may be helpful, to evaluate this proposal against a couple of the outstanding patch series which were close and didn't make it into 4.6. In other words, change sets which we reasonably expect to turn up in the next 4-8 weeks or so. 

Regards
Lars

Re: [URGENT RFC] Branching and reopening -unstable

[Jan Beulich]

>>> On 11.08.15 at 12:44, <wei.liu2@citrix.com> wrote:
> As for bug fixes, here are two options.
> 
> Option 1: bug fixes go into -unstable, backport / cherry-pick bug
> fixes back to 4.6. This seems to leave the tree in half frozen status
> because we need to reject refactoring patches in case they cause
> backporting failure.
> 
> Option 2: bug fixes go into 4.6, merge them to -unstable. If merge has
> conflict and maintainers can't deal with that, the authors of those
> changes in -unstable which cause conflict is responsible for fixing up
> the conflict.

I don't see why even on #2 bug fixes shouldn't go into -unstable
first - as usual backports should carry a reference to the master
commit.

And personally I'd favor the revised #2 over #1 or unrevised #2.

Jan

Re: [URGENT RFC] Branching and reopening -unstable

[Ian Campbell]

On Tue, 2015-08-11 at 12:13 +0100, Ian Jackson wrote:
> Wei Liu writes ("[URGENT RFC] Branching and reopening -unstable"):
> > Branching should be done at one of the RC tags. It might not be enough
> > time for us to reach consensus before tagging RC1, so I would say lets
> > branch at RC2 if we don't observe blocker bugs.
> > 
> > Maintainers should be responsible for both 4.6 branch and -unstable
> > branch.
> > 
> > As for bug fixes, here are two options.
> 
> I think this conflates the three questions which should be answered:
> 
>  Q1: What is the status of the newly branched -unstable ?  Should
>      we avoid (some or all) big sets of changes ?
>       (a) Don't branch
>       (b) Branch but don't allow /any/ big changes.
>           Seems to make branching rather pointless.
>       (c) Branch but allow /some/ big changes.
>           Tree is `half open', which is not ideal.
>       (d) Branch and allow /all/ changes.
> 
>  Q2: If we don't avoid such changes, and a bugfix has a conflict
>      with a change in the new unstable, who is responsible for fixing
>      it up ?  Options include:
>       (a) the relevant maintainers (double whammy for maintainers)
>       (b) the submitter of the bugfix (very undesirable)
>       (c) the submitter of the big set of changes (but what do
>             we do if they don't respond?)
>       (d) the stable tree maintainers (already ruled out, so included
>             in this list for completeness; out of the question IMO)
> 
>  Q3: What workflow should we use, for bugfixes for bugs in 4.6-pre ?
>     There are three options, not two:
> 
>       (a) Bugfixes go to 4.6 first, cherry pick to unstable
>           This keeps our focus on 4.6, which is good.
> 
>       (b) Bugfixes go to 4.6 first, merge 4.6 to unstable.
>           Not tenable if we have big changes in unstable.
> 
>       (c) Bugfixes to to unstable, cherry pick to 4.6.
>           Undesirable IMO because it shifts focus to unstable.

FWIW I think historically we have always done (c) here. That's not to say
we shouldn't change but thought it worth noting.

> Of these 2(c)/3(a) would be ideal but we don't have a good answer to
> the problem posted in Q2(c).  I think that leaves us with 2(a):
> maintainers have to deal with the fallout.
> 
> That makes 1(d) untenable in my view.  As a maintainer, I do not want
> that additional workload.  That leaves us with 1(a) or 1(c)/2(a)/3(a).
> 
> With 1(c), who should decide on a particular series ?  Well, who is
> taking the risk ?  The maintainer, who will have to pick up the
> pieces.  I therefore conclude, we have two options:
> 
> A "1(a)/-/-"
> 
>   Do not branch yet: defer divergence until the risk of bugfixes is
>   much lower.
> 
> B "1(c)(maintainer)/2(a)/3(a)"
> 
>   Branch.
> 
>   Maintainers may choose to defer patch series based on risk of
>   conflicts with bugfixes required for 4.6.  Clear communication with
>   submitters is required.
> 
>   Bugfixes for bugs in 4.6 will be accepted onto the 4.6 branch.
>   Maintainers are required to cherry pick them onto unstable.
> 
>   Bugfixes will not be accepted for unstable unless it is clear that
>   the bug was introduced in unstable since 4.6 branched.
> 
> I am happy with B because it gives the relevant maintainers the
> option.
> 
> Ian.

Re: [URGENT RFC] Branching and reopening -unstable

[Andrew Cooper]

On 11/08/15 12:13, Ian Jackson wrote:
> Wei Liu writes ("[URGENT RFC] Branching and reopening -unstable"):
>> Branching should be done at one of the RC tags. It might not be enough
>> time for us to reach consensus before tagging RC1, so I would say lets
>> branch at RC2 if we don't observe blocker bugs.
>>
>> Maintainers should be responsible for both 4.6 branch and -unstable
>> branch.
>>
>> As for bug fixes, here are two options.
> I think this conflates the three questions which should be answered:
>
>  Q1: What is the status of the newly branched -unstable ?  Should
>      we avoid (some or all) big sets of changes ?
>       (a) Don't branch
>       (b) Branch but don't allow /any/ big changes.
>           Seems to make branching rather pointless.
>       (c) Branch but allow /some/ big changes.
>           Tree is `half open', which is not ideal.
>       (d) Branch and allow /all/ changes.
>
>  Q2: If we don't avoid such changes, and a bugfix has a conflict
>      with a change in the new unstable, who is responsible for fixing
>      it up ?  Options include:
>       (a) the relevant maintainers (double whammy for maintainers)
>       (b) the submitter of the bugfix (very undesirable)
>       (c) the submitter of the big set of changes (but what do
>             we do if they don't respond?)
>       (d) the stable tree maintainers (already ruled out, so included
>             in this list for completeness; out of the question IMO)
>
>  Q3: What workflow should we use, for bugfixes for bugs in 4.6-pre ?
>     There are three options, not two:
>
>       (a) Bugfixes go to 4.6 first, cherry pick to unstable
>           This keeps our focus on 4.6, which is good.
>
>       (b) Bugfixes go to 4.6 first, merge 4.6 to unstable.
>           Not tenable if we have big changes in unstable.
>
>       (c) Bugfixes to to unstable, cherry pick to 4.6.
>           Undesirable IMO because it shifts focus to unstable.
>
> Of these 2(c)/3(a) would be ideal but we don't have a good answer to
> the problem posted in Q2(c).  I think that leaves us with 2(a):
> maintainers have to deal with the fallout.
>
> That makes 1(d) untenable in my view.  As a maintainer, I do not want
> that additional workload.  That leaves us with 1(a) or 1(c)/2(a)/3(a).
>
> With 1(c), who should decide on a particular series ?  Well, who is
> taking the risk ?  The maintainer, who will have to pick up the
> pieces.  I therefore conclude, we have two options:
>
> A "1(a)/-/-"
>
>   Do not branch yet: defer divergence until the risk of bugfixes is
>   much lower.
>
> B "1(c)(maintainer)/2(a)/3(a)"
>
>   Branch.
>
>   Maintainers may choose to defer patch series based on risk of
>   conflicts with bugfixes required for 4.6.  Clear communication with
>   submitters is required.
>
>   Bugfixes for bugs in 4.6 will be accepted onto the 4.6 branch.
>   Maintainers are required to cherry pick them onto unstable.
>
>   Bugfixes will not be accepted for unstable unless it is clear that
>   the bug was introduced in unstable since 4.6 branched.
>
> I am happy with B because it gives the relevant maintainers the
> option.

Very much A.

By definition, 1(c) will destabilise the tree and generate artificial
work for the maintainers and committers.

The most important action at this point is to stabilise 4.6 for release,
and peoples efforts are far better spent pursuing that, rather than
continuing work on unstable.

For the sake of a couple of weeks, contributors can keep their patches
for a little while longer.

~Andrew

Re: [URGENT RFC] Branching and reopening -unstable

[Stefano Stabellini]

On Tue, 11 Aug 2015, Wei Liu wrote:
> Hi all
> 
> RC1 is going to be tagged this week (maybe today). We need to figure
> out when to branch / reopen -unstable for committing and what rules
> should be applied until 4.6 is out of the door.
> 
> Ian, Ian and I had a conversation IRL. We discussed several things,
> but figured it is necessary to have more people involved before making
> any decision.
> 
> Here is my recollection of the conversation.
> 
> Branching should be done at one of the RC tags. It might not be enough
> time for us to reach consensus before tagging RC1, so I would say lets
> branch at RC2 if we don't observe blocker bugs.
> 
> Maintainers should be responsible for both 4.6 branch and -unstable
> branch.
> 
> As for bug fixes, here are two options.
> 
> Option 1: bug fixes go into -unstable, backport / cherry-pick bug
> fixes back to 4.6. This seems to leave the tree in half frozen status
> because we need to reject refactoring patches in case they cause
> backporting failure.
> 
> Option 2: bug fixes go into 4.6, merge them to -unstable. If merge has
> conflict and maintainers can't deal with that, the authors of those
> changes in -unstable which cause conflict is responsible for fixing up
> the conflict.
> 
> Ian and Ian, anything I miss? Anything to add?
> 
> Others, thoughts?

I don't see why Option 1 should be different from Option 2 in terms of
dealing with conflicts. I think that in both cases we should just ask
contributors for help to fix the conflict.

So I would go for a revised Option 1:

Option 1b: bug fixes go into -unstable, backport / cherry-pick bug fixes
back to 4.6. If merge has conflict and maintainers can't deal with that,
the authors of those changes in -unstable which cause conflict is
responsible for fixing up the conflict.

Re: [URGENT RFC] Branching and reopening -unstable

[Stefano Stabellini]

On Tue, 11 Aug 2015, Ian Jackson wrote:
> Wei Liu writes ("[URGENT RFC] Branching and reopening -unstable"):
> > Branching should be done at one of the RC tags. It might not be enough
> > time for us to reach consensus before tagging RC1, so I would say lets
> > branch at RC2 if we don't observe blocker bugs.
> > 
> > Maintainers should be responsible for both 4.6 branch and -unstable
> > branch.
> > 
> > As for bug fixes, here are two options.
> 
> I think this conflates the three questions which should be answered:
> 
>  Q1: What is the status of the newly branched -unstable ?  Should
>      we avoid (some or all) big sets of changes ?
>       (a) Don't branch
>       (b) Branch but don't allow /any/ big changes.
>           Seems to make branching rather pointless.
>       (c) Branch but allow /some/ big changes.
>           Tree is `half open', which is not ideal.
>       (d) Branch and allow /all/ changes.
> 
>  Q2: If we don't avoid such changes, and a bugfix has a conflict
>      with a change in the new unstable, who is responsible for fixing
>      it up ?  Options include:
>       (a) the relevant maintainers (double whammy for maintainers)
>       (b) the submitter of the bugfix (very undesirable)

Why is it very undesirable?

In the Linux community for example is customary to provide a patch for
each of the stable trees you need backports to, in case there are any
merge conflicts. This would be the same.


>       (c) the submitter of the big set of changes (but what do
>             we do if they don't respond?)
>       (d) the stable tree maintainers (already ruled out, so included
>             in this list for completeness; out of the question IMO)
> 
>  Q3: What workflow should we use, for bugfixes for bugs in 4.6-pre ?
>     There are three options, not two:
> 
>       (a) Bugfixes go to 4.6 first, cherry pick to unstable
>           This keeps our focus on 4.6, which is good.
> 
>       (b) Bugfixes go to 4.6 first, merge 4.6 to unstable.
>           Not tenable if we have big changes in unstable.
> 
>       (c) Bugfixes to to unstable, cherry pick to 4.6.
>           Undesirable IMO because it shifts focus to unstable.
> 
> Of these 2(c)/3(a) would be ideal but we don't have a good answer to
> the problem posted in Q2(c).  I think that leaves us with 2(a):
> maintainers have to deal with the fallout.
> 
> That makes 1(d) untenable in my view.  As a maintainer, I do not want
> that additional workload.  That leaves us with 1(a) or 1(c)/2(a)/3(a).
> 
> With 1(c), who should decide on a particular series ?  Well, who is
> taking the risk ?  The maintainer, who will have to pick up the
> pieces.  I therefore conclude, we have two options:
> 
> A "1(a)/-/-"
> 
>   Do not branch yet: defer divergence until the risk of bugfixes is
>   much lower.
> 
> B "1(c)(maintainer)/2(a)/3(a)"
> 
>   Branch.
> 
>   Maintainers may choose to defer patch series based on risk of
>   conflicts with bugfixes required for 4.6.  Clear communication with
>   submitters is required.
> 
>   Bugfixes for bugs in 4.6 will be accepted onto the 4.6 branch.
>   Maintainers are required to cherry pick them onto unstable.
> 
>   Bugfixes will not be accepted for unstable unless it is clear that
>   the bug was introduced in unstable since 4.6 branched.
> 
> I am happy with B because it gives the relevant maintainers the
> option.
> 
> Ian.
> 

Re: [URGENT RFC] Branching and reopening -unstable

[Ian Campbell]

On Tue, 2015-08-11 at 13:55 +0100, Andrew Cooper wrote:
> On 11/08/15 12:13, Ian Jackson wrote:
> > Wei Liu writes ("[URGENT RFC] Branching and reopening -unstable"):
> > > Branching should be done at one of the RC tags. It might not be 
> > > enough
> > > time for us to reach consensus before tagging RC1, so I would say 
> > > lets
> > > branch at RC2 if we don't observe blocker bugs.
> > > 
> > > Maintainers should be responsible for both 4.6 branch and -unstable
> > > branch.
> > > 
> > > As for bug fixes, here are two options.
> > I think this conflates the three questions which should be answered:
> > 
> >  Q1: What is the status of the newly branched -unstable ?  Should
> >      we avoid (some or all) big sets of changes ?
> >       (a) Don't branch
> >       (b) Branch but don't allow /any/ big changes.
> >           Seems to make branching rather pointless.
> >       (c) Branch but allow /some/ big changes.
> >           Tree is `half open', which is not ideal.
> >       (d) Branch and allow /all/ changes.
> > 
> >  Q2: If we don't avoid such changes, and a bugfix has a conflict
> >      with a change in the new unstable, who is responsible for fixing
> >      it up ?  Options include:
> >       (a) the relevant maintainers (double whammy for maintainers)
> >       (b) the submitter of the bugfix (very undesirable)
> >       (c) the submitter of the big set of changes (but what do
> >             we do if they don't respond?)
> >       (d) the stable tree maintainers (already ruled out, so included
> >             in this list for completeness; out of the question IMO)
> > 
> >  Q3: What workflow should we use, for bugfixes for bugs in 4.6-pre ?
> >     There are three options, not two:
> > 
> >       (a) Bugfixes go to 4.6 first, cherry pick to unstable
> >           This keeps our focus on 4.6, which is good.
> > 
> >       (b) Bugfixes go to 4.6 first, merge 4.6 to unstable.
> >           Not tenable if we have big changes in unstable.
> > 
> >       (c) Bugfixes to to unstable, cherry pick to 4.6.
> >           Undesirable IMO because it shifts focus to unstable.
> > 
> > Of these 2(c)/3(a) would be ideal but we don't have a good answer to
> > the problem posted in Q2(c).  I think that leaves us with 2(a):
> > maintainers have to deal with the fallout.
> > 
> > That makes 1(d) untenable in my view.  As a maintainer, I do not want
> > that additional workload.  That leaves us with 1(a) or 1(c)/2(a)/3(a).
> > 
> > With 1(c), who should decide on a particular series ?  Well, who is
> > taking the risk ?  The maintainer, who will have to pick up the
> > pieces.  I therefore conclude, we have two options:
> > 
> > A "1(a)/-/-"
> > 
> >   Do not branch yet: defer divergence until the risk of bugfixes is
> >   much lower.
> > 
> > B "1(c)(maintainer)/2(a)/3(a)"
> > 
> >   Branch.
> > 
> >   Maintainers may choose to defer patch series based on risk of
> >   conflicts with bugfixes required for 4.6.  Clear communication with
> >   submitters is required.
> > 
> >   Bugfixes for bugs in 4.6 will be accepted onto the 4.6 branch.
> >   Maintainers are required to cherry pick them onto unstable.
> > 
> >   Bugfixes will not be accepted for unstable unless it is clear that
> >   the bug was introduced in unstable since 4.6 branched.
> > 
> > I am happy with B because it gives the relevant maintainers the
> > option.
> 
> Very much A.
> 
> By definition, 1(c) will destabilise the tree and generate artificial
> work for the maintainers and committers.
> 
> The most important action at this point is to stabilise 4.6 for release,
> and peoples efforts are far better spent pursuing that, rather than
> continuing work on unstable.

While I agree that people who have things to do for the release should
prioritise the release not all contributors have a stake in the stable
releases and even those that do may not have anything which they are able
to help with etc (or e.g. have other pressures which prevent them dropping
all development work to dedicate full time to the release).

Realistically even those with 4.6-ish tasks and responsibilities aren't
going to have enough such things to do to fill their time 100% between now
and the release.

> For the sake of a couple of weeks, contributors can keep their patches
> for a little while longer.

A full freeze cycle is more like 6-8 weeks not a "couple", which is where
the tension arises between the stable release and other developers.

What seems to have been missed (or gotten a bit mislaid) in the current
analysis is _when_ to branch, the analysis assumes at rc1 while the status
quo for the last few releases has been just before release (or very late in
the rc cycle at least), which are two opposite ends of the spectrum.

There is of course plenty of middle ground between those two points. In
your use of "a couple of weeks" are you making a counter proposal to branch
at (say) rc3 or are you arguing to keep the development branch closed until
9 October?

Depending on where in the rc cycle we branch different options may have
different weights of up or down side.

Ian.

> 
> ~Andrew

Re: [URGENT RFC] Branching and reopening -unstable

[Yang Hongyang]

Hi Wei,

Thanks for CCing me, for me, I prefer option 2, it won't affect the normal
development release cycle, if the contributor wants to contribute to
-unstable, then it is his responsibility to resolve the confilicts on the
main branch. but I think it depends on the maintainers who will make the
decision.

On 08/11/2015 08:31 PM, Wei Liu wrote:
> CCing Hongyang, I missed him when I copy-n-paste emails from MAINTAINERS.
>
> On Tue, Aug 11, 2015 at 11:44:07AM +0100, Wei Liu wrote:
>> Hi all
>>
>> RC1 is going to be tagged this week (maybe today). We need to figure
>> out when to branch / reopen -unstable for committing and what rules
>> should be applied until 4.6 is out of the door.
>>
>> Ian, Ian and I had a conversation IRL. We discussed several things,
>> but figured it is necessary to have more people involved before making
>> any decision.
>>
>> Here is my recollection of the conversation.
>>
>> Branching should be done at one of the RC tags. It might not be enough
>> time for us to reach consensus before tagging RC1, so I would say lets
>> branch at RC2 if we don't observe blocker bugs.
>>
>> Maintainers should be responsible for both 4.6 branch and -unstable
>> branch.
>>
>> As for bug fixes, here are two options.
>>
>> Option 1: bug fixes go into -unstable, backport / cherry-pick bug
>> fixes back to 4.6. This seems to leave the tree in half frozen status
>> because we need to reject refactoring patches in case they cause
>> backporting failure.
>>
>> Option 2: bug fixes go into 4.6, merge them to -unstable. If merge has
>> conflict and maintainers can't deal with that, the authors of those
>> changes in -unstable which cause conflict is responsible for fixing up
>> the conflict.
>>
>> Ian and Ian, anything I miss? Anything to add?
>>
>> Others, thoughts?
>>
>> Wei.
> .
>

-- 
Thanks,
Yang.

Re: [URGENT RFC] Branching and reopening -unstable

[George Dunlap]

On Tue, Aug 11, 2015 at 12:13 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> B "1(c)(maintainer)/2(a)/3(a)"
>
>   Branch.
>
>   Maintainers may choose to defer patch series based on risk of
>   conflicts with bugfixes required for 4.6.  Clear communication with
>   submitters is required.
>
>   Bugfixes for bugs in 4.6 will be accepted onto the 4.6 branch.
>   Maintainers are required to cherry pick them onto unstable.
>
>   Bugfixes will not be accepted for unstable unless it is clear that
>   the bug was introduced in unstable since 4.6 branched.
>
> I am happy with B because it gives the relevant maintainers the
> option.

Did we ever come to a conclusion on this?

FWIW I think Ian's proposal B here is the most sensible: the
maintainer evaluates each patch for how much work it will create them,
and decides whether they want to accept that work or not.

 -George

Re: [URGENT RFC] Branching and reopening -unstable

[Lars Kurth]

See http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg00282.html

> On 27 Aug 2015, at 15:42, George Dunlap <dunlapg@umich.edu> wrote:
> 
> On Tue, Aug 11, 2015 at 12:13 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>> B "1(c)(maintainer)/2(a)/3(a)"
>> 
>>  Branch.
>> 
>>  Maintainers may choose to defer patch series based on risk of
>>  conflicts with bugfixes required for 4.6.  Clear communication with
>>  submitters is required.
>> 
>>  Bugfixes for bugs in 4.6 will be accepted onto the 4.6 branch.
>>  Maintainers are required to cherry pick them onto unstable.
>> 
>>  Bugfixes will not be accepted for unstable unless it is clear that
>>  the bug was introduced in unstable since 4.6 branched.
>> 
>> I am happy with B because it gives the relevant maintainers the
>> option.
> 
> Did we ever come to a conclusion on this?
> 
> FWIW I think Ian's proposal B here is the most sensible: the
> maintainer evaluates each patch for how much work it will create them,
> and decides whether they want to accept that work or not.
> 
> -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel