Closed Bug 898244 Opened 6 years ago Closed 5 years ago

Move RelEng components to new top level product... and rename

Categories

(bugzilla.mozilla.org :: Administration, task)

Production
x86
All
task
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: joduinn, Assigned: glob)

References

Details

After talking with Marcia, hopefully I have all this straight, and the following all makes sense, but there's a lot of moving parts, so let me know if I missed anything, ok?

Thanks
John.
=====

We'd like to move all our "mozilla.org::ReleaseEngineering*" components into a new "Release Engineering" product, instead of being under "mozilla.org" product. For example, "mozilla.org::ReleaseEngineering:Platform Support" would become "Release Engineering::Platform Support". 

As part of that move, we'd also like to rename a few components, and tweak some component descriptions.

Here goes:



To start, please create a new "Release Engineering" top level product, which should appear on the top-level-page of bugzilla.m.o in the "Other" section between "Privacy" and "quality.mozilla.org".

Description: "For bugs related to all aspects of Mozilla's Release Engineering pipeline, including branded releases, Continuous Automation, Release Automation, tools, repos and hooks, machine issues, loaner machines, buildbot."



Once this new top level "Release Engineering" product exists, please move/rename the existing RelEng components as follows:


1) "mozilla.org:ReleaseEngineering"
1a) Rename to "Other" component within the "Release Engineering" product.
1b) Description: 
This component is used for goals, tracking bugs, and any general RelEng work that spans across different RelEng components. Anything that doesn't fit in any other component goes here.


2) "mozilla.org:Release Engineering: Automation (General)"
2a) Rename to "General Automation" within the "Release Engineering" product.
2b) Description: 
This component tracks
* Modifying or removing existing builds, tests and other jobs
* Adding support for new types of jobs, builds or tests (e.g. opt, pgo,
debug, ASAN or code coverage builds; b2g device builds, new test suites;
special builds like spidermonkey or valgrind)
* Scheduler changes: what jobs get run and when


3) "mozilla.org:Release Engineering: Automation (Release Automation)"
3a) Rename to "Release Automation" within the "Release Engineering" product.
3b) Description:
This component tracks bugs related to the Release Automation including,
but not limited to buildbot code.


4) "mozilla.org:Release Engineering: Releases"
4a) Rename to "Releases" within the "Release Engineering" product.
4b) Description:
This component tracks bugs related to specific releases, or updates to
those releases.


5) "mozilla.org:Release Engineering: Machine Management"
5a) Rename to "Buildduty" within the "Release Engineering" product.
5b) Description:
This component tracks the routine care and feeding of RelEng systems
(machine management), reconfigs of masters, and any tree closures or
downtimes. This includes physical machines in any of Mozilla's colos, as
well as instances in AWS.


6) "mozilla.org:Release Engineering: Loan Requests"
6a) Rename to "Loan Requests" within the "Release Engineering" product.
6b) Description:
This component tracks all requests from developers for a loan of a
production machines.


7) "mozilla.org:Release Engineering: Developer Tools"
7a) Rename to "Tools" within the "Release Engineering" product.
7b) Description:
This component tracks large scale tools used to interact with RelEng
systems. Some examples include (but are not limited to):
* vcs2vcs, balrog, tryserver/trychooser, cloud-tools, buildapi,
self-serve, hg/git mapper, integration-with-s3, tools-for-sheriffs,
autoland, kittenherder...
* alerts for colo outages, long-running-jobs,
* reports for wait-times, try-server-top-users, cost reporting, slave
health, ...


8) "mozilla.org:Release Engineering: Platform Support"
8a) Rename to "Platform Support" within the "Release Engineering" product.
8b) Description:
This component tracks requests for supporting builds/tests on a new
operating system. (Examples include: android x86, win 8.1, osx10.9).
This component also tracks requests for toolchain changes (new versions
of compilers, python, hg, git, puppet, GPO, etc.)


9) "mozilla.org:Release Engineering: Repos and Hooks"
9a) Rename to "Repos and Hooks" within the "Release Engineering" product.
9b) Description:
This component handles creating/deleting repos on hg.m.o and git.m.o,
any mirroring between those systems, as well as any hooks on those repos.
Duplicate of this bug: 898557
(In reply to John O'Duinn [:joduinn] from comment #0)
...
> 9) "mozilla.org:Release Engineering: Repos and Hooks"
> 9a) Rename to "Repos and Hooks" within the "Release Engineering" product.
> 9b) Description:
> This component handles creating/deleting repos on hg.m.o and git.m.o,
> any mirroring between those systems, as well as any hooks on those repos.

Sorry for noise, I'd like to tweak this description to address concern raised in bug#898557.

9b) Description:
This component handles creating/deleting Mercurial and Git repos on hg.m.o and git.m.o respectively, any mirroring between those systems, as well as any hooks on those repos.
dkl: as I understand it I would need to create the product, the components, then ask IT to move the bugs for each component. Is there anything else I need to keep in mind?
Flags: needinfo?(dkl)
(In reply to Liz Henry :lizzard from comment #3)
> dkl: as I understand it I would need to create the product, the components,
> then ask IT to move the bugs for each component. Is there anything else I
> need to keep in mind?

This is very similar to a move done in bug 878361 so some of that can be used as reference. Couple of other things we need to be sure of is that we create the proper groups and enable them for the new product so that migrated private bugs stay private. Also we need to look at the flags currently set for all bugs under the old product/components and make sure we have them created/enabled for the new product so that the currently set flags are not dropped during migration as well. And a fairly new feature (but optional) is the reuired reviewer and suggested reviewers that they may want to enable.

As with any change of this nature, users will need to update their stored queries to reflect the changes. 

dkl
Flags: needinfo?(dkl)
> 9b) Description:
> This component handles creating/deleting Mercurial and Git repos on hg.m.o
> and git.m.o respectively, any mirroring between those systems, as well as
> any hooks on those repos.

Can we please use the full hostnames instead of the .m.o abbreviations? I assume I'm not alone in typing hostnames into the "find component" search field when filing bugs. If the full hostnames aren't in the description, these searches don't return the component!
(In reply to Liz Henry :lizzard from comment #3)
> dkl: as I understand it I would need to create the product, the components,
> then ask IT to move the bugs for each component. Is there anything else I
> need to keep in mind?

you don't need to create any of the components in the new product - use syncmsandversions.pl and movecomponent.pl (instead of movebugs.pl).  if you do this component-level configuration (such as review suggestions) will be retained.

as BMO/lib/Data.pm will also need to be updated, it's probably better to co-ordinate this around a bmo push.
(In reply to Byron Jones ‹:glob› from comment #6)
> you don't need to create any of the components in the new product - use
> syncmsandversions.pl and movecomponent.pl (instead of movebugs.pl).  if you
> do this component-level configuration (such as review suggestions) will be
> retained.

to clarify, assuming movecomponent.pl is used..

things that will need to be updated:
 - saved searches
 - external links which references components by name
 - wiki pages which perform per-component searches against bmo
 - dashboards, etc

things that do not need to be updated:
  - bugs :)
  - flags
  - component watching preferences
Any ETA on this?

If its tricky (because of the moving-to-new-top-level-product), could you in the interim do the renaming of the components, and updating of the description for the components? I ask because we're doing bug triage of our bugs to match what will be the new components, and its fiddly having to keep revisiting this bug for the old-name-to new new-name and new scope.
(In reply to John O'Duinn [:joduinn] from comment #8)
> Any ETA on this?

as this change requires a code change to change the visibility of fields, the moves or renames need to be synchronised with our next push.

unfortunately due to our work week this week, we're looking at early next week for push.
Assignee: nobody → glob
Committing to: bzr+ssh://bjones%40mozilla.com@bzr.mozilla.org/bmo/4.2/
modified extensions/BMO/lib/Data.pm
Committed revision 8924.
releng product created, components moved.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
:glob: thanks for the changes, that was a lot to do, and it was great to see this live last night.

Three questions came up today:
1) voting for bugs in RelEng component has gone away. We're ok with that, because we dont actually use that, but wanted to confirm that was known+intended as part of the move+rename.

2) Our previous "release@mozilla-org.bugs" alias that the group used was handy way to cc everyone in the group ... that alias has disappeared. Is there some other alias we should switch to stalking instead? If "release@mozilla-org.bugs" was not intended to disappear, can that alias be recreated? 

3) The "Other" component has no default QA assignee - can you put me for that (joduinn@mozilla.com :joduinn)? The "Repos and Hooks" component has no default QA either, can you put Hal (hwine@mozilla.com :hwine) for that?

Thats it! Thanks again
John.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to John O'Duinn [:joduinn] from comment #12)
> 1) voting for bugs in RelEng component has gone away. We're ok with that,
> because we dont actually use that, but wanted to confirm that was
> known+intended as part of the move+rename.

yes - you didn't ask for voting to be enabled on your new product.
i can enable voting if you require.

> 2) Our previous "release@mozilla-org.bugs" alias that the group used was
> handy way to cc everyone in the group ... that alias has disappeared. Is
> there some other alias we should switch to stalking instead? If
> "release@mozilla-org.bugs" was not intended to disappear, can that alias be
> recreated? 

release@mozilla-org.bugs was the watch-user for the "mozilla.org:ReleaseEngineering" component (meaning watching that user is identical to watching that component).

when the components were renamed, the watch-users were renamed to match, so that one is now "other@releng.bugs".

> 3) The "Other" component has no default QA assignee - can you put me for
> that (joduinn@mozilla.com :joduinn)? The "Repos and Hooks" component has no
> default QA either, can you put Hal (hwine@mozilla.com :hwine) for that?

done
(In reply to Byron Jones ‹:glob› from comment #13)
> (In reply to John O'Duinn [:joduinn] from comment #12)
> > 2) Our previous "release@mozilla-org.bugs" alias that the group used was
> > handy way to cc everyone in the group ... that alias has disappeared. Is
> > there some other alias we should switch to stalking instead? If
> > "release@mozilla-org.bugs" was not intended to disappear, can that alias be
> > recreated? 
> 
> release@mozilla-org.bugs was the watch-user for the
> "mozilla.org:ReleaseEngineering" component (meaning watching that user is
> identical to watching that component).
> 
> when the components were renamed, the watch-users were renamed to match, so
> that one is now "other@releng.bugs".

Considering our old component for this was in product:mozilla.org and component "Release Engineering" it sounds like there wasn't a strict 1:1 relationship between name of user and watch list.

Also that user existed before component watching worked.

Is there any way we can rename or recreate the user to be more intuitive? (we frequently used this user on CC lists for other bugs, outside of our components, and is the only reason I even watch it)  e.g. a "release@releng.bugs" or something?
Bug 904725, voting's already reenabled.
\
Depends on: 905367
Depends on: 908670
i don't think any further action is required on this bug.  please file new bugs if any changes are required.
Status: REOPENED → RESOLVED
Closed: 6 years ago5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.