Regressions in TB 31.x and 33
pidgeot18 at gmail.com
Fri Oct 24 17:21:03 UTC 2014
On 10/24/2014 06:52 AM, Wayne Mery (Thunderbird QA) wrote:
> 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 -
> 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".
After attempting to maintain prior "roadmaps" in the past, I've
concluded that the only chance these have of success is if they are
actively curated by a small group of people who keep the bugs down to a
realistically achievable few. Opening it to the wider community tends to
cause the tracking to degenerate into a list of "my pet feature fixes."
For marketing purposes, it would be better to have a too-small list that
we completely knock off rather than a too-large list that we barely make
I've made a small page with some of the bug numbers I had access to
here: <http://www.tjhsst.edu/~jcranmer/tb38.html> (it also perhaps goes
a bit too overboard on the whole "train" metaphor).
>> 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)
Approvals absolutely need to be grantable only to a select few people
(think module owners level of exclusivity). I'm minded to keep
nominations rather closed as well—you otherwise get lots of people
hankering for their pet features, which is usually a waste of
More information about the tb-planning