<quote name="Brad Jorsch (Anomie)" date="2015-09-24" time="10:58:03 -0400">

On Thu, Sep 24, 2015 at 10:36 AM, Andre Klapper aklapper@wikimedia.org wrote:

...

MediaWiki 1.26 will be released later this year. There are 62 open tasks in Phabricator tagged with "MW-1.26-release".

What does being tagged with "MW-1.26-release" actually mean? T92796 and T113189, for example, were tagged by a bot after patches were merged that didn't completely close the bugs.

Ostensibly: bugs that affect MW 1.26. In theory, it'd be good to get it to zero before we release.... in theory.

Greg

<quote name="Gergo Tisza" date="2015-09-24" time="13:43:14 -0700">

Using #MW-X.XX-release for tracking blockers is just not realistic; that project gets added to any task where there was any recent progress (and it's probably not present on tasks where nothing was merged recently, even if it's about a serious bug that should block the release) . There should be a separate, manually added project for blockers.

See: https://phabricator.wikimedia.org/T113628 "Change how ReleaseTaggerBot handles major MW releases"

My opinion is that the #MW-X.YY-release projects should only be for: * Before X.YY is released: Issues deemed blockers of the release * 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).

What ReleaseTaggerBot is doing by tagging all tasks that had an associated patch merged is not helpful without yet more manual intervention.

Robla's proposal[0] isn't a bad idea. I'd suggest a better name than "check-this"[1] but the concept is sound. The only tasks still open in #MW-1.27-check-this would be ones that had an associated patch merged but were either resolved then reopened or never resolved at all. These tasks shouldn't be listed as "fixed" in the 1.27 release notes and should be acted upon in some other reasonable way[2].

This simple fix (ie: not having ReleaseTaggerBot use #MW-X.YY-release for it's work) would simply the whole process and leave us with projects that mean one thing at any time.

Greg

[0] from IRC: < 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" < robla> er....MW-1.27-release, that is

[1] After typing most of this email, a good suggestion would be "#MW-1.27-release-notes". At release time, all tasks marked as "Resolved" should be automatically listed as "Tasks closed in 1.27" in the Release Notes. All tasks still open are reviewed by a human. See also [3].

[2] 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.

On Thu, Sep 24, 2015 at 8:55 AM Bartosz Dziewoński matma.rex@gmail.com wrote:

On 2015-09-24 16:58, Brad Jorsch (Anomie) wrote:

...

What does being tagged with "MW-1.26-release" actually mean? T92796 and T113189, for example, were tagged by a bot after patches were merged that didn't completely close the bugs.

When the bot does this, I think it's just wishful thinking (and assuming that the patches do close the task). If they didn't, the project should probably be removed from the tasks.

This. I'm seeing a number of non-blockers marked as blockers. Help is welcome cleaning those out.

-Chad