Re: [sage-release] Re: Release process

[Volker Braun]

* Some buildbots are too slow to run the entire testsutie for every ticket
* Sometimes tests fail because of unrelated tickets are randomly failing
* Sometimes tests succeed even if the ticket introduces a random failure
* Sometimes buildbots are offline for a day, need rebooting, etc.
* Incremental builds may succeed but full rebuild might fail because of a 
ticket
 

On Wednesday, May 16, 2018 at 10:06:22 AM UTC+2, vdelecroix wrote:
>
> On 15/05/2018 17:07, Volker Braun wrote: 
> > The integration branch is going to have its history rewritten regularly. 
>
> Why is that? Shouldn't the process be simply 
>
>   1. create a branch TMP = "integration branch" + "merged positive 
> review ticket" 
>   2. if merge fails: move back ticket to needs work and go back to 1 
>   3. if any test fails: move back ticket to needs work and go back to 1 
>   4. set the integration branch to TMP and go back to 1 
>
> > The issue is that unsuspecting developers might *base* their 
> contribution 
> > on the integration branch (i.e. go to github and select the branch with 
> the 
> > most recent commits), and then have it yanked out from under their feet 
> > when I rewrite it. 
>
> This would indeed be terrible. But to my mind, this should not happen. 
>
> Best 
> Vincent 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Jeroen Demeyer]

On 2018-05-16 12:44, Vincent Delecroix wrote:

- "integration" is intended to be used by bots only to check whether
a given positively reviewed ticket is worth a merge. It has no
reason to be used by any human.


The issue is that it may be accidentally used by a human by mistake.

--
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Jeroen Demeyer]

On 2018-05-16 11:26, Vincent Delecroix wrote:

It can be smarter than a hash, e.g. 8.3.beta2018-05-16. And we can
afford a daily release at GMT 00:00.


If you want to automate it anyway, you could instead automatically 
release a new "beta" whenever develop is updated.


--
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Vincent Delecroix]

On 16/05/2018 10:57, Jeroen Demeyer wrote:

On 2018-05-16 10:30, Vincent Delecroix wrote:

And I agree: there should be two branches whatever
they are called. Let's go for "develop + integration" (that were
"integration" + "TMP" in my previous e-mail).


In that case, I fully agree with your previous e-mail!


As a consequence, we would abandon beta releases


Why? I like the idea of betas because it makes it easy to name things. I 
can say "I rebased this on top of 8.3.beta1" and everybody understands 
what I mean. On the other hand, "I rebased this on top of 
6fc1e20c666283a301b4ff3f855013de8d206b35" is not so clear.


It can be smarter than a hash, e.g. 8.3.beta2018-05-16. And we can
afford a daily release at GMT 00:00.

Vincent

--
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Jeroen Demeyer]

On 2018-05-16 10:30, Vincent Delecroix wrote:

And I agree: there should be two branches whatever
they are called. Let's go for "develop + integration" (that were
"integration" + "TMP" in my previous e-mail).


In that case, I fully agree with your previous e-mail!


As a consequence, we would abandon beta releases


Why? I like the idea of betas because it makes it easy to name things. I 
can say "I rebased this on top of 8.3.beta1" and everybody understands 
what I mean. On the other hand, "I rebased this on top of 
6fc1e20c666283a301b4ff3f855013de8d206b35" is not so clear.


--
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Vincent Delecroix]

On 16/05/2018 10:26, Jeroen Demeyer wrote:

On 2018-05-16 10:23, Vincent Delecroix wrote:

TMP is public! People should just not base their work on as it is
likely to be abandoned. On the other hand, people should be encouraged
to base their work on "integration" and not on "latest beta".


It seems that you're thinking that there are 3 branches (develop, 
integration and TMP) while in reality there are only two (develop and TMP).


It seems that you have too much imagination about my thinking. I never
mentioned 3 branches. And I agree: there should be two branches whatever
they are called. Let's go for "develop + integration" (that were
"integration" + "TMP" in my previous e-mail).

As a consequence, we would abandon beta releases and simply provide
snapshots of the develop branch. That can also be completely automatized.

Vincent

--
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Jeroen Demeyer]

On 2018-05-16 10:23, Vincent Delecroix wrote:

TMP is public! People should just not base their work on as it is
likely to be abandoned. On the other hand, people should be encouraged
to base their work on "integration" and not on "latest beta".


It seems that you're thinking that there are 3 branches (develop, 
integration and TMP) while in reality there are only two (develop and TMP).


--
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Vincent Delecroix]

On 16/05/2018 10:15, Jeroen Demeyer wrote:

On 2018-05-16 10:06, Vincent Delecroix wrote:

On 15/05/2018 17:07, Volker Braun wrote:

The integration branch is going to have its history rewritten regularly.


Why is that? Shouldn't the process be simply

   1. create a branch TMP = "integration branch" + "merged positive
 review ticket"
   2. if merge fails: move back ticket to needs work and go back to 1
   3. if any test fails: move back ticket to needs work and go back to 1
   4. set the integration branch to TMP and go back to 1


The integration branch *is* TMP. Otherwise you are just shifting the 
problem from "integration branch" to TMP and people will complain that 
TMP should be publicly accessible.


TMP is public! People should just not base their work on as it is
likely to be abandoned. On the other hand, people should be encouraged
to base their work on "integration" and not on "latest beta".

I think about integration as a "permanent beta" where tickets are merged
one by one.


IMHO the workflow should be:

1. create a branch integration = develop + some selection of positive 
review tickets

2. if merge fails: move back ticket to needs work and go back to 1 > 3. if any 
test fails: move back ticket to needs work and go back to 1
4. set develop to integration and go back to 

Your version is completely unclear:
 * which ticket are you talking about in 2,3,4?
 * "go back to 1": makes no sense. Step 1 consider "a selection
   of positive review tickets" that is unspecified.

--
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Jeroen Demeyer]

On 2018-05-16 10:06, Vincent Delecroix wrote:

On 15/05/2018 17:07, Volker Braun wrote:

The integration branch is going to have its history rewritten regularly.


Why is that? Shouldn't the process be simply

   1. create a branch TMP = "integration branch" + "merged positive
 review ticket"
   2. if merge fails: move back ticket to needs work and go back to 1
   3. if any test fails: move back ticket to needs work and go back to 1
   4. set the integration branch to TMP and go back to 1


The integration branch *is* TMP. Otherwise you are just shifting the 
problem from "integration branch" to TMP and people will complain that 
TMP should be publicly accessible.


IMHO the workflow should be:

1. create a branch integration = develop + some selection of positive 
review tickets

2. if merge fails: move back ticket to needs work and go back to 1
3. if any test fails: move back ticket to needs work and go back to 1
4. set develop to integration and go back to 1

--
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Vincent Delecroix]

On 15/05/2018 17:07, Volker Braun wrote:

The integration branch is going to have its history rewritten regularly.


Why is that? Shouldn't the process be simply

 1. create a branch TMP = "integration branch" + "merged positive
   review ticket"
 2. if merge fails: move back ticket to needs work and go back to 1
 3. if any test fails: move back ticket to needs work and go back to 1
 4. set the integration branch to TMP and go back to 1


The issue is that unsuspecting developers might *base* their contribution
on the integration branch (i.e. go to github and select the branch with the
most recent commits), and then have it yanked out from under their feet
when I rewrite it.


This would indeed be terrible. But to my mind, this should not happen.

Best
Vincent

--
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Samuel Lelièvre]

2018-05-15 18:59 GMT+02:00 Volker Braun :
>
> If you want better merge conflict information: extend the
> "git releasemgr merge " script (part of the
> git-trac repo) to diagnose which ticket the conflict came
> from. Then I'll be happy to include that info when setting
> the ticket back...

I opened an issue for that:

https://github.com/sagemath/git-trac-command/issues/29

If someone can provide this enhancement, that would be great!

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Volker Braun]

If you want better merge conflict information: extend the "git releasemgr 
merge " script (part of the git-trac repo) to diagnose which 
ticket the conflict came from. Then I'll be happy to include that info when 
setting the ticket back...

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Dima Pasechnik]

More helpful would be the info which trac tickets in the integration branch 
cause these merge failures.
While basing off the branch might be a no-no, adding some positively 
reviewed tickets as dependencies to a ticket does not break stuff, at least 
in my experience.

I can discover these tickets/branches by fetching the integration branch, 
but I'd rather prefer this info
to be posted in case of these merge conflicts.


On Tuesday, May 15, 2018 at 4:07:25 PM UTC+1, Volker Braun wrote:
>
> The integration branch is going to have its history rewritten regularly. 
> The issue is that unsuspecting developers might *base* their contribution 
> on the integration branch (i.e. go to github and select the branch with the 
> most recent commits), and then have it yanked out from under their feet 
> when I rewrite it.
>
>
>  
>
> On Tuesday, May 15, 2018 at 3:59:08 PM UTC+2, Erik Bray wrote:
>>
>> On Tue, May 15, 2018 at 3:11 PM, Jeroen Demeyer  
>> wrote: 
>> > On 2018-05-15 14:35, Erik Bray wrote: 
>> >> 
>> >> I'm not convinced that's a real problem.  This is what I meant by "yes 
>> >> its contents may change and shift rapidly, but for a sophisticated 
>> >> developer who just wants to peek in on the release process this is not 
>> >> a problem". 
>> > 
>> > 
>> > I agree that it's not a problem for the "sophisticated developer" who 
>> knows 
>> > what he is doing. But the more you advertise this secret branch, the 
>> larger 
>> > chance there is of abuse by non-sophisticated developers who have no 
>> clue. I 
>> > believe that this is the point that Maarten was trying to make. 
>>
>> I don't see much chance for "abuse".  Mostly all I'm talking about 
>> here is to do integration in a branch that's easy to identify and is 
>> documented (it can even be documented as "this branch is unstable so 
>> don't look at it unless you know what you're doing".  The worse 
>> someone can bite themselves is by maybe rebasing a branch on top of 
>> that branch, and then proposing that version of the branch for merging 
>> which might not always be for the best (though it might often be fine 
>> too).  To make this mistake would require knowing how to use rebase in 
>> the first place... 
>>
>> On Tue, May 15, 2018 at 3:49 PM, Jeroen Demeyer  
>> wrote: 
>> > On 2018-05-15 15:40, Emmanuel Charpentier wrote: 
>> >> 
>> >> Therefore, I think that contributing to Sage should not *require* a 
>> >> sophisticated understanding of the finer points of git care and 
>> feeding... 
>> > 
>> > 
>> > Of course not. I don't think that anybody here proposed that. 
>>
>> Nope, but as I wrote upthread this discussion is still orthogonal to 
>> what I wanted to propose... 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Volker Braun]

The integration branch is going to have its history rewritten regularly. 
The issue is that unsuspecting developers might *base* their contribution 
on the integration branch (i.e. go to github and select the branch with the 
most recent commits), and then have it yanked out from under their feet 
when I rewrite it.


 

On Tuesday, May 15, 2018 at 3:59:08 PM UTC+2, Erik Bray wrote:
>
> On Tue, May 15, 2018 at 3:11 PM, Jeroen Demeyer  > wrote: 
> > On 2018-05-15 14:35, Erik Bray wrote: 
> >> 
> >> I'm not convinced that's a real problem.  This is what I meant by "yes 
> >> its contents may change and shift rapidly, but for a sophisticated 
> >> developer who just wants to peek in on the release process this is not 
> >> a problem". 
> > 
> > 
> > I agree that it's not a problem for the "sophisticated developer" who 
> knows 
> > what he is doing. But the more you advertise this secret branch, the 
> larger 
> > chance there is of abuse by non-sophisticated developers who have no 
> clue. I 
> > believe that this is the point that Maarten was trying to make. 
>
> I don't see much chance for "abuse".  Mostly all I'm talking about 
> here is to do integration in a branch that's easy to identify and is 
> documented (it can even be documented as "this branch is unstable so 
> don't look at it unless you know what you're doing".  The worse 
> someone can bite themselves is by maybe rebasing a branch on top of 
> that branch, and then proposing that version of the branch for merging 
> which might not always be for the best (though it might often be fine 
> too).  To make this mistake would require knowing how to use rebase in 
> the first place... 
>
> On Tue, May 15, 2018 at 3:49 PM, Jeroen Demeyer  > wrote: 
> > On 2018-05-15 15:40, Emmanuel Charpentier wrote: 
> >> 
> >> Therefore, I think that contributing to Sage should not *require* a 
> >> sophisticated understanding of the finer points of git care and 
> feeding... 
> > 
> > 
> > Of course not. I don't think that anybody here proposed that. 
>
> Nope, but as I wrote upthread this discussion is still orthogonal to 
> what I wanted to propose... 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Erik Bray]

On Tue, May 15, 2018 at 3:11 PM, Jeroen Demeyer  wrote:
> On 2018-05-15 14:35, Erik Bray wrote:
>>
>> I'm not convinced that's a real problem.  This is what I meant by "yes
>> its contents may change and shift rapidly, but for a sophisticated
>> developer who just wants to peek in on the release process this is not
>> a problem".
>
>
> I agree that it's not a problem for the "sophisticated developer" who knows
> what he is doing. But the more you advertise this secret branch, the larger
> chance there is of abuse by non-sophisticated developers who have no clue. I
> believe that this is the point that Maarten was trying to make.

I don't see much chance for "abuse".  Mostly all I'm talking about
here is to do integration in a branch that's easy to identify and is
documented (it can even be documented as "this branch is unstable so
don't look at it unless you know what you're doing".  The worse
someone can bite themselves is by maybe rebasing a branch on top of
that branch, and then proposing that version of the branch for merging
which might not always be for the best (though it might often be fine
too).  To make this mistake would require knowing how to use rebase in
the first place...

On Tue, May 15, 2018 at 3:49 PM, Jeroen Demeyer  wrote:
> On 2018-05-15 15:40, Emmanuel Charpentier wrote:
>>
>> Therefore, I think that contributing to Sage should not *require* a
>> sophisticated understanding of the finer points of git care and feeding...
>
>
> Of course not. I don't think that anybody here proposed that.

Nope, but as I wrote upthread this discussion is still orthogonal to
what I wanted to propose...

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Jeroen Demeyer]

On 2018-05-15 15:40, Emmanuel Charpentier wrote:

Therefore, I think that contributing to Sage should not *require* a
sophisticated understanding of the finer points of git care and feeding...


Of course not. I don't think that anybody here proposed that.

--
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Emmanuel Charpentier]

May I argue that we should aim at being able to use *UN*sophisticated 
developers (such as, well... myself) ?

There is a *lot* of "maintenance" tasks  in Sage that can use (relatively) 
ignorant people. For example, maintaining Sage ports of well-understood 
packages (such as Maxima or, in my case, R) does not need extreme level of 
sophistication ; delegating these tasks to people able to follow some 
guidelines, read and interpret error messages and propose reasonably clean 
patches allow people who *are* sophisticated to use their time at more 
difficult tasks...

Therefore, I think that contributing to Sage should not *require* a 
sophisticated understanding of the finer points of git care and feeding...

--
Emmanuelk Charpentier

Le mardi 15 mai 2018 15:11:09 UTC+2, Jeroen Demeyer a écrit :
>
> On 2018-05-15 14:35, Erik Bray wrote: 
> > I'm not convinced that's a real problem.  This is what I meant by "yes 
> > its contents may change and shift rapidly, but for a sophisticated 
> > developer who just wants to peek in on the release process this is not 
> > a problem". 
>
> I agree that it's not a problem for the "sophisticated developer" who 
> knows what he is doing. But the more you advertise this secret branch, 
> the larger chance there is of abuse by non-sophisticated developers who 
> have no clue. I believe that this is the point that Maarten was trying 
> to make. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Jeroen Demeyer]

On 2018-05-15 14:35, Erik Bray wrote:

I'm not convinced that's a real problem.  This is what I meant by "yes
its contents may change and shift rapidly, but for a sophisticated
developer who just wants to peek in on the release process this is not
a problem".


I agree that it's not a problem for the "sophisticated developer" who 
knows what he is doing. But the more you advertise this secret branch, 
the larger chance there is of abuse by non-sophisticated developers who 
have no clue. I believe that this is the point that Maarten was trying 
to make.


--
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Erik Bray]

On Sat, May 12, 2018 at 10:31 AM, Marc Mezzarobba  wrote:
> Jeroen Demeyer wrote:
>> To be honest, I think it's not very meaningful to do that without
>> consulting the release manager. I mean, you can write up all the
>> documentation that you want; in the end, it's the release manager who
>> decides what happens.
>
> Even without switching to the model Erik is advocating, it could perhaps
> be useful to have additional integration branches where the *reviewer*
> would be supposed to merge a branch when setting the corresponding
> ticket to positive review. The release manager would remain free to use
> these branches or not when preparing the actual release.

I mean, one thing that drives me up the wall is being told with some
regularity that a ticket of mine has a "merge conflict" without any
indication of what it actually *conflicts* with, even though the
ticket merges fine with the "develop" branch.  This is because Volker
has a "private" integration branch that he's merging things into.
(I've in the past glibly called this "secret", and while no it's not
*actually* secret it's not exactly easy to find--I don't understand
why it isn't just a standard branch like "master", or at least
something with an identifiable name that is fetched by default).
While Volker could at least tell us what the conflicting files are we
are otherwise left to guess since we don't even know what's been
merged into that branch.  I think it would be better if this branch
were easily found and were documented--yes its contents may change and
shift rapidly, but for a sophisticated developer who just wants to
peek in on the release process this is not a problem.

All that said, I see no reason not to make release-specific branches.
On most projects I would make such a branch simultaneously with
tagging a beta release of a new X.Y version.  Sage's development
process uses "beta" a little differently that I would normally, and
that's fine--that's just a bikeshed.  But with Sage's version
nomenclature it would at least make sense to create a release-specific
branch concurrently with the first *release candidate*.  With such a
branch available, development can still continue apace while critical
bugfixes can be backported the release branch.  This is a completely
normal thing to do and is plenty advantageous.  I don't see the harm
in asking people who are interested in Sage development to get used to
the idea that there can be multiple lines of development
simultaneously (in this case just two...)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Volker Braun]

Just to suggest something that is not burdened with combinatorial 
explosion, how about listing the conflicting tickets. Which is just O(N^2)


On Saturday, May 12, 2018 at 5:10:52 PM UTC+2, Maarten Derickx wrote:
>
>
>
> On Saturday, 12 May 2018 14:10:27 UTC+2, Jeroen Demeyer wrote:
>>
>> On 2018-05-12 10:31, Marc Mezzarobba wrote: 
>> > it could perhaps 
>> > be useful to have additional integration branches where the *reviewer* 
>> > would be supposed to merge a branch when setting the corresponding 
>> > ticket to positive review. 
>>
>> I don't see how this would be useful. If it's not automated, it's 
>> regularly  going to be forgotten or wrong. Even if it would be automated 
>> (and therefore correct), I still don't see the use case. 
>>
>> It might be useful for the patchbot though: I can see some merit in the 
>> patchbot testing a ticket against all other positively-reviewed tickets. 
>> But that could be done even without having a dedicated branch on Trac: 
>> the patchbot could easily handle this internally. 
>>
>>
>>
> +1 to having a patchbot running the merge of running all positively reviewed 
> tickets.
>
> p.s. because of the possibility of both merge conflicts, and other types 
> of interference it should not literally be all positively reviewed 
> tickets, but against an inductively defined subset of all positively 
> reviewed tickets that all merge and together pass all doctests.
>
> If something like this is introduced we should also provide some 
> guidelines on when and how to rebase in case of conflicts.
>  
>
>> Jeroen. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-release] Re: Release process

[Maarten Derickx]

On Saturday, 12 May 2018 14:10:27 UTC+2, Jeroen Demeyer wrote:
>
> On 2018-05-12 10:31, Marc Mezzarobba wrote: 
> > it could perhaps 
> > be useful to have additional integration branches where the *reviewer* 
> > would be supposed to merge a branch when setting the corresponding 
> > ticket to positive review. 
>
> I don't see how this would be useful. If it's not automated, it's 
> regularly  going to be forgotten or wrong. Even if it would be automated 
> (and therefore correct), I still don't see the use case. 
>
> It might be useful for the patchbot though: I can see some merit in the 
> patchbot testing a ticket against all other positively-reviewed tickets. 
> But that could be done even without having a dedicated branch on Trac: 
> the patchbot could easily handle this internally. 
>
>
>
+1 to having a patchbot running the merge of running all positively reviewed 
tickets.

p.s. because of the possibility of both merge conflicts, and other types of 
interference 
it should not literally be all positively reviewed tickets, but against an 
inductively defined subset of all positively reviewed tickets that all 
merge and together pass all doctests.

If something like this is introduced we should also provide some guidelines 
on when and how to rebase in case of conflicts.
 

> Jeroen. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.