On 2017-12-08 10:26, Erik Bray wrote:
a) Have a normal "bleeding edge" master branch into which all accepted
changes are immediately merged
Now everything boils down to defining "accepted changes".
Just having a ticket set to positive review does not mean that much. It
is a bad idea to merge them in your bleeding edge branch because those
tickets might not get merged in master (because it breaks something or
it conflicts with other ticket). So you need some mechanism anyway to
check tickets, which is the current situation.
When I was release manager, checking tickets was the most time-consuming
step in the release process. And a rather large fraction of tickets
(say, about 10%) didn't pass buildbot testing. Now that we have the
patchbot in reasonable shape, that is hopefully better now.
Once all tickets pass buildbot testing, actually making a release is easy.
It would be good to have some feedback from the current release manager
to identify what the bottleneck currently is.
More people who can merge into master
I actually like the idea of having a single release manager whose job it
is to do exactly this. With more people, things are no doubt going to
become sloppier. Also, it is harder to organize/synchronize the buildbot
workflow with many people.
helping to set priorities, and triaging.
This *could* be done by other people apart from the release manager, but
I don't think that there is a problem to be solved here.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
