On Fri, Mar 7, 2014 at 12:21 PM, Brad Jorsch (Anomie) <bjor...@wikimedia.org
> wrote:
> On Fri, Mar 7, 2014 at 12:08 PM, C. Scott Ananian <canan...@wikimedia.org
> >wrote:
>
> > I agree. I think a better technical solution would be to halt jenkins'
> > auto-merge for the 24 hour period, so that +2'ed changes are not
> > automatically merged until after the branch is cut.
>
>
> I don't see how that's any better. Things still aren't getting merged.
>
> If anything, the "cut using master@{24 hours ago}" is a much better
> idea.[1] Although it might be useful to see if Wednesday tends to be a
> relatively active bug-fixing day as the community on non-Wikipedia sites
> finds issues in the version that was deployed to them on Tuesday, in which
> case keeping those from making it into the new cut on Thursday (and so
> requiring more backports or waiting an extra week for fixes) might not be
> so great.
>
That makes it harder to apply deployable bug fixes/merges. Now you need to
apply them against two different branches, so you've just moved the problem
24 hours back in time.
The benefit of halting auto-merge is that (a) it automatically resumes once
the deploy happens, so volunteers don't have to come back to gerrit to
repeat their approval, and (b) gerrit already has a convenient "publish and
submit" button that can be used to easily merge deployment-relevant patches
before the branch is cut.
--scott
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
