On Tue, May 15, 2018 at 2:16 PM, Maarten Derickx <m.derickx.stud...@gmail.com> wrote: > > > On Tuesday, 15 May 2018 12:35:52 UTC+2, Erik Bray wrote: >> >> On Sat, May 12, 2018 at 10:31 AM, Marc Mezzarobba <ma...@mezzarobba.net> >> 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. >> > > > I think the fact that this branch is "secret" is a feature instead of an > annoyance. It prevents us the eager developers from random rebasing branches > of one ticket onto the branch of another ticket. Which is a good thing if > you take into account with how Linus intends git to be used > https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html > (summary you should only rebase/merge with things that are in a "nice" > state). The reason for Volker not advertising his branch is that he wants to > have full freedom in changing the branch in whatever way he sees fit.
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". For my own purposes I would be doing things like "git fetch upstream; git checkout "integration"; git reset --hard upstream/integration" where "integration" is just a stand-in name I'm using for this hypothetical branch. Then I can easily do something like "git checkout tmp-merge; git merge my-branch" to see how my branch currently works with other branches being currently integrated, instead of just being told "merge conflict ¯\_(ツ)_/¯" with no means of investigating for myself :) > I think having the release manager determine what is stable enough to go > into the next beta is a sensible thing to do, and that we as developers > should only rebase onto the next beta is also sensible. I don't know if that's actually what's happening though. That determination is partly based on "does the ticket have positive review" and the rest is opaque. Anyways, my original purpose of this thread was just asking if I should bother proposing a process for creating release branches so that we don't have such a bottleneck when it comes to creating releases. I'm not sure I'm convinced by the suggestion that 8.2 was an aberration, because I feel like this has been a problem for every Sage release I've witnessed to some degree or other, and to a greater degree than I've ever seen elsewhere. > That being said, I do think that a better communication about why things are > done in the way they are could help a lot with migitating the annoyances. > I.e. instead of just a comment "merge conflict" on trac by Volker, there > would instead just post "merge conflict + pointer to sage developer manual" > where the pointer to the sage developer manual is a pointer to a to be > written part of the developer manual that explains what the "merge conflict" > means, and why it is best to just wait till the next beta. I wouldn't find that any more helpful. Best, E -- 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.
