Page MenuHomePhabricator

Decide how ReleaseTaggerBot fits into the brave new world of long-lived-branches
Closed, DeclinedPublic

Description

Breaking this task out from T139210: Abandon (or at least strongly simplify) project creation policy as it's really orthogonal to that discussion.

  • Currently we have a bunch of teams creating milestones which most people outside the team don't care much about.
  • Release-Tagger-Bot creates weekly release tags which are generally useful but they are ugly and numerous
    • related problem: these aren't actually milestones because the bot predates milestones

I can make them milestones, it just needs someone to decide what the parent project is. :-)

  • Does ReleaseTaggerBot only tag WMF deployments (a la WMF-deploy-2016-07-12_(1.28.0-wmf.10) or also supports other projects with their own milestone schemes?

It currently only supports the former, but other schemes could be written. There's already T100814: Have ReleaseTaggerBot also tag versioned libraries we control for libraries, for example; that task could be expanded for other areas.

  • If the latter: Would you like to create a task to make ReleaseTaggerBot create milestones (assuming the API allows)?

Currently the projects are manually created (by me), not by the bot; back then, we weren't sure we wanted to give it project admin rights as it was a simple test. A task to do this already exists: T100812: Have ReleaseTaggerBot automatically create new deploy branch (release) projects.

I manually archive them when they're no longer on the cluster; this could be automatic, yes.

You say "fix", I say "will break a critical workflow". :-(

Event Timeline

mmodell created this task.Jul 25 2016, 5:00 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 25 2016, 5:00 PM
greg added a subscriber: greg.Aug 1 2016, 6:28 PM
  • Currently we have a bunch of teams creating milestones which most people outside the team don't care much about.
  • Release-Tagger-Bot creates weekly release tags which are generally useful but they are ugly and numerous
    • related problem: these aren't actually milestones because the bot predates milestones
  • Does ReleaseTaggerBot only tag WMF deployments (a la WMF-deploy-2016-07-12_(1.28.0-wmf.10) or also supports other projects with their own milestone schemes?
  • If the latter: Would you like to create a task to make ReleaseTaggerBot create milestones (assuming the API allows)?

You say "fix", I say "will break a critical workflow". :-(

@Jdforrester-WMF can you elaborate what that workflow is and the underlying purpose/goal? (see also: the relevant workflow xkcd ;) ).

It answers the question "When is the patch that fixes my bug going to be deployed?"

The real answer is of course more nuanced because of multiple patches to fix one bug, the train being delayed, etc., but for the most part it gets it right I think.

It answers the question "When is the patch that fixes my bug going to be deployed?"

The real answer is of course more nuanced because of multiple patches to fix one bug, the train being delayed, etc., but for the most part it gets it right I think.

Indeed. And what I figured the other day when mulling this over with @thcipriani and @mmodell was that the bot can basically live as it is. The naming convention would just change, we could name the tags to be more date-based instead of version # based.

Yes, they'll be incorrect when the release slips, but that's already the case now (like when we skipped 1.28.0-wmf.9)

greg added a comment.Aug 1 2016, 10:46 PM

It answers the question "When is the patch that fixes my bug going to be deployed?"

I also know that James et al use this tag for the VE weekly triage to show "tasks resolved in the last X weeks/releases", cf https://phabricator.wikimedia.org/maniphest/query/Cmz_uJo94KJV/#R

demon closed this task as Declined.Mar 9 2017, 9:16 PM

Considering we declined T89945, I think this can get the same treatment.