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 <j.de...@ugent.be> >> 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 <j.de...@ugent.be> >> 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.
