Closed Bug 1017648 Opened 7 years ago Closed 7 years ago

migrate mentors from the whiteboard to the mentor field

Categories

(bugzilla.mozilla.org :: General, defect)

Production
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dkl, Assigned: mhoye)

References

Details

Attachments

(3 files)

As part of the move to using custom field for mentor values, we need to move the current mentor values from the whiteboard to the new field once it is in place.

From 649691:
> the discussion points are:
> - after the field is live, it doesn't make sense to have the mentor in both
> the whiteboard and in a mentor field
>   - we'll need migration code to move the mentor out of the whiteboard
>   - should do a pre-migration check for bugs where we're unable to resolve
> the mentor

The normal form of mentor values in the whiteboard are [mentor=dkl@mozilla.com] but can also be [mentor=dkl] or [mentor=:dkl] so the migration script would need to use the same logic as used currently in the _bug_mentors() function in the Review extension.

Question: Do we remove the current [mentor=*] from the whiteboard once we have copied it over to the new custom field? Or do we leave it for backup? Will this cause confusion for new users on which field to use for setting the mentor value(s) for a bug?

dkl
Flags: needinfo?(benjamin)
I'd prefer a clean sweep, if that's a thing we can do easily, and have that information only in one place. Is it possible to have more than one mentor on a bug, if more than one person would be happy to do that?
Assignee: nobody → glob
(In reply to Mike Hoye [:mhoye] from comment #1)
> Is it possible to have more than one mentor on a bug, if more than one person would be
> happy to do that?

yes, we already have bugs with multiple mentors, and that's supported by both the current mentor code (for suggested reviewers), and the patch on bug 649691.
Yes, remove the [mentor] whiteboard tags. If there are ambiguous mentor=foo markings, mhoye and I are willing to hand-triage them.
Flags: needinfo?(benjamin)
Attached patch 1017648_1.patch β€” β€” Splinter Review
Attachment #8440519 - Flags: review?(dkl)
Comment on attachment 8440519 [details] [diff] [review]
1017648_1.patch

Review of attachment 8440519 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. Found 217 users in my recent test database that could not be migrated. Otherwise 1059 others went fine. r=dkl
Attachment #8440519 - Flags: review?(dkl) → review+
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   464be05..86ffc2b  master -> master
Summary: Create a migration script that moves the current mentor values from the whiteboard to the new mentors custom field created by 649691 → migrate mentors from the whiteboard to the mentor field
bsmedberg/mhoye/jdm : let us know when you want this migration to happen.  i assume you'd want to announce it prior to making the switch, and synchronise updating of bugsahoy.
Flags: needinfo?(mhoye)
Flags: needinfo?(josh)
Flags: needinfo?(benjamin)
I'll confirm this with bsmedberg, but I'm happy to move on this as soon as possible. If we can do the migration in two steps - put mentors in the mentoring field on the first pass, remove them from the whiteboard in a second pass later - that will let us turn this on right away without breaking WCIDFM/BA, and we can run the whiteboard cleanup pass once they're patched up.
Flags: needinfo?(mhoye)
(In reply to Mike Hoye [:mhoye] from comment #8)
> I'll confirm this with bsmedberg, but I'm happy to move on this as soon as
> possible. If we can do the migration in two steps - put mentors in the
> mentoring field on the first pass, remove them from the whiteboard in a
> second pass later

as per comments 1 and 3, the migration code does it in a single test.

if that needs to change, then it'll take longer as new code will have to be developed, tested, reviewed, and deployed to production (meaning it can't happen "as soon as possible" :( ).
OK, let's go with what we have. I'll do whatever manual cleanup is required and Josh has agreed to do whatever breakfix work on WCIDFM/BugsAhoy needs breakfixing.

So, as soon as you're ready would be good, and sooner would be even gooder.
Flags: needinfo?(josh)
Flags: needinfo?(benjamin)
gah; looks like the migration script had a bug.
it set the bug_mentor field, updated the whiteboard, and then immediately cleared the bug_mentor field.

i shall write a fix-up script asap.
Attached patch 1017648_2.patch β€” β€” Splinter Review
Attachment #8441458 - Flags: review?(dkl)
Comment on attachment 8441458 [details] [diff] [review]
1017648_2.patch

Review of attachment 8441458 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. We will see what happens on stage. r=dkl
Attachment #8441458 - Flags: review?(dkl) → review+
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   120d7eb..d2c984a  master -> master
Attached file 1017648.txt β€”
This is the output from the migration run earlier today. Mhoye and others, please look for similar lines to:

588759 [good first bug][mentor=mkmelin]
       'mkmelin' failed to match any users
659887 [mentor=rhelmer@mozilla.com]
       'rhelmer@mozilla.com' failed to match any users
...

Those are the ones that will need to be manually looked at.

dkl
How will the manual migration go? Announcement and list of names? Someone looking through all bugs? mkmelin should be mkmelin+mozilla@iki.fi by the way.
A few notes from that list:
rhelmer@mozilla.com should be rhelmer@rhelmer.org
selena@mozilla.com should be sdeckelmann@mozilla.com
jhammel and jlebar are no longer active in the project, bugs where they're tagged as mentor should have them removed.

Boy, giving people a free-form text field to use for structured information just leads to all kinds of crap in there, doesn't it?
Depends on: 1027044
(In reply to David Lawrence [:dkl] from comment #15)
> Those are the ones that will need to be manually looked at.

Sounds good, I'll take it from here.
Assignee: glob → mhoye
OK, manual work done.

Anything else to be done here before closing this?
(In reply to Mike Hoye [:mhoye] from comment #19)
> OK, manual work done.
> 
> Anything else to be done here before closing this?

None that I know of. Thanks!
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.