Re: [sage-release] Re: Release process

* 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. *

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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"

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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 >

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

Re: [sage-release] Re: Release process

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

[sage-release] Re: Release process

Well this time was a bit extreme since Apple screwed us over at the last minute, causing extra delays. I also just got back from vacation. If it would have been up to me I'd have made the release before leaving, but then people complained that this is too fast. What would be nice if there