Regressions in TB 31.x and 33

Joshua Cranmer pidgeot18 at
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 - 
> - combined 
> with the target milestone as firefox is doing 
>  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 
progress on.

I've made a small page with some of the bug numbers I had access to 
here: <> (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 
everybody's time.

More information about the tb-planning mailing list