On Fri, Dec 8, 2017 at 1:59 PM, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: > 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".
Of course--this isn't trivial, but there's going to be some degree of subjectivity involved no matter what. Right now (it seems?) just about anyone can give a ticket "positive review". What you really want is to have some set of "core maintainers", possibly with different responsibilities for different areas of the code depending on their expertise. And a sign-off from one of them (plus positive results of continuous integration and other checklist items) means the change should be merged. Right now there is really just one "core maintainer" in the sense I described above, and that's the "release manager", who in Sage is currently wearing a lot more hats than merely release management. And a single release manager can't be a subject-matter expert on all topics either, nor have a 100% top-down view of what to prioritize--certainly not without input. This is really a massive bottleneck to development iMO. > 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. I'm not sure what you mean here. I'm saying "master" is the bleeding-edge. On most projects accepted changes are merged directly into master--they've been checked to work against the current HEAD of the master branch. This *can* move quickly, which means some proposed changes can become outdated quickly, but only in cases where there is a conflict. This does not happen with every change. It also happens less often if changes are being approved and merged more quickly, which does not happen with Sage because again there is a single bottleneck. > 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. It can be time-consuming, yes. However, having other trusted people who know what they're doing help with that task alleviates quite a bit of burden; something I know from experience. Knowing that Trusted Person A who is a subject matter expert on the topic of the change has signed off on a pull request, for example, increases my confidence enough that I will scrutinize the change less myself. For the pedants, a number of checks can be scripted as well (even checked by bots--see CPython's excellent fleet of bots that have been deployed on their GitHub project). > 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. See above. I think this attitude that one and only one person can know what they're doing with respect to accepting changes is pretty presumptuous. I don't understand the point about the "buildbot workflow" but it sounds like that might be a problem with that workflow. >> 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. Yes and no. Right now it doesn't seem to get done very much. The "milestone" field on Trac seems all but useless. If I put a ticket in the "sage-8.1" milestone it means I think that ticket would be well suited to go into that release. That doesn't mean the release must be held up for every ticket assigned to the milestone--oftentimes an issue will be assigned to a milestone, but won't be possible to resolve for that release due to time constraints of the interested parties, unresolved questions, etc. In this case it can be deferred, either to a future release milestone, or a more "pie-in-the-sky" category. But this should be done explicitly during a pre-release triaging period in which others can participate, to decide what we really think will or will not go in a given release. Right now the way it (seems to) work is new tickets get assigned to the next release milestone. That release is then made...whenever...regardless of what tickets are still open or not, and then all those tickets (typically) remain in old milestones for completed releases. This is nobody's fault; it just doesn't seem to be part of the practice or culture of the project to really use milestones in a consistent manner. -- 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.
