Community
Participate
Working Groups
Now that Helios has shipped, we need to restructure Bugzilla for the new GMP project. We currently have under modeling three Products in Bugzilla: GMF GMP GMP.Graphiti I am not exacly sure why we created a new GMP.Graphiti and a separate GMP. Webmaster: Is this because of what we requested? Webmaster: Is the new way supposed to be to create GMP.Graphiti style components? I would propose: 1) Create GMF-Tooling, GMF-Runtime and GMF-Notation Components under GMP. 2) Move GMF Bugzillas to the three new Components 3) Remove GMF and 1) Create Graphiti Component under GMP. 2) Move GMP.Graphiti Bugzillas to the new Component 3) Remove GMP.Graphiti This would match what exists under EMF, MDT, M2M, etc. in modeling. The downside is that we would loose a subcomponent, for example Graphiti has components Samples and Framework already. GMF also has a bunch of subcomponents, but we do not use them. What do you think?
Michael / Artem, what do you think as well?
(In reply to comment #0) Hi Anthony, your proposal sounds ok to me. We created the subcomponents for future use but are not really sure if we'll really need them. I would rate conformity with EMF higher than having them. So, green light from me. Simply let me know if there is anything I can do. Thanks, Michael
So we just need confirmation from the Eclipse webmasters that we can do the work.
> Webmaster: Is this because of what we requested? Yes. GMP would have rated it's own 'product' anyway. But since the Graphiti request did specify bugzilla details, and the others didn't it made sense that you were planning to treat these projects 'separately', and so a specific product was created for Graphiti. > Webmaster: Is the new way supposed to be to create GMP.Graphiti style > components? That's our goal, but if you really want components we can do that. As you noted it does mean you lose 'sub-components'. > 1) Create GMF-Tooling, GMF-Runtime and GMF-Notation Components under GMP. Not a problem > 2) Move GMF Bugzillas to the three new Components As long as you can give me a map of what goes where I can do this move. We may lose some version information, but I'll do my best to make sure it doesn't happen. > 3) Remove GMF Ok. > 1) Create Graphiti Component under GMP. > 2) Move GMP.Graphiti Bugzillas to the new Component > 3) Remove GMP.Graphiti Ok. -M.
Thanks Matt, Graphiti is easy can be done right away, there is only one Graphiti bugzilla in the database. So we can do 1) Create Graphiti Component under GMP. 2) Move the one GMP.Graphiti Bugzilla to the new Component 3) Remove GMP.Graphiti (In reply to comment #4) > > 1) Create GMF-Tooling, GMF-Runtime and GMF-Notation Components under GMP. > > Not a problem When you create GMF-Tooling for example, you would create a gmp.gmf-tooling.inbox@eclipse.org . Can you figure out who gmf.generation-inbox@eclipse.org is being set to and update to the new address? Alternately, we can send an email to gmf.generation-inbox@eclipse.org with a migration email. I will get a table with the following Bug 237863 > 2) Move GMF Bugzillas to the three new Components We will need to do scripts like we did Bug 237863 (we do not want to mailbomb people). The existing bugs are https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=product&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=Modeling&product=GMF&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0=
> 1) Create Graphiti Component under GMP. > 2) Move the one GMP.Graphiti Bugzilla to the new Component > 3) Remove GMP.Graphiti Done. > > (In reply to comment #4) > > > 1) Create GMF-Tooling, GMF-Runtime and GMF-Notation Components under GMP. > > > > Not a problem > > When you create GMF-Tooling for example, you would create a > gmp.gmf-tooling.inbox@eclipse.org . Sure. I've created inboxes for each component and one for Graphiti(gmp.graphiti@eclipse.org) > Alternately, we can send an email to gmf.generation-inbox@eclipse.org with a > migration email. This is the best way to handle this. > We will need to do scripts like we did Bug 237863 (we do not want to mailbomb > people). Much like that bug I can shut off the mail for a few minutes. I'll just need to let everyone know it's going to happen. -M.
I created a releases table http://www.eclipse.org/modeling/gmp/development/releases.php so I could figure out the list. So the version list for GMP should be: 1.0.0 1.0.1 1.0.2 1.0.3 1.4.0 1.4.1 2.0.0 2.0.1 2.0.2 2.1.0 2.1.1 2.1.2 2.1.3 2.2.0 2.2.1 2.2.2 2.3.0 The milestones list for GMP should be: milestone, sortkey 1.0, 1000 1.0.1, 1010 1.0.2, 1020 1.0.3, 1030 1.4.0, 1400 1.4.1, 1410 2.0, 2000 2.0.1, 2010 2.0.2, 2020 2.1, 2100 2.1.1, 2110 2.2, 2200 2.3, 2300 2.4, 2400 3.0, 3000
(In reply to comment #6) > > 1) Create Graphiti Component under GMP. > > 2) Move the one GMP.Graphiti Bugzilla to the new Component > > 3) Remove GMP.Graphiti > Done. I have adapted Graphiti metadata and Website links to that. Thanks, Michael
I've created the versions and milestones. -M.
(In reply to comment #0) > 2) Move GMF Bugzillas to the three new Components To move the GMF Bugzillas to the three new Components is a two step process. STEP ONE would be to do the cleanup as we did in Bug 237863 to the existing bugs in GMF. We will change targets like 2.2 M3 to just 2.2 and add the comment "[target cleanup] 2.2 M3 was the original target milestone for this bug" the list of milestone changes, each with a comment of the form above: old, new 2.2 M1 -> 2.2 2.2 M2 -> 2.2 2.2 M3 -> 2.2 2.2 M4 -> 2.2 2.2 M5 -> 2.2 2.2 M6 -> 2.2 2.2 M7 -> 2.2 2.2 RC -> 2.2 2.3 M1 -> 2.3 2.3 M2 -> 2.3 2.3 M3 -> 2.3 2.3 M4 -> 2.3 2.3 M5 -> 2.3 2.3 M6 -> 2.3 2.3 M7 -> 2.3 2.3 RC -> 2.3 STEP TWO is to move all the bugs from GMF to GMP Add the comment "[GMF Restructure] Bug 319140 : product GMF and component Definition was the original product and component for this bug" Definition -> GMF-tooling DevTools -> GMF-tooling Docs -> GMF-tooling Generation -> GMF-tooling Generation - Lite -> GMF-tooling Models -> GMF-tooling Models - Generation -> GMF-tooling Models - Graphical -> GMF-tooling Models - Mapping -> GMF-tooling Models - Tooling -> GMF-tooling Reconciler -> GMF-tooling Releng -> Releng Runtime -> GMF-Runtime Runtime Common -> GMF-Runtime Runtime Diagram -> GMF-Runtime Runtime EMF -> GMF-Runtime Samples -> GMF-Tooling Templates -> GMF-Tooling UI -> GMF-Tooling UI - Wizards -> GMF-Tooling Website -> Website
Ok, how about we do the moves this friday starting at 1pm? I'll send a note to the committers letting them know that bugzilla mail will be 'down' for 15 minutes. -M.
(In reply to comment #11) > Ok, how about we do the moves this friday starting at 1pm? I'll send a note to > the committers letting them know that bugzilla mail will be 'down' for 15 > minutes. > > -M. How about Thursday at 1pm instead?
I've sent the notice, and unless someone has a problem/concern Thursday it is. -M.
I'm shutting off the bug mail now. -M.
Mail has been restored. -M.
(In reply to comment #15) > Mail has been restored. > > -M. Do we have to reschedule? GMF is still there as before.
I guess so. Sorry I just realized that while I offered to do the move in comment 4, I took your usage of 'we' in comment 10 to mean that the project was going to move things. -M.
(In reply to comment #17) > I guess so. Sorry I just realized that while I offered to do the move in > comment 4, I took your usage of 'we' in comment 10 to mean that the project was > going to move things. > > -M. OK, Lets schedule the shutting off the bug mail Monday July 19 at 1:00 p.m. EST and I will move the defects from Bugzilla.
I've manged to move the milestones with a quick script that deactivated mail for the people listed on the bug. I'll have to cook up something to move the product/components around to prevent milestone/version losses. -M.
Ok there are a few versions and milestones that GMP seems to be missing. Versions: 1.0,2.0,2.1,2.2,2.3 Milestones: 2.1.2,2.1.3,2.2.1,2.2.2 Shall I add those or should they changed to something else? -M.
(In reply to comment #20) > Ok there are a few versions and milestones that GMP seems to be missing. > > Versions: 1.0,2.0,2.1,2.2,2.3 > Milestones: 2.1.2,2.1.3,2.2.1,2.2.2 > > Shall I add those or should they changed to something else? > > -M. Hi Matt, I do not have access to the portal for GMP. Can you fix? Back in comment 7 I listed all the versions and milestones.
(In reply to comment #20) > Shall I add those or should they changed to something else? Yes, anything missing in GMP needs to be added, we should not change to something else.
Ok I'll add them. I had already added the versions and milestones from comment 7 but in checking the database while planning for the move today I found these. -M.
(In reply to comment #23) > Ok I'll add them. I had already added the versions and milestones from comment > 7 but in checking the database while planning for the move today I found these. > > -M. OK, the versions and milestones should currently be identical as we are only dealing with released versions and have not added the M1-M7 milestones.
Ok I'm going to move these later tonight when the db is quiet. -M.
Ok I've finished the move. Anthony can you confirm all is as you expect? Once I have that I'll remove the gmf stuff. One thing we should think about cleaning up is the default assignees for these bugs. For those assigned to committers we're fine, but those assigned to generic inboxes should be updated. -M.
(In reply to comment #26) > Ok I've finished the move. Anthony can you confirm all is as you expect? Once > I have that I'll remove the gmf stuff. Looks good to me. > One thing we should think about cleaning up is the default assignees for these > bugs. For those assigned to committers we're fine, but those assigned to > generic inboxes should be updated. You mean another bulk update so anything assigned to the old inboxes get assigned to the new inbox? There are 252 bugs found. One more thing as a reminder that I still cannot edit bugzilla components,versions and milestones for your project(s) in the portal.
> Looks good to me. Awesome. I'll clear out the components and products > You mean another bulk update so anything assigned to the old inboxes get > assigned to the new inbox? Yes. > There are 252 bugs found. Actually it looks like there are 814 bugs assigned to the various GMF inboxes. > One more thing as a reminder that I still cannot edit bugzilla > components,versions and milestones for your project(s) in the portal. Sorry this has been fixed. -M.
I think there is one last fix before we can close this. I noticed that Component GMF-Graphiti should be Graphiti. Can you rename to the correct Graphiti?
Just to be clear: you want the component to be called 'Graphiti' not 'GMF-graphiti' and not 'GMF-Graphiti'. -M.
(In reply to comment #30) > Just to be clear: you want the component to be called 'Graphiti' not > 'GMF-graphiti' and not 'GMF-Graphiti'. > > -M. Correct, it should be Graphiti
(In reply to comment #31) > (In reply to comment #30) > > Just to be clear: you want the component to be called 'Graphiti' not > > 'GMF-graphiti' and not 'GMF-Graphiti'. > > > > -M. > Correct, it should be Graphiti Correct also from my side. -Michael
Done. And since you said this was the last fix I'll close out this bug. Please reopen if there are more issues. -M.
