On Sunday, April 19, 2015 at 12:32:20 PM UTC-4, leif wrote: > > On 04/19/2015 05:41 PM, Nathann Cohen wrote: > >> I often have a look at positively reviewed tickets and sometimes ask > >> questions about the review. Positive review just mean that one person > agreed > >> that the changes were good to be integrated. But it might still > interest > >> other to have a look (or even the reviewer might think of something in > the > >> morning after setting the day before 'positive review'). So I would > prefer a > >> stand by period between the 'positive review' and the 'closed' (= > currently > >> testing if it merges cleanly). One week looks reasonable to me. And it > >> should not be hard to script. > > > It is true that several persons requested that tickets should stay in > > positive review for a while before being merged. On the other hand, if > > merging them becomes fully automatic, then changing something is > > really immediate and perhaps we will end up creating more tickets. > > Yep, with all consequences. > > It would IMHO be much more sensible to use the "Merged in" field (which > Volker likes very much, I know), indicating that the branch has > currently been merged into the next, not yet released, version. (No > need to change that field later, upon closing the ticket, if everything > went well.) > > That way, anybody would (or should) know that he/she must not change the > ticket's branch, but it would also easily be possible to revert the > ticket's state into "needs work", in case other reviewers (or the > original one(s)) happen to find further issues directly related to the > ticket's changes (as opposed to desirable changes for a follow-up). >
Yes, this seems reasonable. Keeping a proliferation of tickets is good, having a way for the release manager to let everyone know that the ticket is being "tested" is also good, making the release manager's job not annoying is good. By the way, I would be very against completely automated merging. The release manager (as a human) is a last line of defense against scurrilous tickets/branches/changes to Sage. Otherwise it's too easy for a write/review team of two to put in a whole bunch of stuff that maybe isn't following convention (minor) or actively making Sage bad (major). I'm not defining those things, but just pointing out that having a "real person" who has been working with the project quite a while verifying that the changes could be relevant and useful is a good thing; otherwise we don't have a "commit group" like some projects, but essentially any pair of people becomes a committer. In practice that isn't a huge problem, but it's still worth having that role, very much so - and not just for testing for doctest errors, which could themselves be in error ;) -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
