1120782 - Suppress some older Firefox and mozilla versions from the target milestone dropdowns.

Status: RESOLVED FIXED

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

Description

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

I think it would be useful to not list some of the older Firefox and mozilla versions from the Target Milestone options, as we're really not likely to set some bug's milestone to an ancient version via mcMerge at this point.

Say... anything earlier than Firefox/mozilla 25 just doesn't get listed as an option?

Comment 1

[Ed Morley [:emorley]]

I think we should try asking this upstream in BMO first, and if they wontfix, we can do so in mcMerge.

iirc they can disable specific milestones in specific products, such that existing bugs with the milestone keep them, but it doesn't appear in the select field for new/other bugs.

Comment 2

[David Lawrence [:dkl]]

I will need a list of product/milestone pairs that need to be set to inactive and they will not visible as an option after.

Thanks
dkl

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Version 30 is the oldest Gecko revision that still has any supported branches off it, so I'd suggest drawing the line there (mozilla30/Firefox 30/Thunderbird 30). Even that's probably conservative, but at least that'd make a huge difference.

But I also don't know who needs to formally rubberstamp making this change.

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(In reply to David Lawrence [:dkl] from comment #2)
> I will need a list of product/milestone pairs that need to be set to
> inactive and they will not visible as an option after.
> 
> Thanks
> dkl


For the Firefox product, I'd say the following milestones can be disabled:
Firefox 3
Firefox 3.5
Firefox 3.6
Firefox 4.0b6
Firefox 4.0b7
Firefox 4.0b8
Firefox 4.0b9
Firefox 4.0b10
Firefox 4.0b11
Firefox 4.0b12
Firefox 4.0
Firefox 5
Firefox 6
Firefox 7
Firefox 8
Firefox 9
Firefox 10
Firefox 11
Firefox 12
Firefox 13
Firefox 14
Firefox 15
Firefox 16
Firefox 17
Firefox 18
Firefox 19
Firefox 20
Firefox 21
Firefox 22
Firefox 23
Firefox 24
Firefox 25
Firefox 26
Firefox 27
Firefox 28
Firefox 29


For the Toolkit product, the following can probably be disabled:
Phoenix0.1
Phoenix0.2
Phoenix0.3
Phoenix0.4
Phoenix0.5
Firebird0.6
Firebird0.7
Firebird0.7.1
Firebird0.8
Firefox0.9
Firefox1.0beta
Firefox1.0
Firefox1.0Mac
Firefox1.5rc1
Firefox1.5
Firefox 2 alpha1
Firefox 2 alpha2
Firefox 2 alpha3
Firefox 2 beta1
Firefox 2 beta2
Firefox 2
Firefox 3 alpha1
Firefox 3 alpha2
Firefox 3 alpha3
Firefox 3 alpha4
Firefox 3 alpha5
Firefox 3 alpha6
Firefox 3 alpha7
Firefox 3 alpha8
Firefox 3 beta1
Firefox 3 beta2
Firefox 3 beta3
Firefox 3 beta4
Firefox 3 beta5
Firefox 3
mozilla1.9
Firefox 3.1a1
Firefox 3.1a2
Firefox 3.1b1
Firefox 3.1b2
Firefox 3.1b3
Firefox 3.5b4
Firefox 3.5
mozilla1.9.1
Firefox 3.6a1
Firefox 3.6b1
Firefox 3.6
mozilla1.9.2
Firefox 3.7a1
Firefox 3.7a2
Firefox 3.7a3
Firefox 3.7a4
Firefox 3.7a5
Firefox 4.0b1
Firefox 4.0b2
Firefox 4.0b3
Firefox 4.0b4
Firefox 4.0b5
Firefox 4.0b6
Firefox 4.0b7
Firefox 4.0b8
Firefox 4.0b9
mozilla2.0b5
mozilla2.0b6
mozilla2.0b7
mozilla2.0b8
mozilla2.0b9
Firefox 4.0b10
mozilla2.0b10
Firefox 4.0b11
mozilla2.0b11
Firefox 4.0b12
mozilla2.0b12
Firefox 4.0
mozilla2.0
Firefox 5
mozilla5
Firefox 6
mozilla6
Firefox 7
mozilla7
Firefox 8
Firefox 9
mozilla8
Firefox 10
mozilla9
Firefox 11
mozilla10
Firefox 12
mozilla11
Firefox 13
mozilla12
Firefox 14
mozilla13
Firefox 15
mozilla14
Firefox 16
mozilla15
Firefox 17
Firefox 18
Firefox 19
Firefox 20
Firefox 21
Firefox 22
Firefox 23
Firefox 24
Firefox 25
Firefox 26
Firefox 27
Firefox 28
Firefox 29
mozilla16
mozilla17
mozilla18
mozilla19
mozilla20
mozilla21
mozilla22
mozilla23
mozilla24
mozilla25
mozilla26
mozilla27
mozilla28
mozilla29


For the Core product:
mozilla1.9
mozilla1.9.1
mozilla1.9.2
mozilla2.0b6
mozilla2.0b7
mozilla2.0b8
mozilla2.0b9
mozilla2.0b10
mozilla2.0b11
mozilla2.0b12
mozilla2.0
mozilla5
mozilla6
mozilla7
mozilla8
mozilla9
mozilla10
mozilla11
mozilla12
mozilla13
mozilla14
mozilla15
mozilla16
mozilla17
mozilla18
mozilla19
mozilla20
mozilla21
mozilla22
mozilla23
mozilla24
mozilla25
mozilla26
mozilla27
mozilla28
mozilla29
(The rest I'm less sure about disabling as I don't follow b2g's development as closely, but I think these ones would be safe to disable at this point):
B2G C1 (to 19nov)
B2G C2 (20nov-10dec)
B2G C3 (12dec-1jan)
B2G C4 (2jan on)
1.0.1 Madrid (19apr)
1.0.1 Cert1 (24apr)
1.1 QE1 (5may)
1.0.1 IOT1 (10may)
1.1 CS (11may)
1.0.1 Cert2 (21may)
1.1 QE2 (6jun)
1.0.1 IOT2 (31may)
1.0.1 IOT3 (3jun)
1.1 QE3 (26jun)
1.1 QE4 (15jul)
1.1 QE5
1.1 QE6
1.2 C1(Sep27)
1.2 FC (16sep)
1.2 C2(Oct11)
1.2 C3(Oct25)
1.2 C4(Nov8)
1.2 C5(Nov22)
1.2 C6(Dec6)
1.3 Sprint 1 - 9/27
1.3 Sprint 2 - 10/11
1.3 Sprint 3 - 10/25
1.3 Sprint 4 - 11/8
1.3 Sprint 5 - 11/22
1.3 Sprint 6 - 12/6
1.3 C1/1.4 S1(20dec)
1.3 C2/1.4 S2(17jan)
1.3 C3/1.4 S3(31jan)




With these disabled in the API, mcMerge and other tools that pull the API should have a much cleaner picture of what's actually useful.

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Forgot the Firefox for Android product:
Firefox 11
Firefox 12
Firefox 13
Firefox 14
Firefox 15
Firefox 16
Firefox 17
Firefox 18
Firefox 19
Firefox 20
Firefox 21
Firefox 22
Firefox 23
Firefox 24
Firefox 25
Firefox 26
Firefox 27
Firefox 28
Firefox 29

Comment 6

[David Lawrence [:dkl]]

I have done all except for the ones listed below.

Bbajaj, is it ok to deactivate the milestones listed below in the 'Core' that look like that are used for B2G development?

(In reply to Wes Kocher (:KWierso) from comment #4)
> (The rest I'm less sure about disabling as I don't follow b2g's development
> as closely, but I think these ones would be safe to disable at this point):
> B2G C1 (to 19nov)
> B2G C2 (20nov-10dec)
> B2G C3 (12dec-1jan)
> B2G C4 (2jan on)
> 1.0.1 Madrid (19apr)
> 1.0.1 Cert1 (24apr)
> 1.1 QE1 (5may)
> 1.0.1 IOT1 (10may)
> 1.1 CS (11may)
> 1.0.1 Cert2 (21may)
> 1.1 QE2 (6jun)
> 1.0.1 IOT2 (31may)
> 1.0.1 IOT3 (3jun)
> 1.1 QE3 (26jun)
> 1.1 QE4 (15jul)
> 1.1 QE5
> 1.1 QE6
> 1.2 C1(Sep27)
> 1.2 FC (16sep)
> 1.2 C2(Oct11)
> 1.2 C3(Oct25)
> 1.2 C4(Nov8)
> 1.2 C5(Nov22)
> 1.2 C6(Dec6)
> 1.3 Sprint 1 - 9/27
> 1.3 Sprint 2 - 10/11
> 1.3 Sprint 3 - 10/25
> 1.3 Sprint 4 - 11/8
> 1.3 Sprint 5 - 11/22
> 1.3 Sprint 6 - 12/6
> 1.3 C1/1.4 S1(20dec)
> 1.3 C2/1.4 S2(17jan)
> 1.3 C3/1.4 S3(31jan)

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Hrm, I'm seeing the milestones disabled in a bug on bugzilla, but mcmerge is still showing all of the milestones in its dropdown.

dkl: Does anything different need to be done to bugzilla's API to get consumers to not show the disabled milestones?
Ed: Does mcMerge need to do anything to filter out the disabled milestones from its end?

Comment 8

[Ed Morley [:emorley]]

mcMerge uses https://bugzilla.mozilla.org/bzapi/configuration which still lists the old milestones.

Comment 9

[David Lawrence [:dkl]]

(In reply to Ed Morley [:edmorley] from comment #8)
> mcMerge uses https://bugzilla.mozilla.org/bzapi/configuration which still
> lists the old milestones.

Yeah. Just double checked and it has been this way for a long time. I admit that the current behavior is wrong. The UI properly filters out the inactive milestones/versions but BzAPI does not. I would suggest that we change the behavior to show all milestones, but have an is_active flag that is either true or false. Then the client can filter the disabled values. I would be reluctant to only return active values as some bugs still have the disabled values set.

Anyway, we should file a different bug for the change. Also we need to consider that this change would possibly break a lot of other code that may be looking for the old structure.

dkl

Comment 10

[:glob ✱]

we should disable old milestones when we create new ones on merge day.
https://wiki.mozilla.org/BMO/new-version

should we disable the milestone corresponding with the tracking flag which is disabled?
ie. disable the N-4 milestone?


disabling old versions means people won't be able to report bugs against those versions, so we should probably be more conservative there.  maybe N-8 ?

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

This sounds good to me, we just have to be careful about keeping a milestone for ESR which I think glob's suggestions about n-8 would cover.   I am not sure who else uses this field.  I like the idea of hiding it from the BMO interface but maybe not disabling it in the API.

Comment 12

[:glob ✱]

(In reply to Liz Henry :lizzard from comment #11)
> This sounds good to me, we just have to be careful about keeping a milestone
> for ESR which I think glob's suggestions about n-8 would cover.

my N-8 was directed at versions, not milestones.
we already skip disabling of esr tracking flags, so we should just add a note on the wiki to skip those when disabling versions and milestones.

> I like the idea of hiding it from the BMO interface but maybe not disabling it in the API.

yeah; we really need a simpler API call to get the relevant versions/milestones, with an option to include disabled values.  we have Bug.fields, but that returns all values leaves visibility as an exercise for the caller :|

Comment 13

[bhavana bajaj [:bajaj]]

(In reply to David Lawrence [:dkl] from comment #6)
> I have done all except for the ones listed below.
> 
> Bbajaj, is it ok to deactivate the milestones listed below in the 'Core'
> that look like that are used for B2G development?
> 
> (In reply to Wes Kocher (:KWierso) from comment #4)
> > (The rest I'm less sure about disabling as I don't follow b2g's development
> > as closely, but I think these ones would be safe to disable at this point):
> > B2G C1 (to 19nov)
> > B2G C2 (20nov-10dec)
> > B2G C3 (12dec-1jan)
> > B2G C4 (2jan on)
> > 1.0.1 Madrid (19apr)
> > 1.0.1 Cert1 (24apr)
> > 1.1 QE1 (5may)
> > 1.0.1 IOT1 (10may)
> > 1.1 CS (11may)
> > 1.0.1 Cert2 (21may)
> > 1.1 QE2 (6jun)
> > 1.0.1 IOT2 (31may)
> > 1.0.1 IOT3 (3jun)
> > 1.1 QE3 (26jun)
> > 1.1 QE4 (15jul)
> > 1.1 QE5
> > 1.1 QE6
> > 1.2 C1(Sep27)
> > 1.2 FC (16sep)
> > 1.2 C2(Oct11)
> > 1.2 C3(Oct25)
> > 1.2 C4(Nov8)
> > 1.2 C5(Nov22)
> > 1.2 C6(Dec6)
> > 1.3 Sprint 1 - 9/27
> > 1.3 Sprint 2 - 10/11
> > 1.3 Sprint 3 - 10/25
> > 1.3 Sprint 4 - 11/8
> > 1.3 Sprint 5 - 11/22
> > 1.3 Sprint 6 - 12/6
> > 1.3 C1/1.4 S1(20dec)
> > 1.3 C2/1.4 S2(17jan)
> > 1.3 C3/1.4 S3(31jan)

yes, its fine to clean these up as long as I can extract any historical data in future if needed..

Comment 14

[David Lawrence [:dkl]]

(In reply to bhavana bajaj [:bajaj] from comment #13)
> (In reply to David Lawrence [:dkl] from comment #6)
> > > 1.3 C1/1.4 S1(20dec)
> > > 1.3 C2/1.4 S2(17jan)
> > > 1.3 C3/1.4 S3(31jan)
> 
> yes, its fine to clean these up as long as I can extract any historical data
> in future if needed..

Yes. We just disable them from use. Bugs where the value is set are not changed.

All done.

dkl

Comment 15

[Ed Morley [:emorley]]

(In reply to Byron Jones ‹:glob› from comment #12)
> yeah; we really need a simpler API call to get the relevant
> versions/milestones, with an option to include disabled values.  we have
> Bug.fields, but that returns all values leaves visibility as an exercise for
> the caller :|

I've filed bug 1124255 for giving mcMerge a way to find out what target milestones are active, rather than the current situation of having https://bugzilla.mozilla.org/bzapi/configuration return them all :-)

Comment 16

[Ryan VanderMeulen [:RyanVM]]

(In reply to David Lawrence [:dkl] from comment #14)
> (In reply to bhavana bajaj [:bajaj] from comment #13)
> > (In reply to David Lawrence [:dkl] from comment #6)
> > > > 1.3 C1/1.4 S1(20dec)
> > > > 1.3 C2/1.4 S2(17jan)
> > > > 1.3 C3/1.4 S3(31jan)
> > 
> > yes, its fine to clean these up as long as I can extract any historical data
> > in future if needed..
> 
> Yes. We just disable them from use. Bugs where the value is set are not
> changed.

They're still visible in the Core component.

Comment 17

[David Lawrence [:dkl]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #16)
> (In reply to David Lawrence [:dkl] from comment #14)
> > (In reply to bhavana bajaj [:bajaj] from comment #13)
> > > (In reply to David Lawrence [:dkl] from comment #6)
> > > > > 1.3 C1/1.4 S1(20dec)
> > > > > 1.3 C2/1.4 S2(17jan)
> > > > > 1.3 C3/1.4 S3(31jan)
> > > 
> > > yes, its fine to clean these up as long as I can extract any historical data
> > > in future if needed..
> > 
> > Yes. We just disable them from use. Bugs where the value is set are not
> > changed.
> 
> They're still visible in the Core component.

I do not see them. Where are you seeing these values still?

Comment 18

[Ryan VanderMeulen [:RyanVM]]

As discussed on IRC, it was the 1.4 jobs I was seeing. I guess we might as well leave them around since v1.4 isn't EOL yet, even though the odds of anybody intentionally setting a bug to them are essentially zero at this point.