We are about to enter the final sprint to migrate Bugzilla and RT to https://phabricator.wikimedia.org. The move from Trello and Mingle is about to start as well. And well, it is time to plan the migration from Gerrit. The first goal is to build a proof of concept based on a sample of repositories imported and created.
Feedback and contributors are welcome! Some links, from generic to specific:
Code Review project https://phabricator.wikimedia.org/tag/code-review/board/ (check especially the Need Discussion column)
Plan to migrate code review from Gerrit to Phabricator https://phabricator.wikimedia.org/T18
Define main tasks (epics) for code review in Phabricator https://phabricator.wikimedia.org/T584
Proof of concept of code review in Phabricator https://phabricator.wikimedia.org/T560
Quim Gil wrote:
We are about to enter the final sprint to migrate Bugzilla and RT to https://phabricator.wikimedia.org. The move from Trello and Mingle is about to start as well. And well, it is time to plan the migration from Gerrit.
I'm confused by this e-mail. I don't understand why you're seemingly switching to a focus on code review when everyone had decided to indefinitely put that off. The last time this was discussed, there were real concerns that Phabricator couldn't handle code review in the same way that Gerrit does and so Gerrit would continue to be used. What has changed?
I also don't understand the focus on code review when the Bugzilla migration is still not done. You mention a final sprint, but I'm unclear what this means. You previously wrote:
NEXT STEPS
We will set up a separate Phabricator instance containing a sample of Bugzilla reports imported automatically, for your delight and criticism. After this instance is announced, we will leave at least one week for community feedback before deciding the next steps.
https://www.mediawiki.org/wiki/Phabricator#Migration_timeline
As I understand it, this has not happened yet. Looking at the wiki page, it seems this is tentatively scheduled for the week of October 31.
I'm concerned about whether bug reporters/filers and people who have CC'd themselves on a Bugzilla bug will seamlessly receive future notifications from Phabricator. It's very important that the CC field is migrated to Phabricator subscribers or equivalent, for example.
I also don't think one to four days of Bugzilla downtime is acceptable given that Bugzilla is a central development tool. I think maybe one day would be okay, but it would ideally be on a Saturday or Sunday then.
And, even though it should go without saying, Bugzilla will need to remain online in a read-only format indefinitely post-migration.
Your most recent e-mail seems to jump past all of this and focus on Gerrit/code review, which is mentioned as a goal for March 2015 at https://www.mediawiki.org/wiki/Phabricator#Migration_timeline, so I'm confused about what the priorities are here and whether there's general consensus for the work you intend to do.
MZMcBride
On Sun, Oct 19, 2014 at 10:44 AM, MZMcBride z@mzmcbride.com wrote:
And, even though it should go without saying, Bugzilla will need to remain online in a read-only format indefinitely post-migration.
Why would this be necessary, assming everything is properly imported to Phab?
Will *every* detail of a BZ ticket be moved? Comments, attachments, history, etc? If so, I wouldn't see a need to keep it laying around. Is there one?
On Oct 19, 2014 11:52 AM, "Rjd0060" rjd0060.wiki@gmail.com wrote:
On Sun, Oct 19, 2014 at 10:44 AM, MZMcBride z@mzmcbride.com wrote:
And, even though it should go without saying, Bugzilla will need to
remain
online in a read-only format indefinitely post-migration.
Why would this be necessary, assming everything is properly imported to Phab?
Will *every* detail of a BZ ticket be moved? Comments, attachments, history, etc? If so, I wouldn't see a need to keep it laying around. Is there one?
--
Ryan User:Rjd0060 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Well there are a lot of links to it first of all. And there is always the possibility that something will be missed in the migration. Personally i wouldnt call having a read only bugzilla stay up a hard requirement, but its something i would certainly want.
I still refer to Special:code sometimes (most recently a couple days ago) even though we are long dince migrated.
--bawolff
On Sun, Oct 19, 2014 at 5:44 PM, Brian Wolff bawolff@gmail.com wrote:
Well there are a lot of links to it first of all.
For which a redirect is a much better solution than sending the reader to a dead site and leaving them to figure out it's dead. At least for direct bug references it should be easy to set up a rewrite rule forwarding them to a Phabricator search on the bugzilla ticket number.
The main reason for keeping Bugzilla up as long as possible would be, IMO, the personal details which won't be migrated but help people keep track of their bugs of interest, often across many years - votes, saved searches, personal whiteboards and such.
On Sun, 2014-10-19 at 10:52 -0400, Rjd0060 wrote:
On Sun, Oct 19, 2014 at 10:44 AM, MZMcBride z@mzmcbride.com wrote:
And, even though it should go without saying, Bugzilla will need to remain online in a read-only format indefinitely post-migration.
Why would this be necessary, assming everything is properly imported to Phab?
Will *every* detail of a BZ ticket be moved? Comments, attachments, history, etc? If so, I wouldn't see a need to keep it laying around. Is there one?
We plan to keep Bugzilla read-only for some time (not sure about "indefinitely" though) - https://phabricator.wikimedia.org/T366
Most details will be moved. You can find the exact details under "Bugzilla data migrated" on https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla
andre
Rjd0060 wrote:
On Sun, Oct 19, 2014 at 10:44 AM, MZMcBride z@mzmcbride.com wrote:
And, even though it should go without saying, Bugzilla will need to remain online in a read-only format indefinitely post-migration.
Why would this be necessary, assming everything is properly imported to Phab?
Will *every* detail of a BZ ticket be moved? Comments, attachments, history, etc? If so, I wouldn't see a need to keep it laying around. Is there one?
I thought of quips and saved searches off-hand. There are almost certainly other pieces of Bugzilla that may not be migrated, but still may be of interest to users. We've had Bugzilla since 2004, it's a decade old, so leaving it up for a while in a read-only state shouldn't be an issue.
https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla looks promising.
Andre Klapper wrote:
In order to tackle the bigger issues with code review migration they need to receive sufficient attention and discussion about the best way forward. High level examples: Do we have sufficient expertise in Wikimedia? Who has this expertise? Do these persons have the time and interest to work on these issues? What has higher priority compared to other tasks these persons already have on their lists for the next months?
[...]
Hope that answers some of your concerns.
Quim Gil wrote:
As the description of https://phabricator.wikimedia.org/T18 says, The Code Review migration to Phabricator is quite orthogonal to the RT and Bugzilla migrations, and we should start planning for it now. We need to request resources for the current quarter now, and in order to do this properly we need to have an initial plan that gives us an idea of the skills/roles needed and for how long.
[...]
When we discussed code review during the RfC there was indeed a lot of discussion about how to integrate Phabricator's code review process with the Wikimedia code review requirements. However, the only formal decision was to schedule tentatively a "Proof of concept of code review in Phabricator adapted to Wikimedia needs" for Oct-Dec 20014, and nothing has changed in that respect.
[...]
Although there is some overlap of people, most of the active contributors in the code review discussion are not particularly involved in the RT and Bugzilla migration work.
Thanks for the detailed replies. I'll take a look at some of these links.
Andre: Your questions are interesting, but I was mostly wondering whether Phabricator as a replacement for Gerrit had been decided. We've not yet reached the point of no return for Phabricator and code review is a pretty important process, of course.
Quim: you seem to be saying that the idea is to plan for and allocate resources toward demoing Phabricator as a replacement for Gerrit, as I now understand it. Thanks for the clarification.
MZMcBride
Hi,
On Sun, 2014-10-19 at 10:44 -0400, MZMcBride wrote:
Quim Gil wrote:
We are about to enter the final sprint to migrate Bugzilla and RT to https://phabricator.wikimedia.org. The move from Trello and Mingle is about to start as well. And well, it is time to plan the migration from Gerrit.
I'm confused by this e-mail. I don't understand why you're seemingly switching to a focus on code review when everyone had decided to indefinitely put that off. The last time this was discussed, there were real concerns that Phabricator couldn't handle code review in the same way that Gerrit does and so Gerrit would continue to be used. What has changed?
The stress is on "plan" so I wouldn't call it "switching focus". The main technical focus remains on finishing the migration from RT and Bugzilla to Phabricator but that's more executing and less planning as we are getting closer to that goal.
In order to tackle the bigger issues with code review migration they need to receive sufficient attention and discussion about the best way forward. High level examples: Do we have sufficient expertise in Wikimedia? Who has this expertise? Do these persons have the time and interest to work on these issues? What has higher priority compared to other tasks these persons already have on their lists for the next months?
I'm concerned about whether bug reporters/filers and people who have CC'd themselves on a Bugzilla bug will seamlessly receive future notifications from Phabricator. It's very important that the CC field is migrated to Phabricator subscribers or equivalent, for example.
https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Bugzilla_data_mig... states under "CC list" that it will be migrated.
I also don't think one to four days of Bugzilla downtime is acceptable given that Bugzilla is a central development tool. I think maybe one day would be okay, but it would ideally be on a Saturday or Sunday then.
We're talking about migrating 75000 Bugzilla tickets to Phabricator which will take a while. Some actions will require direct database actions hence some downtime is required. We know how disruptive it'll be to not have Bugzilla around hence the plan is to start the migration on a Friday.
And, even though it should go without saying, Bugzilla will need to remain online in a read-only format indefinitely post-migration.
We plan to keep Bugzilla read-only for some time (not sure about "indefinitely" though) - https://phabricator.wikimedia.org/T366
Hope that answers some of your concerns.
Cheers, andre
On Sun, Oct 19, 2014 at 4:44 PM, MZMcBride z@mzmcbride.com wrote:
I'm confused by this e-mail. I don't understand why you're seemingly switching to a focus on code review
Sorry for the confusion, sometimes it is tricky to find the balance between brevity and clarity.
As the description of https://phabricator.wikimedia.org/T18 says, The Code Review migration to Phabricator is quite orthogonal to the RT and Bugzilla migrations, and we should start planning for it now. We need to request resources for the current quarter now, and in order to do this properly we need to have an initial plan that gives us an idea of the skills/roles needed and for how long.
when everyone had decided to indefinitely put that off. The last time this was discussed, there were real concerns that Phabricator couldn't handle code review in the same way that Gerrit does and so Gerrit would continue to be used. What has changed?
When we discussed code review during the RfC there was indeed a lot of discussion about how to integrate Phabricator's code review process with the Wikimedia code review requirements. However, the only formal decision was to schedule tentatively a "Proof of concept of code review in Phabricator adapted to Wikimedia needs" for Oct-Dec 20014, and nothing has changed in that respect.
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals#Engineeri...
I also don't understand the focus on code review when the Bugzilla
migration is still not done.
Although there is some overlap of people, most of the active contributors in the code review discussion are not particularly involved in the RT and Bugzilla migration work.
You mention a final sprint, but I'm unclear what this means.
It means exactly this:
https://phabricator.wikimedia.org/tag/bugzilla-preview/
https://phabricator.wikimedia.org/tag/bugzilla-migration/
https://phabricator.wikimedia.org/tag/rt-migration/
Chase, Mukunda, Andre, and myself are working almost full time in these three subprojects. I'm taking some extra time to push the Code Review plan to identify with a higher level of detail what we need, and what Phabricator is not offering today.
You previously wrote:
NEXT STEPS
We will set up a separate Phabricator instance containing a sample of Bugzilla reports imported automatically, for your delight and criticism. After this instance is announced, we will leave at least one week for community feedback before deciding the next steps.
https://www.mediawiki.org/wiki/Phabricator#Migration_timeline
As I understand it, this has not happened yet. Looking at the wiki page, it seems this is tentatively scheduled for the week of October 31.
The announcement of the Bugzilla migration preview is imminent, see https://phabricator.wikimedia.org/T552
I also don't think one to four days of Bugzilla downtime is acceptable
Any ideas to reduce the time? :) We will go as fast as the Bugzilla and Phabricator APIs allow us to migrate all the content we want to migrate from A to B.
In fact...
On Mon, Oct 20, 2014 at 1:04 AM, Quim Gil qgil@wikimedia.org wrote:
As the description of https://phabricator.wikimedia.org/T18 says, The Code Review migration to Phabricator is quite orthogonal to the RT and Bugzilla migrations, and we should start planning for it now. We need to request resources for the current quarter now, and in order to do this properly we need to have an initial plan that gives us an idea of the skills/roles needed and for how long.
After some discussions today, we have concluded that we have not enough resources to have a complete assessment (including a proof of concept) and a full fledged project plan by the end of 2014.
The "stretch goal" proposed for the current quarter is a "Basic plan for Phabricator as code review tool". The exact content of this basic plan needs to be defined, but the main idea is to identify technical showstoppers and propose the next steps, keeping a stream of discussion and experimentation.
wikitech-l@lists.wikimedia.org