Page MenuHomePhabricator

Change how ReleaseTaggerBot handles major MW releases
Closed, ResolvedPublic



What tasks belong in #MW-X.YY-release projects:

  • Before X.YY is released: Issues deemed blockers of the release (added by a human)
  • After X.YY is released: Issues that are present in X.YY and are important enough to include in a point release (if it gets fixed). (added by a human)

How ReleaseTaggerBot should continue to provide useful information based on patches committed to master during a release's development:

  • ReleaseTaggerBot should tag #MW-X.YY-release-notes on any task that had an associated patch merged into master during a release's development.
  • At release time, all tasks marked as "Resolved" in #MW-X.YY-release-notes should be automatically listed as "Tasks closed in 1.27" in the Release Notes.
  • All tasks still open are reviewed by a human:
    1. Is it a blocker of the release (as deemed by the release team, mostly Chad H, with me helping where I can)? Then go get someone to fix it now, change mind and make it not a blocker, etc etc
    2. Was some meaningful progress made worthy of a mention in the release notes? If yes, do something, if not, then it's great that the default was not to include this task.
    3. Remove from #MW-X.YY-release-notes is it shouldn't be included in the "Tasks closed in 1.27" part of the Release Notes.
    4. etc... Humans are great at this part.


From discussion in #-releng:

16:50 < robla> why did ForrestBot tag T92796 as "MW-1.26-release" on August 22?
16:51 < legoktm> merged core patches get the tag of the next stable release
16:53 <+ greg-g> ForrestBot's idea is to see all tasks which were fixed in a given release, both for wmfXX branches and the big'uns.
16:53 <+ greg-g> I'm unsure of the helpfulness of the later
16:54 <+ greg-g> s/ForrestBot/ReleaseTaggerBot/ # 'twas renamed
16:55 < valhallas> oh, but 'WM-1.26-release' is also interpreted as 'should be fixed before the release', which is something different than 'a patch for this is in <branch>' :/
16:55 < legoktm> so far I've found it really useful for quickly identifying if a bug fix was backported to 1.25
16:55 <+ greg-g> valhallasw`cloud: right
16:55 < legoktm> I think it will prove to be useful when we start writing up [[MediaWiki 1.26]] and other release notes
16:56 <+ greg-g> legoktm: but what about edge cases like the one robla linked where the patch doesn't actually resolve the issue?
16:56 <+ greg-g> is that "noise" manageable?
16:56 < legoktm> someone should manually remove the tag whenever they re-opened the bug
16:57 <+ greg-g> no one knows about the project
16:57 < robla> legoktm: "someone should manually..." seems like a dangerous way to start a sentence :-)
16:57 <+ greg-g> (It's not just a "tag" in the parlance of, it's a "release")
16:57 < valhallas> greg-g: I think the answer is 'we don't know'. This is the first release that will have bugs tagged as MW-1.26-release
16:58 <+ greg-g> valhallasw`cloud: fair
16:58 < valhallas> and not even all of them yet
16:58 <+ greg-g> but I think maybe some confusion is caused by the thought that it is just a tag, not a release project
16:58 < valhallas> no, most of them should be in there, I think, because 1.25 was released at the hackathon
16:58 <+ greg-g> the mw-1.2X-release projects are... release projects, not just informational tags
16:58 < legoktm> we're just missing stuff that was merged between REL1_25 branch point and hackathon
16:59 <+ greg-g> so, what releasetaggerbot is doing shoudl really be tagged as "fixed-in-1.26" or similar
17:00 <+ greg-g> again, I thinmk that's the mental model discrepency: MW-1.26-release is meant to track blockers, whereas RTB is just tagging for inforamtional purposes what could be found by a query after the fact :)
17:00 < valhallas> *nod*
17:00 greg-g is thinking in his metadata/ontology brain right now, it's a scary place
17:02 legoktm wonders why phabricator doesn't add opengraph <meta> tags
17:03 <+ greg-g> legoktm: shush! quit trying to nerd-snipe me!
17:03 < legoktm> :P
17:05 < legoktm> ohhh, I haven't read wikitech-l yet
17:05 < robla> legoktm: :-) yeah, that's what prompted me to say something here
17:07 <+ greg-g> legoktm: heh :)
17:09 < robla> For 1.27, it might make sense to have nee Forrestbot use a new tag (e.g. "1.27-check-this") and then have a single blocking "MW-1.26-release" task which is "clear out the '1.27-check-this' queue"
17:09 < robla> er....MW-1.27-release, that is
17:09 <+ greg-g> not bad

Event Timeline

greg created this task.Sep 24 2015, 5:16 PM
greg raised the priority of this task from to Needs Triage.
greg updated the task description. (Show Details)
greg added a project: ReleaseTaggerBot.
greg added subscribers: greg, RobLa, Legoktm, valhallasw.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 24 2015, 5:16 PM
greg set Security to None.
RobLa-WMF edited subscribers, added: RobLa-WMF; removed: RobLa.Sep 24 2015, 5:22 PM
greg added a subscriber: Tgr.Sep 24 2015, 9:58 PM

See discussion on wikitech-l, specifically my response to @Tgr here:

greg updated the task description. (Show Details)Sep 24 2015, 10:06 PM
greg updated the task description. (Show Details)Sep 24 2015, 10:53 PM

I strongly counsel against this change.

"Blockers for MW1.26" is an excellent project to create, with manual curation of what's actually important, but "Tasks fixed as part of MW1.26" is something we strongly need as well. The RELEASE-NOTES process has been laborious, and yet insufficient to secure every big change.

Right now we have, through RTB, the latter provision, albeit imperfect, and I think throwing it away rather than creating a distinct (and temporary) project would be a pity.

greg added a comment.Sep 25 2015, 5:44 PM

I don't think you're understanding my proposal then, because no where does this throw away the work that RTB does, it just moves it to #MW-X.YY-release-notes, which is, as you just said, the main benefit of RTB in this case.

greg added a comment.EditedSep 25 2015, 5:45 PM

(Also, the change wouldn't happen for 1.26, only for 1.27 onwards, just to be explicit)

greg added a comment.Sep 25 2015, 5:57 PM

The question really is: Who "owns" the MW-X.YY-release projects, the team managing the release of MW or a bot/the release notes? :) I go with the former and want the bot to do its work in #MW-X.YY-release-notes.

greg added a comment.Sep 25 2015, 6:13 PM

(sorry, I'm thinking in piece-meal today...)

Why have the bot move instead of the release team? Because people already treat the #MW-X.YY-release projects how I propose (adding tasks they want to be fixed before the release), it's only the bot that doesn't.

greg added a comment.Sep 29 2015, 9:11 PM

So, can we *please* make this change now? RTB is adding tasks to MW-1.27-release as of today.

There hasn't been an argument other than "it's different" yet.

The main benefit is not having to re-train other people (bots are easy to train) to not use MW-1.27-release how they have been and how I propose in the description it should be used (they're one and the same). eg:

(those are just from looking quickly at 1.25-release, I didn't look at them all, even)

Has a MW-1.27-release-notes project been created?

greg added a comment.Sep 29 2015, 9:44 PM

No, but I can make it in about 25 minutes.

I moved the #mw1.27 hashtag over to the new project, forrestbot should begin using it in the next run.

greg added a comment.Sep 29 2015, 10:27 PM

Yup, looks good. I'll do it right now. Spam in-coming!

greg closed this task as Resolved.Sep 29 2015, 10:30 PM