Erik Bray wrote: > On Tue, Jun 28, 2016 at 7:14 PM, leif <not.rea...@online.de> wrote: >> Erik Bray wrote: >>> While we're tinkering with the workflow, I think we need to change the >>> workflow associated with testing changes. >>> >>> Currently the release manager *closes* a ticket and marks it as >> >> s/currently the release manager/the current release manager/ ;-) > > Yes, but I didn't want to imply "fault" here or anything like that. > Volker does what's best for Volker and that's completely fine. > > The problem is that there aren't any documented procedures (that I > know of!) for how testing of issues, merging, and releases should be > handled. So the correct procedure *is* whatever the current release > manager does. That, I do have a problem with, though it's nobody's > fault.
Regarding the release process, there are some (fairly outdated) notes in the Sage wiki, but a lot is simply defined by the actual release manager(s) (and more or less tradition). In the past, the release managers (usually teams) changed more often, also because nobody volunteered (or had the time to do it) for a longer period. >>> "fixed" when merging the change for testing. This really makes no >>> sense--if the tests fail the issue is not "fixed". After >>> "positive_review" can we add a "in testing" status or the like (from >>> which the next stages can be either back to "needs_work" or >>> "resolved". >> >> We had at least one lengthy discussion regarding that in the past (last >> time probably a year ago? -- too lazy to search the thread[s] now, but >> they're certainly worth reading [again]). >> >> Nothing happened since then though, if I'm not mistaken. >> >> But note that the buildbots do test tickets having positive review, some >> also those with "needs review", so with relatively frequent "beta >> releases", it's not all that bad. > > I'm really confused about what the buildbots do or don't do. Or what > the relationship is between patchbot and buildbot (other than the > latter implying that someone is managing a bunch of buildbot instances > somewhere?) My mistake, tickets are automatically tested by our *patchbots*. The buildbots don't do anything by themselves (unless the release manager runs some cron job, say). They are used to test potential (beta/rc/final) releases before releasing, and to build binary distributions of Sage. All of the above testing of course makes up only a fraction of the review process though (hopefully, I mean). People should really read the code, diffs, comments by other reviewers on a ticket, and experiment interactively, otherwise we could automate setting tickets to "positive review" (and merging them) as well... B) IMHO there have been (and will be) /some/ tickets with good reasons to revert them from positive review back to "needs work" or "needs review" (despite their patches applying and their tests -- if any -- passing), i.e., where merging them as is and opening follow-ups (which in fact rarely happens, often not because it wasn't necessary) instead didn't make sense, hence 'in_testing' or whatever seems useful. But the main problem usually is time, namely the time for others to take a look and to eventually intervene between someone setting a ticket to positive review and the ticket getting "finally" merged (into the release managers' trunk). 'in_testing' or 'merge_candidate' could attract (or alert) more people to look at, but the impact of a change (beyond what files get touched -- we don't even have a tool to notify people based on that) also matters. Everyone is allowed to (attempt to) modify any part of Sage, while we don't all live in the same timezone, and most of us don't work full-time on Sage. -leif -- 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.
