Could someone take this up? It seems counter productive to work on workarounds when the we could deploy the real fix instead.

In T86772#1025124, @JanZerebecki wrote:

Could someone take this up? It seems counter productive to work on workarounds when the we could deploy the real fix instead.

Can you link to the upstream fix you mean?

@JanZerebecki is referring to T76732: Exact matches should always win when suggesting/auto-completing and https://secure.phabricator.com/T6102

@Christopher I saw you merging some updates. What revision of Phab are you up to for testing against?

https://gerrit.wikimedia.org/r/#/c/190112/

Sprint is current with Phabricator
commit eee8d194eb48ede0e839a0a9f828d088be565e1a
Date: Fri Feb 6 15:32:55 2015 -0800

and libphutil
commit 2b23ac46a8473304b68afa16c353539e18e2e9f4
Date: Thu Feb 5 07:23:33 2015 +1100

Everything seems to be working. I just merged some javascript, including jQuery for table sorting, searching and paging. The demo site http://phab08.wmflabs.org has the latest for review. I still have a few minor fixes to implement, but overall I think that it is ready to deploy. The master tag is 0.7.2.0.

In T86772#1033068, @Christopher wrote:

Sprint is current with Phabricator
commit eee8d194eb48ede0e839a0a9f828d088be565e1a
Date: Fri Feb 6 15:32:55 2015 -0800

and libphutil
commit 2b23ac46a8473304b68afa16c353539e18e2e9f4
Date: Thu Feb 5 07:23:33 2015 +1100

Everything seems to be working. I just merged some javascript, including jQuery for table sorting, searching and paging. The demo site http://phab08.wmflabs.org has the latest for review. I still have a few minor fixes to implement, but overall I think that it is ready to deploy. The master tag is 0.7.2.0.

Ok man, thanks for the reply. I can test the other local changes against that revision then.

If you could wrap that up by like next monday? Maybe we could shoot for a wed upgrade. Otherwise we are pushing out to the 25th.

I heard from @Aklapper that the updates for the sprint extension/burndown charts should be going out in this next update, though I'm having a hard time confirming that from this bug. @Qgil, @chasemp, @Christopher can one of you please confirm?

In T86772#1037559, @Awjrichards wrote:

I heard from @Aklapper that the updates for the sprint extension/burndown charts should be going out in this next update, though I'm having a hard time confirming that from this bug. @Qgil, @chasemp, @Christopher can one of you please confirm?

It's more complicated than you hoped :)

@Christopher is chugging away on the sprint app and usually he is referencing some particular point in time (some commit) in upstreams history. We have a few other local changes and additions that then need to be tested against that version of upstream as well in tandem. Assuming the 0.7.2.0. tag is stable for sprint, and we can test the security and oauth extensions against the same eee8d194eb48ede0e839a0a9f828d088be565e1a mentioned above, and everything is ok. Then assuming there is nothing else that takes up the wednesday reserved outage spot for phab like the search debacle did this week.

Then we can assume we would upgrade :)

There are a lot of moving parts and not a lot of resources to reign them in. I am on an official 1 day a week phab time now, and spend well more than that. I think @mmodell is buried in a lot of releng work atm. But next week or the week after is pretty realistic I think.

@chasemp I have tagged the production branch of Sprint with the release tag 'release/2015-02-18'. This is the "ready to go" version for the upgrade. If there is anything I can help with, please let me know.

One other thing that people should know is that the switch from the special character to "Is Sprint" means that existing Sprint projects will have to be reinitialized. The existing tasks and task points in these projects will not be affected.

We should communicate this important detail to all the sprints involved. An
unorthodox but perhaps efficient way of doing this would be to create a
task with the explanation and associate the related sprints to it...

Upgrade Notification task T89646 created.

One of the things we have noticed is that the phab/sprint url no longer works, it is now phab/project/sprint. I'm not a big fan of the asymmetry there with every other application in phabricator and at the very least the url should redirect. I'm not sure if this is a big enough gotcha to delay upgrade, but combined with the tenuous acknowledgement of process associated with T89646 I'm not sure if users are prepared for the changes here.

@Christopher @chasemp what is the expected impact of these changes - eg how many teams/projects are going to be impacted? I'd really like to see the new sprint extension deployed ASAP but if it's going to result in breakage for a lot of folks, perhaps deployment should wait until there's more time for communication (or backwards compatibility?)

In T86772#1045132, @Awjrichards wrote:

@Christopher @chasemp what is the expected impact of these changes - eg how many teams/projects are going to be impacted? I'd really like to see the new sprint extension deployed ASAP but if it's going to result in breakage for a lot of folks, perhaps deployment should wait until there's more time for communication (or backwards compatibility?)

I'm going to say the url thing is survivable but IMO should be fixed. The sprint initialization thing I'm not sure exactly how that plays out but as far as impact every sprint project is affected. If someone wants to take point on following up with these teams and making sure this gets shaken out I think we could power through? It seems like all would be correctable, just confusing.

The re-initialization of all of the Sprint projects is like 5 minutes of work in total. See attached screenshot for reference of the dates. I will do it, if people are put off by the change.

As far as the URL change, this is justifiable. Because Sprint is a subpackage of the Projects application, the hierarchy should be referenced canonically. In this regard, the Sprint extension is unique from other Phabricator applications, so I think that the asymmetry is technically warranted. But, perhaps I am thinking too much like a Java programmer ...

I do not see any value in retaining the old /sprint url. If people have hard-coded links to stuff in a Sprint, changing them to match the new URL seems a lot more simple than implementing a confusing "backwards compatible" redirect. I would also recommend using the /tag/$project_name route for all external project linking references. Unfortunately, Phabricator still has parameterized URLs for specific resources, and it is probably good practice to avoid hard coding ids in external hrefs. Beyond this, if the redirect is required, it should be implemented in Apache rather than duplicate routes in the application controller.

In T86772#1045132, @Awjrichards wrote:

if it's going to result in breakage for a lot of folks, perhaps deployment should wait until there's more time for communication (or backwards compatibility?)

Well, T89646 has been around and added to the appropriate sprints (though might not be enough?).

To me the reasons exposed by Christopher and Andre are enough. The Sprint users will be happy with the Sprint novelties and the rest of improvements coming with the Phabricator update.

If you guys are on board then I'm fine with going ahead.

In T86772#1045983, @Christopher wrote:

The re-initialization of all of the Sprint projects is like 5 minutes of work in total. See attached screenshot for reference of the dates. I will do it, if people are put off by the change.

As far as the URL change, this is justifiable. Because Sprint is a subpackage of the Projects application, the hierarchy should be referenced canonically. In this regard, the Sprint extension is unique from other Phabricator applications, so I think that the asymmetry is technically warranted. But, perhaps I am thinking too much like a Java programmer ...

I do not see any value in retaining the old /sprint url. If people have hard-coded links to stuff in a Sprint, changing them to match the new URL seems a lot more simple than implementing a confusing "backwards compatible" redirect. I would also recommend using the /tag/$project_name route for all external project linking references. Unfortunately, Phabricator still has parameterized URLs for specific resources, and it is probably good practice to avoid hard coding ids in external hrefs. Beyond this, if the redirect is required, it should be implemented in Apache rather than duplicate routes in the application controller.

Hey man, thanks for responding. A few thoughts on this and what would be good from my perspective.

I'm making no judgement on the re-initialization of sprint stuff really, I'm sure it's a necessary thing, my issue is that I barely know what that means, and I have no idea what that means if it's done wrong. That is enough for me to call this kind of major change off in any other context. So I totally get you saying "it's only a few minutes" and you are certainly right, but from where I'm standing it's a change I have to deploy that no one I can get ahold of seems to fully understand. Especially in terms of consequences for not doing it right.

Regarding the URL, I'm prettty meh on it. I think I understand your reasoning, and I can live with it if other can. I'm not a primary consumer of the sprint app atm anyways, so live and let live. However, yesterday we deployed the latest everything to phab-01 and neither @mmodell nor I knew this would happen. I'm going to assume there is fault if something doesn't match up with my expectations based on the current production and there are no deployment notes telling me hey the entire url has changed and it will time out if you try to access it. That's a substantial problem in terms of integration testing. I'm not trying to be a jerk about it here, I know you are on kind of a solo mission and have been hacking away at a large tree here. I fully appreciate that seriously, but something like this is a bug unless it's documented to expect it. I honestly thought the entire app was broken at first until we investigated phab08 and kind of worked backwards. That's not an ideal process.

Please if you could overcommunicate large changes, especially breaking changes. I don't know the evolution of all of this and who will take this part over, but for the moment it's a skeleton crew and I have no choice to but to hold off if I'm unsure of something with the limited window I have for testing.

I would really like it if you could document some at https://www.mediawiki.org/wiki/Phabricator/Sprint with very light release notes or something that tells me what not to worry about when it seems possibly bad news. A match up of sprint tag version to phabricator commit id's would be great in case of rollback.

Update has happened.

The following projects need to set their sprint dates again by editing their project:

• § Fundraising Sprint Devo
• § Fundraising Sprint the Cure
• § Fundraising Sprint Beastie Boys
• § Fundraising Sprint Abba
• Collaboration-Team-Sprint-Q-2015-02-25
• Collaboration-Team-Sprint-P-2015-02-11/q3
• Collaboration-Team-Sprint-M-2014-12-17
• §Analytics-Sprint-2014-12-11
• #§_Fundraising_Sprint_E
• #§_Fundraising_Tech_Backlog
• Fundraising Dash (obsolete)

In addition, #§Collaboration-Team needs to also enable the "Is sprint" checkbox as I do not have permissions to edit that project.

Also copying that comment to T89646 and sending an email to teampractices@.

Planning the next upgrade is done in T89830 (feel free to CC yourself).

There seem to be some significant changes that occurred with this update - many of which I'm really really happy to see go out!

However, I haven't seen many of the significant changes communicated beyond this thread (eg PROJECT MENTIONS NO LONGER ASSOCIATE THEM TO TASK, changes to the URL scheme for burndowns, etc) or the email to the teampractices mailing list about some of the breakage to sprints using the sprint extension (after the update happened), and as far as I can tell from where I am sitting, there was no prior consultation with teams using the sprint extension on their projects about the potential implication of the changes being rolled out. I realize that some of the changes to the sprint extension seemed innocuous, but they have real impact on the day-to-day operations of the teams using it. I am seeing chatter in the teampractices IRC channel indicating confusion around the updates - this is not good.

Two asks:

1. Can someone commit to rolling up a list of significant changes from this update and send it out to a public mailing list like wikitech?
2. Can someone point me to any documentation regarding policy around communicating breaking changes *prior* to updates to concerned parties? If there is no documentation nor some policy around this, is this something you guys can come up with?

@Awjrichards: Yeah, I agree. Sorry for that. From the top of my head:

• Tasks crossed out in the "Blocks" section of this task have been fixed
• UI changes: New project related bar on the left; project view by default goes to workboard instead of project overview page
• Mentioning #projects in comments or descs does not add them to the task anymore
• not sure about the changes in the Sprint extension, that's something @Christopher knows best:
  • URLs like /sprint/board/1015/ are now /project/sprint/board/1015/
  • ...

In T86772#1045983, @Christopher wrote:

The re-initialization of all of the Sprint projects is like 5 minutes of work in total. See attached screenshot for reference of the dates.

@Christopher: Ahem, I am very sorry as I had missed that comment and had not seen it when I wrote "The following projects need to set their sprint dates again by editing their project" above. Meh. :(

Thanks for all your work on the Sprint extension!

1. Can someone commit to rolling up a list of significant changes from this update and send it out to a public mailing list like wikitech?

For the records: https://lists.wikimedia.org/pipermail/teampractices/2015-February/000621.html