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