Phabricator for code review (defining the plan)

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Phabricator for code review (defining the plan)

Quim Gil-2
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
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Phabricator for code review (defining the plan)

MZMcBride-2
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



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Phabricator for code review (defining the plan)

Rjd0060 -
On Sun, Oct 19, 2014 at 10:44 AM, MZMcBride <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Phabricator for code review (defining the plan)

Brian Wolff
On Oct 19, 2014 11:52 AM, "Rjd0060" <[hidden email]> wrote:
>
> On Sun, Oct 19, 2014 at 10:44 AM, MZMcBride <[hidden email]> 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
> [hidden email]
> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Phabricator for code review (defining the plan)

Andre Klapper-2
In reply to this post by MZMcBride-2
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_migrated
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
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Phabricator for code review (defining the plan)

Andre Klapper-2
In reply to this post by Rjd0060 -
On Sun, 2014-10-19 at 10:52 -0400, Rjd0060 wrote:

> On Sun, Oct 19, 2014 at 10:44 AM, MZMcBride <[hidden email]> 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
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Phabricator for code review (defining the plan)

Quim Gil-2
In reply to this post by MZMcBride-2
On Sun, Oct 19, 2014 at 4:44 PM, MZMcBride <[hidden email]> 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#Engineering_Community


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.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Phabricator for code review (defining the plan)

MZMcBride-2
In reply to this post by Rjd0060 -
Rjd0060 wrote:

>On Sun, Oct 19, 2014 at 10:44 AM, MZMcBride <[hidden email]> 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



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Phabricator for code review (defining the plan)

Quim Gil-2
In reply to this post by Quim Gil-2
In fact...

On Mon, Oct 20, 2014 at 1:04 AM, Quim Gil <[hidden email]> 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.

More: https://phabricator.wikimedia.org/T18#12479
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Phabricator for code review (defining the plan)

Gergo Tisza
In reply to this post by Brian Wolff
On Sun, Oct 19, 2014 at 5:44 PM, Brian Wolff <[hidden email]> 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.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l