Regressions in TB 31.x and 33

Wayne Mery (Thunderbird QA) vseerror at Lehigh.EDU
Fri Oct 24 11:52:25 UTC 2014


On 10/24/2014 2:02 AM, Magnus Melin wrote:
> On 24.10.2014 00:10, Archaeopteryx wrote:
>> I am considering getting tracking-thunderbird38 and status-thunderbird38
>>> tracking flags added that we can use to track issues the we are trying
>>> to achieve in our next major release.
> Getting the 38 flags showing already is a good idea, especially as the
> in-between "blockers" would not really block unless they were real
> showstoppers. It should probably be tracking-thunderbird_esr38 if we
> want to follow the current convention.
>
>> So, how do we distinguish hard blockers from things we want to get
>> done, but are not essential?
>
> Hard blockers should get tracking-thunderbird_esr38+
> "Things we want done" for a particular release, and no staff does not
> work very well together. Even if some things gets a plus, that buys you
> fairly little besides some limited increased visibility.

So Kent is talking about bugs/features that have been identified as very 
serious Thunderbird Team goals for the release, which are a step above 
"nice to have" - maildir for example.

*IF* they are few enough in number, we could choose to conflate them 
with tracking-thunderbird_esr38+, and as we approach release time we 
periodically reassess their status - if the feature isn't going to meet 
the time goal or the quality goal, then it gets dropped from blocking 
and perhaps goes on some other status.  The advantage of this approach 
is you have fewer fields to create and watch for the release.  iirc this 
has been done before and worked OK.  Further, these "not quite hard 
blocker" bugs could be distinguished as such by using the "feature" 
keyword - https://bugzilla.mozilla.org/describekeywords.cgi#feature

Another possible conflation approach is "feature" keyword - 
https://bugzilla.mozilla.org/describekeywords.cgi#feature - combined 
with the target milestone as firefox is doing 
https://wiki.mozilla.org/Features/Release_Tracking.  TM was mentioned in 
other posts as being used to indicate when a bug was fixed, but I see no 
problem with using TM in this manner for still-open bugs.

Another possible approach is to use a meta bug "feature goals for TB38".

I'd need to hear counterarguments and sleep on this before offering 
which one is my clear favorite.


> We could just put [wanted-thunderbird-next] in the whiteboard as things
> come up, and only some limited group would set that. But going through
> nominations is really time consuming so I don't think it's really worth
> having a requestable flag for it.

agreed. As someone who participated in the two previous experiments we 
don't want to go down the route of open nominations unless we have a 
clear path to successfully handling them - which means boatloads of 
developers with time on their hands. (to be clear, the experiments were 
worth attempting - but the results were on the order of our more recent 
papercuts effort, i.e. not great results)




More information about the tb-planning mailing list