What's the status of papercuts?

111 views
Skip to first unread message

Chris Ilias

unread,
Jun 9, 2012, 1:49:37 AM6/9/12
to tb-pl...@mozilla.org
In late March, Blake sent an email listing UX priorities, including
papercuts. If I do a search for TB and mailnews core bugs with [UXprio]
that are fixed since March 24, I only get one bug (508776). Has there
been any priority given to those bugs?
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

Kent James

unread,
Jul 10, 2012, 11:37:07 PM7/10/12
to tb-pl...@mozilla.org
On 6/8/2012 10:49 PM, Chris Ilias wrote:
> In late March, Blake sent an email listing UX priorities, including
> papercuts. If I do a search for TB and mailnews core bugs with
> [UXprio] that are fixed since March 24, I only get one bug (508776).
> Has there been any priority given to those bugs?
I've often been concerned about the lack of attention within Thunderbird
to long-standing bugs myself, and that also seems to be the source of a
lot of the negative energy that sometimes surrounds the project. But
honestly, I don't have a good feel for how important that is. I do know
that some individuals have a lot of passion and frustration around
certain unfixed bugs, and can generate a lot of negative energy over
that issue.

But let me propose an idea. What if we were to make a list of
well-recognized bugs (not enhancements) in Thunderbird, and make that
the focus of an initial effort for the developer community that is
starting to gel around Thunderbird? That would go against the
conventional wisdom of course that developers are mostly interested in
jazzy new features, but perhaps being different could start to build
some positive energy. I could imagine trying to develop a list of a
certain number of bugs (not enhancements), and set the goal of fixing
them all in some period of time.

So as an example, we could develop a list of 100 Thunderbird bugs that
at least 3 people are willing to vouch for (with a limited number of
vouchers per person, and perhaps some vetting by a benevolent dictator),
and recruit a group of community developers to tackle those in a year.

Count me in, if other people are also willing to be involved.

rkent

Ludovic Hirlimann

unread,
Jul 11, 2012, 5:09:38 AM7/11/12
to tb-pl...@mozilla.org, Kent James
I' think we'd be able to get a lot of interest if we did that. Now let's
be practical, how do we cherry pick these 100 bugs , based on age, votes
, area of the code ?


Ludo
count me in on that one

--
@lhirlimann on twitter
https://wiki.mozilla.org/Thunderbird:Testing

my photos http://www.flickr.com/photos/lhirlimann/collections/


Kent James

unread,
Jul 11, 2012, 8:14:03 AM7/11/12
to tb-pl...@mozilla.org
On 7/11/2012 2:09 AM, Ludovic Hirlimann wrote:
> I' think we'd be able to get a lot of interest if we did that. Now
> let's be practical, how do we cherry pick these 100 bugs , based on
> age, votes , area of the code ?
I was proposing that the list be selected primarily based on a current
nomination (ie vote, or voucher) by people currently active on
tb-planning, with some light vetting by the benevolent dictator. So if
20 people participated, and each was allowed to pick 20 bugs, then there
would be 400 vouchers, and perhaps 50 bugs with three or more votes.

You are free to use your own criteria to select your bugs, that is based
on bugzilla analysis, personal annoyance, grand strategy, whatever.

The benevolent dictator is necessary because there might be some rework
bugs that need to be on the list, and there might be some popular bugs
that require too much rework to be practical.

Ludovic Hirlimann

unread,
Jul 11, 2012, 8:25:46 AM7/11/12
to Kent James, tb-pl...@mozilla.org
On 7/11/12 2:14 PM, Kent James wrote:
>
> The benevolent dictator is necessary because there might be some
> rework bugs that need to be on the list, and there might be some
> popular bugs that require too much rework to be practical.

I agree on that - previous project I was involved with worked because of
a strong leader (or dictator). We need to agree on who's going to be
that person. Ideas on who should do that ?

Ludo

Kent James

unread,
Jul 11, 2012, 9:23:54 AM7/11/12
to tb-pl...@mozilla.org

On 7/11/2012 5:25 AM, Ludovic Hirlimann wrote:
> On 7/11/12 2:14 PM, Kent James wrote:
>>
>> The benevolent dictator is necessary because there might be some
>> rework bugs that need to be on the list, and there might be some
>> popular bugs that require too much rework to be practical.
>
> I agree on that - previous project I was involved with worked because
> of a strong leader (or dictator). We need to agree on who's going to
> be that person. Ideas on who should do that ?
I think it is too early to be very concrete about that - ideally it
would be a group. The main thing that I wanted to do was to dispel the
idea that votes are the only criteria.

Ludovic Hirlimann

unread,
Jul 11, 2012, 9:26:44 AM7/11/12
to Kent James, tb-pl...@mozilla.org
On 7/11/12 3:23 PM, Kent James wrote:
>
> On 7/11/2012 5:25 AM, Ludovic Hirlimann wrote:
>> On 7/11/12 2:14 PM, Kent James wrote:
>>>
>>> The benevolent dictator is necessary because there might be some
>>> rework bugs that need to be on the list, and there might be some
>>> popular bugs that require too much rework to be practical.
>>
>> I agree on that - previous project I was involved with worked because
>> of a strong leader (or dictator). We need to agree on who's going to
>> be that person. Ideas on who should do that ?
> I think it is too early to be very concrete about that - ideally it
> would be a group. The main thing that I wanted to do was to dispel the
> idea that votes are the only criteria.
And I completely agree with that. It wasn't even part of my criteria :-)

Mike Conley

unread,
Jul 11, 2012, 9:52:41 AM7/11/12
to tb-pl...@mozilla.org
I'm on board with this.

The UX-Prio stuff was what I started focusing on after Filelink and
Account Provisioner were released - however, hiccups and developments in
both of those features have continued to distract me from the list.

Anyhow, I agree with rkent - I think this could be an excellent way to
communicate that we're serious about making Thunderbird better / faster/
stronger in this "post innovation driven by Mozilla" phase that we're
entering.

-Mike

On 11/07/2012 9:26 AM, Ludovic Hirlimann wrote:
> On 7/11/12 3:23 PM, Kent James wrote:
>>
>> On 7/11/2012 5:25 AM, Ludovic Hirlimann wrote:
>>> On 7/11/12 2:14 PM, Kent James wrote:
>>>>
>>>> The benevolent dictator is necessary because there might be some
>>>> rework bugs that need to be on the list, and there might be some
>>>> popular bugs that require too much rework to be practical.
>>>
>>> I agree on that - previous project I was involved with worked because
>>> of a strong leader (or dictator). We need to agree on who's going to
>>> be that person. Ideas on who should do that ?
>> I think it is too early to be very concrete about that - ideally it
>> would be a group. The main thing that I wanted to do was to dispel the
>> idea that votes are the only criteria.
> And I completely agree with that. It wasn't even part of my criteria :-)
>
>
> Ludo
>
>
>

Vincent

unread,
Jul 11, 2012, 5:18:26 AM7/11/12
to tb-pl...@mozilla.org
Maybe we can create a meta bug on bugzilla and ask for everyone to add its bug to it. Then some "dictator" review it and remove all the bugs that don't seems to be relevant.

2012/7/11 Ludovic Hirlimann <lud...@mozilla.com>
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning




--
Vincent (caméléon)

Ludovic Hirlimann

unread,
Jul 11, 2012, 10:27:51 AM7/11/12
to Vincent, tb-pl...@mozilla.org
On 7/11/12 11:18 AM, Vincent wrote:
> Maybe we can create a meta bug on bugzilla and ask for everyone to add
> its bug to it. Then some "dictator" review it and remove all the bugs
> that don't seems to be relevant.
That's be confusing, I'm a bit against it. It generates a lot of bug mail :(

Ludo

kers...@gmx.de

unread,
Jul 11, 2012, 3:00:02 AM7/11/12
to tb-pl...@mozilla.org
Good Plan!
Solveing these bug would increase trust in the whole project.

Hein
Gesendet mit BlackBerry® Webmail von Telekom Deutschland

Kent James

unread,
Jul 11, 2012, 10:45:39 AM7/11/12
to tb-pl...@mozilla.org
On 7/11/2012 6:52 AM, Mike Conley wrote:
> I'm on board with this.
>
> The UX-Prio stuff was what I started focusing on after Filelink and
> Account Provisioner were released - however, hiccups and developments
> in both of those features have continued to distract me from the list.
>
> Anyhow, I agree with rkent - I think this could be an excellent way to
> communicate that we're serious ...

Then let's get serious. What I would like to see is a list of people who
have the technical capability to take on a few of these bugs, and are
willing to commit to fixing at least 5 papercut bugs from the list in
the next year. Both volunteers (like myself) and Mozilla Thunderbird
team staff are welcome - but this is a personal commitment, that may or
may not be part of your formal Mozilla assignments (that's for you and
your boss to decide.)

Who is willing to be counted? Mike, can you make this commitment?

Count me in.

rkent

Mike Conley

unread,
Jul 11, 2012, 10:47:58 AM7/11/12
to tb-pl...@mozilla.org
>> Who is willing to be counted? Mike, can you make this commitment?

Yes, count me in.

Joshua Cranmer

unread,
Jul 11, 2012, 10:55:57 AM7/11/12
to tb-pl...@mozilla.org
On 7/11/2012 10:27 AM, Ludovic Hirlimann wrote:
> On 7/11/12 11:18 AM, Vincent wrote:
>> Maybe we can create a meta bug on bugzilla and ask for everyone to
>> add its bug to it. Then some "dictator" review it and remove all the
>> bugs that don't seems to be relevant.
> That's be confusing, I'm a bit against it. It generates a lot of bug
> mail :(

I have personally found bugzilla lacking in terms of being able to
large-scale bug management. Note that the various Firefox teams have all
built their own tools that pull data from Bugzilla but don't use it
directly.

--
Joshua Cranmer
News submodule owner
DXR coauthor

Ludovic Hirlimann

unread,
Jul 11, 2012, 10:58:26 AM7/11/12
to tb-pl...@mozilla.org
On 7/11/12 4:47 PM, Mike Conley wrote:
>>> Who is willing to be counted? Mike, can you make this commitment?
>
> Yes, count me in.
I'll make at least one patch for next year, so count me in.

Tanstaafl

unread,
Jul 11, 2012, 6:19:02 AM7/11/12
to tb-pl...@mozilla.org
On 2012-07-10 11:37 PM, Kent James <ke...@caspia.com> wrote:
> I've often been concerned about the lack of attention within Thunderbird
> to long-standing bugs myself, and that also seems to be the source of a
> lot of the negative energy that sometimes surrounds the project. But
> honestly, I don't have a good feel for how important that is. I do know
> that some individuals have a lot of passion and frustration around
> certain unfixed bugs, and can generate a lot of negative energy over
> that issue.

I agree this is probably the single largest source of negativity I've
seen in my years of using Thunderbird (and participating in these lists
and the forums).

> But let me propose an idea. What if we were to make a list of
> well-recognized bugs (not enhancements) in Thunderbird, and make that
> the focus of an initial effort for the developer community that is
> starting to gel around Thunderbird? That would go against the
> conventional wisdom of course that developers are mostly interested in
> jazzy new features, but perhaps being different could start to build
> some positive energy. I could imagine trying to develop a list of a
> certain number of bugs (not enhancements), and set the goal of fixing
> them all in some period of time.

I love this idea, and think it would go well with a bug bounty system -
as you pointed out, since fixing bugs isn't really considered the
sexiest aspect of programming, this would provide a different incentive.

Also, I'd suggest adding something like a 'Bug Wrangler Heros' page,
where people who successfully tackle these long standing bugs would be
honored - these pages should be long lived (Mozilla should promise to
maintain them as long as they are relevant), so that these devs could
use these pages in their resumes if they wanted...

> So as an example, we could develop a list of 100 Thunderbird bugs that
> at least 3 people are willing to vouch for (with a limited number of
> vouchers per person, and perhaps some vetting by a benevolent dictator),
> and recruit a group of community developers to tackle those in a year.

Personally, I think 100 is too many, at least to start with. I say this
because the usual reason given that a long standing bug is long
standing, is because it is a big job that requires a lot of work to fix
(properly).

So, I'd suggest starting with a much lower number (10?), and look for
someone who can manage them properly (coordinate the people willing to
take them on, divide the bug into sub bugs, etc)...

> Count me in, if other people are also willing to be involved.

Not sure what you mean by 'vouching' above, but if you mean
testing/confirming bugs (and testing fixes, although I can't create my
own builds), I'm happy to help with that.

Tanstaafl

unread,
Jul 11, 2012, 7:19:57 AM7/11/12
to tb-pl...@mozilla.org
On 2012-07-11 5:09 AM, Ludovic Hirlimann <lud...@mozilla.com> wrote:
> On 7/11/12 5:37 AM, Kent James wrote:
>> So as an example, we could develop a list of 100 Thunderbird bugs
>> that at least 3 people are willing to vouch for (with a limited
>> number of vouchers per person, and perhaps some vetting by a
>> benevolent dictator), and recruit a group of community developers
>> to tackle those in a year.

> I' think we'd be able to get a lot of interest if we did that. Now
> let's be practical, how do we cherry pick these 100 bugs, based on
> age, votes, area of the code?

I know I'm not a programmer so may be speaking out of turn, but...

Since the current bugs database is so huge (and there are probably a
*lot* of outdated/old/irrelevant bugs in there), whatever is done, it
should be really easy to find/work with these bugs... so, either an
entirely new bug DB, or at the very least a prominent tab in the current
system so people can browse just these bugs...

I'd start with area of the code/complexity (we want bugs that are most
likely to get worked on), then votes (we want ones that will have the
most positive impact on users), etc...

As for how many, again, I don't think we should start with 100 that are
going to be a lot of work, but... being able to start announcing lots of
long standing fixes, even if they are relatively minor, would be really
good PR (note what happened with LibreOffice when it forked) and would
also serve to attract more potential devs, since most people prefer
working on an active project rather than a seemingly dead one, so maybe
limit the total number of bugs under this new tracker to 100, but limit
the number of 'complex' ones to 10 or so, then have a way to prioritize
bugs from the old/main tracker into a queue, which will automatically
move them into the active tracker as others are closed.

Wayne Mery

unread,
Jul 11, 2012, 11:20:00 AM7/11/12
to tb-pl...@mozilla.org

Quoting Joshua Cranmer <pidg...@gmail.com>:

> On 7/11/2012 10:27 AM, Ludovic Hirlimann wrote:
>> On 7/11/12 11:18 AM, Vincent wrote:
>>> Maybe we can create a meta bug on bugzilla and ask for everyone to
>>> add its bug to it. Then some "dictator" review it and remove all
>>> the bugs that don't seems to be relevant.
>> That's be confusing, I'm a bit against it. It generates a lot of bug mail :(
>
> I have personally found bugzilla lacking in terms of being able to
> large-scale bug management. Note that the various Firefox teams have
> all built their own tools that pull data from Bugzilla but don't use
> it directly.

examples, references would be welcomed

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Kent James

unread,
Jul 11, 2012, 11:22:43 AM7/11/12
to tb-pl...@mozilla.org

On 7/11/2012 3:19 AM, Tanstaafl wrote:
> On 2012-07-10 11:37 PM, Kent James <ke...@caspia.com> wrote:
> ...
>> But let me propose an idea. What if we were to make a list of
>> well-recognized bugs (not enhancements) in Thunderbird, and make that
>> the focus of an initial effort for the developer community that is
>> starting to gel around Thunderbird?...
>
> I love this idea, and think it would go well with a bug bounty system
> - as you pointed out, since fixing bugs isn't really considered the
> sexiest aspect of programming, this would provide a different incentive.
>
> Also, I'd suggest adding something like a 'Bug Wrangler Heros' page,
> where people who successfully tackle these long standing bugs would be
> honored - these pages should be long lived (Mozilla should promise to
> maintain them as long as they are relevant), so that these devs could
> use these pages in their resumes if they wanted...
These kinds of things don't motivate me, don't know about others. But it
is hard for me to picture someone like mconley or jcranmer being
motivated by that, and those are the type of people that we need to fix
these kinds of bugs. But I could be persuaded if this is motivating to
others.

>
>> So as an example, we could develop a list of 100 Thunderbird bugs that
>> at least 3 people are willing to vouch for ...
>
> Personally, I think 100 is too many, at least to start with. I say
> this because the usual reason given that a long standing bug is long
> standing, is because it is a big job that requires a lot of work to
> fix (properly).
>
> So, I'd suggest starting with a much lower number (10?), and look for
> someone who can manage them properly (coordinate the people willing to
> take them on, divide the bug into sub bugs, etc)...
You may be right. But the impressions that you get from the more
negative people is that there are lots of long-neglected bugs that are
simple one line changes, but I also know from my own experience looking
over lists of bugs with lots of bz votes that those are actually quite
hard to find. But I myself could do 5 difficult bugs per year, so the
number that we choose is partly determined by the number of people who
are willing to count themselves in for the effort.
>
>> Count me in, if other people are also willing to be involved.
>
> Not sure what you mean by 'vouching' above, but if you mean
> testing/confirming bugs (and testing fixes, although I can't create my
> own builds), I'm happy to help with that.
My term "vouching" was meant to represent the process of selecting which
bugs you think need fixing, and adding your "voucher" to some number of
those. I meant it as a plural term for the noun "vote". That is an
important process, and I would welcome your participation, but at this
point in time I think that we need to get some committed developers to
lead some credibility to the effort. The people with negative attitudes
(and haven't we all been there at some point?) need some convincing that
this is a serious effort.

rkent

Blake Winton

unread,
Jul 11, 2012, 11:27:13 AM7/11/12
to tb-pl...@mozilla.org
I'm in, too, but I reserve the right to take the easy bugs. ;)

Later,
Blake.
--
Blake Winton Thunderbird User Experience Lead
bwi...@mozilla.com

Blake Winton

unread,
Jul 11, 2012, 11:30:19 AM7/11/12
to tb-pl...@mozilla.org
(Although, having just said that, I wonder if it would be more useful to
the project for me to spend my time mentoring 5 people who want to fix
papercut bugs, instead… Thoughts?)

Later,
Blake.

Joshua Cranmer

unread,
Jul 11, 2012, 11:33:51 AM7/11/12
to tb-pl...@mozilla.org
On 7/11/2012 11:20 AM, Wayne Mery wrote:
>
> Quoting Joshua Cranmer <pidg...@gmail.com>:
>
>> On 7/11/2012 10:27 AM, Ludovic Hirlimann wrote:
>>> On 7/11/12 11:18 AM, Vincent wrote:
>>>> Maybe we can create a meta bug on bugzilla and ask for everyone to
>>>> add its bug to it. Then some "dictator" review it and remove all
>>>> the bugs that don't seems to be relevant.
>>> That's be confusing, I'm a bit against it. It generates a lot of bug
>>> mail :(
>>
>> I have personally found bugzilla lacking in terms of being able to
>> large-scale bug management. Note that the various Firefox teams have
>> all built their own tools that pull data from Bugzilla but don't use
>> it directly.
>
> examples, references would be welcomed

<http://mozilla.github.com/devtools/status/index.html#news> is the
foremost example in my mind. There's also
<http://brasstacks.mozilla.com/orangefactor/>, but that's solving a
moderately different issue.

One idea someone had for papercuts was a screenshot of Thunderbird where
you could hover over various parts and get the last of papercuts in
various issues.

--
Joshua Cranmer
News submodule owner
DXR coauthor

Blake Winton

unread,
Jul 11, 2012, 11:36:11 AM7/11/12
to tb-pl...@mozilla.org
On 11-07-12 11:33 , Joshua Cranmer wrote:
> On 7/11/2012 11:20 AM, Wayne Mery wrote:
>> Quoting Joshua Cranmer <pidg...@gmail.com>:
>>> On 7/11/2012 10:27 AM, Ludovic Hirlimann wrote:
>>>> On 7/11/12 11:18 AM, Vincent wrote:
>>>>> Maybe we can create a meta bug on bugzilla and ask for everyone to
>>>>> add its bug to it. Then some "dictator" review it and remove all
>>>>> the bugs that don't seems to be relevant.
>>>> That's be confusing, I'm a bit against it. It generates a lot of
>>>> bug mail :(
>>> I have personally found bugzilla lacking in terms of being able to
>>> large-scale bug management. Note that the various Firefox teams have
>>> all built their own tools that pull data from Bugzilla but don't use
>>> it directly.
>> examples, references would be welcomed
> <http://mozilla.github.com/devtools/status/index.html#news> is the
> foremost example in my mind. There's also
> <http://brasstacks.mozilla.com/orangefactor/>, but that's solving a
> moderately different issue.
Would http://www.joshmatthews.net/bugsahoy/ be a useful example, too?
> One idea someone had for papercuts was a screenshot of Thunderbird
> where you could hover over various parts and get the last of papercuts
> in various issues.
Something like http://areweprettyyet.com/thunderbird/1/index.htm# ? ;)

Later,
Blake.

--
Blake Winton Thunderbird User Experience Lead
bwi...@mozilla.com

Kent James

unread,
Jul 11, 2012, 11:36:14 AM7/11/12
to tb-pl...@mozilla.org
I think at this point in the process, that is a complexity that is more
confusing than is helpful. 5 bugs over a year is not a huge commitment
for someone who is really familiar with the code (particularly if you
are free to take the easy ones). Per my bz search, bienvenu was the
assignee to 122 bugs that landed in 2011, for example.


On 7/11/2012 8:30 AM, Blake Winton wrote:
> (Although, having just said that, I wonder if it would be more useful
> to the project for me to spend my time mentoring 5 people who want to
> fix papercut bugs, instead… Thoughts?)
>
> Later,
> Blake.

Magnus Melin

unread,
Jul 11, 2012, 1:48:50 PM7/11/12
to tb-pl...@mozilla.org
Kent James wrote:
> Then let's get serious. What I would like to see is a list of people
> who have the technical capability to take on a few of these bugs, and
> are willing to commit to fixing at least 5 papercut bugs from the list
> in the next year. Both volunteers (like myself) and Mozilla
> Thunderbird team staff are welcome - but this is a personal
> commitment, that may or may not be part of your formal Mozilla
> assignments (that's for you and your boss to decide.)
>
> Who is willing to be counted?
>

Count on me too!

-Magnus

acel...@atlas.sk

unread,
Jul 11, 2012, 2:57:27 PM7/11/12
to tb-pl...@mozilla.org
What is then left for me? :)

I don't know if I can be counted into this special team, depends on what kind of difficult bugs are discussed here.
______________________________________________________________
> Od: "Blake Winton" <bwi...@mozilla.com>
> Komu: <tb-pl...@mozilla.org>
> Dátum: 11.07.2012 17:27
> Predmet: Re: Papercuts remixed (was Re: What's the status of papercuts?)

Axel

unread,
Jul 11, 2012, 6:27:04 PM7/11/12
to Blake Winton, tb-pl...@mozilla.org
> (Although, having just said that, I wonder if it would be more useful to the project
> for me to spend my time mentoring 5 people who want to fix papercut bugs, instead…
> Thoughts?)
>
> Later,
> Blake.

probably yes. papercuts is new to me, but maybe you can find something that is
appropriate for my skillset? with some mantoring prvided, you cn count me in as well :)

axel

Axel

unread,
Jul 11, 2012, 6:41:14 PM7/11/12
to Kent James, tb-pl...@mozilla.org

>
> On 7/11/2012 3:19 AM, Tanstaafl wrote:
>> On 2012-07-10 11:37 PM, Kent James <ke...@caspia.com> wrote:
>> ...
>>> But let me propose an idea. What if we were to make a list of
>>> well-recognized bugs (not enhancements) in Thunderbird, and make that
>>> the focus of an initial effort for the developer community that is
>>> starting to gel around Thunderbird?...
>>
>> I love this idea, and think it would go well with a bug bounty system - as you
>> pointed out, since fixing bugs isn't really considered the sexiest aspect of
>> programming, this would provide a different incentive.
>>
>> Also, I'd suggest adding something like a 'Bug Wrangler Heros' page, where people
>> who successfully tackle these long standing bugs would be honored - these pages
>> should be long lived (Mozilla should promise to maintain them as long as they are
>> relevant), so that these devs could use these pages in their resumes if they wanted...
> These kinds of things don't motivate me, don't know about others. But it is hard for
> me to picture someone like mconley or jcranmer being motivated by that, and those
> are the type of people that we need to fix these kinds of bugs. But I could be
> persuaded if this is motivating to others.
what ever happened to the rolling credits that the older versions of fx / tb used to
have? i kind of liked that as motivation...

>
>>
>>> So as an example, we could develop a list of 100 Thunderbird bugs that
>>> at least 3 people are willing to vouch for ...
>>
>> Personally, I think 100 is too many, at least to start with. I say this because the
>> usual reason given that a long standing bug is long standing, is because it is a
>> big job that requires a lot of work to fix (properly).
>>
>> So, I'd suggest starting with a much lower number (10?), and look for someone who
>> can manage them properly (coordinate the people willing to take them on, divide the
>> bug into sub bugs, etc)...
> You may be right. But the impressions that you get from the more negative people is
> that there are lots of long-neglected bugs that are simple one line changes, but I
> also know from my own experience looking over lists of bugs with lots of bz votes
> that those are actually quite hard to find. But I myself could do 5 difficult bugs
> per year, so the number that we choose is partly determined by the number of people
> who are willing to count themselves in for the effort.
I think there are some complex or fundamental ones like format=flowed which are
cintinually mentioned on the newsgroup. they kind of sound important although i
wouldn't know whether they really are. it could also be that some people are more
persistent in repeating their gripes.
>>
>>> Count me in, if other people are also willing to be involved.
>>
>> Not sure what you mean by 'vouching' above, but if you mean testing/confirming bugs
>> (and testing fixes, although I can't create my own builds), I'm happy to help with
>> that.
> My term "vouching" was meant to represent the process of selecting which bugs you
> think need fixing, and adding your "voucher" to some number of those. I meant it as
> a plural term for the noun "vote".
exactly, shouldn't the bug votes somehow be accounted for when prioritizing them?
guess we will need some sort of committee to decide which bugs are really important.
> That is an important process, and I would welcome your participation, but at this
> point in time I think that we need to get some committed developers to lead some
> credibility to the effort.
funny, just what i said without having read the rest of your post. the thing is i
would probably have some opinions but i wouldn't feel experienced enough to have
anything approximating an "informed overview". I think you should be part of such a
panel / committee.

Chris Ilias

unread,
Jul 11, 2012, 4:37:56 PM7/11/12
to tb-pl...@mozilla.org
On 12-07-10 11:37 PM, Kent James wrote:
> On 6/8/2012 10:49 PM, Chris Ilias wrote:
>> In late March, Blake sent an email listing UX priorities, including
>> papercuts. If I do a search for TB and mailnews core bugs with
>> [UXprio] that are fixed since March 24, I only get one bug (508776).
>> Has there been any priority given to those bugs?
> I've often been concerned about the lack of attention within Thunderbird
> to long-standing bugs myself, and that also seems to be the source of a
> lot of the negative energy that sometimes surrounds the project. But
> honestly, I don't have a good feel for how important that is. I do know
> that some individuals have a lot of passion and frustration around
> certain unfixed bugs, and can generate a lot of negative energy over
> that issue.
>
> But let me propose an idea. What if we were to make a list of
> well-recognized bugs (not enhancements) in Thunderbird, and make that
> the focus of an initial effort for the developer community that is
> starting to gel around Thunderbird? That would go against the
> conventional wisdom of course that developers are mostly interested in
> jazzy new features, but perhaps being different could start to build
> some positive energy. I could imagine trying to develop a list of a
> certain number of bugs (not enhancements), and set the goal of fixing
> them all in some period of time.
>
> So as an example, we could develop a list of 100 Thunderbird bugs that
> at least 3 people are willing to vouch for (with a limited number of
> vouchers per person, and perhaps some vetting by a benevolent dictator),
> and recruit a group of community developers to tackle those in a year.
>
> Count me in, if other people are also willing to be involved.

Thanks for responding. :)

One of the reasons I asked about it, is because we already have a list
that Blake asked for feedback on in March. I only mentioned one bug,
because that was the only one fixed since then. For a list of unresolved
[UXprio] bugs, see:
https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr;status_whiteboard=[UXprio];resolution=---

I now see there's also a [ux-papercut] whiteboard tag, so this list
could also do:
https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr;status_whiteboard=[ux-papercut];resolution=---

I also thought [gs] bugs could be used, but there are well over 200 bugs
on that list.

Gervase Markham

unread,
Jul 12, 2012, 5:13:00 AM7/12/12
to Axel, tb-pl...@mozilla.org
On 11/07/12 23:41, Axel wrote:
> what ever happened to the rolling credits that the older versions of fx
> / tb used to have? i kind of liked that as motivation...

It got removed in a redesign; deciding who was in or out was also a
tricky political problem. We now just have the "append-only" credits
list for the entire project: about:credits.

Gerv

Axel Grude

unread,
Jul 12, 2012, 4:20:01 AM7/12/12
to tb-pl...@mozilla.org



(Although, having just said that, I wonder if it would be more useful to the project for me to spend my time mentoring 5 people who want to fix papercut bugs, instead� Thoughts?)

Later,
Blake.

probably yes. papercuts is new to me, but maybe you can find something that is appropriate for my skillset? with some mantoring prvided, you cn count me in as well :)
I can't believe how many spelling mistakes I made. *mentoring *provided *can

One thing I wanted to add is that my experience at the moment is that (my own) Add-ons are eating way too much of my Mozilla time, and that is something I would like to shift towards Thunderbird Core over the next year.

From my own experience (At least in Windows) setting up for bug writing and getting a basic understanding of git and python are some of the major obstacles for somebody trying to enter that world, I think we have to still work on making that a lot easier in order to pull in more people towards core.

Axel


--
Axel Grude
Software Developer
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate4)
AMO Editor

Tanstaafl

unread,
Jul 12, 2012, 5:48:28 AM7/12/12
to tb-pl...@mozilla.org
On 2012-07-11 6:41 PM, Axel <axel....@googlemail.com> wrote:
>> My term "vouching" was meant to represent the process of selecting
>> which bugs you think need fixing, and adding your "voucher" to some
>> number of those. I meant it as a plural term for the noun "vote".

> exactly, shouldn't the bug votes somehow be accounted for when
> prioritizing them? guess we will need some sort of committee to decide
> which bugs are really important.

If Thunderbird is going to become more community driven/oriented, then
indeed votes should count more... they shouldn't be the only factor, but
they should definitely matter. The problem is the flip side - since the
development is community driven/volunteer, there is no way (nor should
there be) to force any developer to work on any given bug...

This is another reason why I am in favor of some kind of bounty system.
It is a way for 'voters' to put their money where their mouth is - and,
it is a simple and meaningful way for the devs/maintainers to deflect
criticism of bugs not getting fixed - ie, "you want it fixed? put up or
shut up! <link to bounty system>". Also, if such a system is put in
place, there needs to be a way to identify pledgers, so if they don't
follow through on their pledges, this fact should be publicized
prominently (to hopefully shame them into making good on it), as well as
to be able to show public appreciation once they do.

Kent James

unread,
Jul 12, 2012, 10:23:59 AM7/12/12
to tb-pl...@mozilla.org
On 7/12/2012 1:20 AM, Axel Grude wrote:
> From my own experience (At least in Windows) setting up for bug
> writing and getting a basic understanding of git and python are some
> of the major obstacles for somebody trying to enter that world, I
> think we have to still work on making that a lot easier in order to
> pull in more people towards core.
While I would agree that there is a substantial learning curve toward
getting involved in Mozilla development, I would not describe "git (hg?)
and python" as the main obstacles.

Testing is certainly an obstacle. As a mostly backend developer, I've
never written (or even run) a Mozmill test - but I live in
xpcshell-tests most of the time. Still, the way that you accomplish
things during testing is often quite different than the way you do it in
the main program, so getting started there is a barrier.

There is also, particularly in the C++ world, a unique Mozilla language
to learn. Peculiar Mozilla constructs (which are now practically native
to me), like

nsCOMPtr<nsIMsgIMAPFolder> imapFolder(do_QueryInterface(folder));

take quite a bit of time to learn.

But new people do get started somehow. I think that most more
experienced developers also are willing to assist people that are
learning. The code base is so vast that we are all learning something
new all of the time anyway. That is part of the skill of doing large
project development, to be able to pick up new areas quickly.

So I think you should go for it, Axel!

Mike Conley

unread,
Jul 12, 2012, 10:31:10 AM7/12/12
to tb-pl...@mozilla.org
Mozmill is where I do most of my testing. I'd be happy to lend a hand.

-Mike

Jb Piacentino

unread,
Jul 12, 2012, 10:31:20 AM7/12/12
to Blake Winton, tb-pl...@mozilla.org

On 11/07/12 17:30, Blake Winton wrote:
(Although, having just said that, I wonder if it would be more useful to the project for me to spend my time mentoring 5 people who want to fix papercut bugs, instead� Thoughts?)
That is absolutely the right way to approach the problem, IMHO: give a man a fish, he can have lunch. Show him how to fish, he can feed his family... (or something along those lines..)

But hold on! That is not a excuse to not take on the easy bugs, right Blake ? ;-)

Jb
�

Mike Conley

unread,
Jul 12, 2012, 10:32:57 AM7/12/12
to tb-pl...@mozilla.org
aceman:

We can use all the help we can get, and you've already proven yourself
to be an incredible contributor. I think you'd be a perfect fit.

-Mike

Joshua Cranmer

unread,
Jul 12, 2012, 11:04:11 AM7/12/12
to tb-pl...@mozilla.org
On 7/12/2012 5:48 AM, Tanstaafl wrote:
> On 2012-07-11 6:41 PM, Axel <axel....@googlemail.com> wrote:
>>> My term "vouching" was meant to represent the process of selecting
>>> which bugs you think need fixing, and adding your "voucher" to some
>>> number of those. I meant it as a plural term for the noun "vote".
>
>> exactly, shouldn't the bug votes somehow be accounted for when
>> prioritizing them? guess we will need some sort of committee to decide
>> which bugs are really important.
>
> If Thunderbird is going to become more community driven/oriented, then
> indeed votes should count more... they shouldn't be the only factor,
> but they should definitely matter. The problem is the flip side -
> since the development is community driven/volunteer, there is no way
> (nor should there be) to force any developer to work on any given bug...

I keep bugzilla queries of highly-voted TB bugs, divided into all bugs
that have more than 50 votes and all bugs filed in the last year with
more than 5 votes. I personally don't set a lot of store by bug
votes--Thunderbird for Android is probably much more useful than
combine-and-decode, but votes would suggest otherwise. The other problem
is that really high-vote bugs also end up being "really complicated
things"--of the top 49 bugs by vote counts, there are maybe 5 bugs which
wouldn't require major invasive changes somewhere. I do follow the lists
from time to time to get an idea of general desires of the community,
and many of the high-ticket items have ended up on the tb-roadmap of
"long-term" plans. But votes are poor proxies for knowing what to work on.

--
Joshua Cranmer
News submodule owner
DXR coauthor

Kent James

unread,
Jul 12, 2012, 11:42:44 AM7/12/12
to tb-pl...@mozilla.org
On 7/12/2012 8:04 AM, Joshua Cranmer wrote:
> really high-vote bugs also end up being "really complicated
> things"--of the top 49 bugs by vote counts, there are maybe 5 bugs
> which wouldn't require major invasive changes somewhere.

One good example of that is bug 105169 "Filter for attachments". MIME
information (such as attachment name or even existence) is not available
at the time that filters are executed. It's a major backend change (with
possible negative performance implications) to provide MIME information
at that point.

My first impulse was to toss those out of the "papercut" list as too
complex, but as I think about it maybe what we should do is to tie these
high-vote bugs to specific backend rework projects that we have talked
about doing. (and actually "filter for attachments" is really an
enhancement and not a failure to meet design specifications ("true
bug"). I really think we need to focus on "true bugs" first).

rkent

Wayne Mery

unread,
Jul 12, 2012, 12:23:38 PM7/12/12
to tb-pl...@mozilla.org
The history of bounties is spotty at best [1]. Bounties tend to be
offered either in the heat of the moment or as a tentative offer. And
integrating bounties into some rating methodology would I think make
things just more complex. OTOH, I wouldn't discourage someome from
offering or making a bounty system more visible. Put [bounty] in
whiteboard after you register your bounty somewhere.

FWIW, as best I can find the official mozilla position is stated in
https://bugzilla.mozilla.org/show_bug.cgi?id=213437


[1] Thunderbird bounty history of past 5 years:

* open bugs
** two very old bounties, probably expired:
https://bugzilla.mozilla.org/show_bug.cgi?id=328418
https://bugzilla.mozilla.org/show_bug.cgi?id=136871
** one current bug at roughly $350:
https://bugzilla.mozilla.org/show_bug.cgi?id=737347, see
http://www.fossfactory.org/project/p294?tab=sponsors#tabs
* fixed bugs - no bounties found



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

BAUVENS Laurent

unread,
Jul 12, 2012, 1:07:24 PM7/12/12
to tb-pl...@mozilla.org
Humm FYI, vote-for-fix and pay-for-fix systems could be worked essentially for individuals but certainly not for businesses and public organizations which have a strict accounting process. Moreover these systems tend to over represent individual needs because one professional TB admin can represent hundreds and even sometimes dozens of thousands users.

AFAIK, in term of number of users, Thunderbird has about 20 million users and some Mozilla sources say only 7 or 8 millions are individual users. So I guess the 12 other millions represent the professional users.
-- 
Laurent BAUVENS

Citation du jour :
> Loi Zéro : Un robot ne peut nuire à l'humanité ni, restant passif, 
> permettre que l'humanité souffre d'un mal. - Isaac Asimov



*****************************************************
"Le contenu de ce courriel et ses eventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire.

Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'Organisme sauf s'il en est disposé autrement dans le présent courriel."
******************************************************

Chris Ilias

unread,
Jul 13, 2012, 12:39:06 AM7/13/12
to tb-pl...@mozilla.org
On 12-07-11 6:41 PM, Axel wrote:
> exactly, shouldn't the bug votes somehow be accounted for when
> prioritizing them? guess we will need some sort of committee to decide
> which bugs are really important.

I think what I said in 2009[1] still applies today.
The threshold of discovering bugzilla, learning how to use it, creating
an account, and voting for a bug is so high that vote count does not
represent what most users want.

[1]<http://markmail.org/message/q2bbgdcqicbzncl3>

Mark Banner

unread,
Jul 13, 2012, 11:48:48 AM7/13/12
to tb-pl...@mozilla.org
On 12/07/2012 18:07, BAUVENS Laurent wrote:
AFAIK, in term of number of users, Thunderbird has about 20 million users and some Mozilla sources say only 7 or 8 millions are individual users. So I guess the 12 other millions represent the professional users.
Possibly professional, but not necessarily. There's some factoring that gets applied to the metrics, I don't know what the exact details are, but I know that some people we don't see so much (e.g. not everyone logs on every day), and some people choose not to do the update checks (or redirect to their own update system).

Mark

Tanstaafl

unread,
Jul 13, 2012, 10:49:09 AM7/13/12
to tb-pl...@mozilla.org
On 2012-07-13 12:39 AM, Chris Ilias <tb-pl...@ilias.ca> wrote:
> On 12-07-11 6:41 PM, Axel wrote:
>> exactly, shouldn't the bug votes somehow be accounted for when
>> prioritizing them? guess we will need some sort of committee to decide
>> which bugs are really important.

> I think what I said in 2009[1] still applies today.
> The threshold of discovering bugzilla, learning how to use it, creating
> an account, and voting for a bug is so high that vote count does not
> represent what most users want.

Maybe not, but I'd say that it does represent a more logical/rational
view of what features should be added/bugs fixed, since people who are
more technically proficient tend to be more logical/rational...

Wayne Mery

unread,
Jul 13, 2012, 12:22:57 PM7/13/12
to tb-pl...@mozilla.org
There are, and have been, many ways to categorize bugs/problems.

Not mentioned yet in recent conversation but very important IMO is
getsatisfaction, which has a wealth of information including a number
for "this affects me", and number of people following:
- https://getsatisfaction.com/mozilla_messaging/ideas/popular
- https://getsatisfaction.com/mozilla_messaging/problems/common
(Some topics are matched to bug reports. Many are not.)

Back to your point - there is a litany of past and current notations
in bugzilla relevant to the current discussion. Some are listed
below. Please post if I've missed any. We can build on these
experiences of these items.

Whiteboard [1]:

[good first bug]
[student project]
[uxprio]
[*papercut]
[b3ux]
[delight]
[mentor=*]

Flags (from most recently instituted to oldest) :
* indicates used by developers for release management

*blocking-thunderbirdX[?|-|+]
wanted-thunderbird[?|-|+]
wanted-thunderbird3[?|-|+]
*blocking-thunderbird3[?|-|+]
*blocking-thunderbird2[?|-|+]

wanted-thunderbird [2] is closest to what is being attempted now with
papercuts. Arguably, the same thing. anyone in buzilla could nominate
wanted-thunderbird, and then someone triaged them.

wanted-thunderbird3 [3] came earlier iirc, and was used inform what
features were wnated for thunderbird3.

wanted-thunderbird and -thunderbird3 possibly didn't scale well due to
the number of nominations and an inability to determine to level of
interest or impact in the user community.

I think of UXPRIO whiteboard as an uber form of wanted-thunderbird3,
but driven UX dev vision.



[1] whiteboard -
https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=substring;field0-0-0=short_desc;type0-0-1=substring;field0-0-1=keywords;type1-0-1=allwordssubstr;resolution=---;classification=Client%20Software;classification=Components;status_whiteboard_type=anywordssubstr;query_format=advanced;status_whiteboard=prio%20ux%20delight%20wanted%20student%20first%20mentor;type0-0-0=anywordssubstr;field1-0-0=short_desc;product=MailNews%20Core;product=Thunderbird;field1-0-1=short_desc;list_id=3695119

[2] wanted-thunderbird+ -
https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=substring;list_id=3695361;field0-0-0=flagtypes.name;type0-0-1=substring;field0-0-1=keywords;type1-0-1=allwordssubstr;resolution=---;classification=Client%20Software;classification=Components;query_format=advanced;type0-0-0=equals;value0-0-0=wanted-thunderbird%2B;field1-0-0=short_desc;product=MailNews%20Core;product=Thunderbird;field1-0-1=short_desc

[3] wanted-thunderbird3+
https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=substring;list_id=3685466;field0-0-0=flagtypes.name;type0-0-1=equals;type1-0-1=allwordssubstr;resolution=---;classification=Client%20Software;classification=Components;query_format=advanced;type0-0-0=equals;value0-0-0=wanted-thunderbird%2B%20;field1-0-0=short_desc;type0-0-2=equals;product=MailNews%20Core;product=Thunderbird;field1-0-1=short_desc
* wanted-thunderbird3?
https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=substring;list_id=3685563;field0-0-0=flagtypes.name;type1-0-1=allwordssubstr;resolution=---;classification=Client%20Software;classification=Components;query_format=advanced;type0-0-0=equals;value0-0-0=wanted-thunderbird3%3F;field1-0-0=short_desc;product=MailNews%20Core;product=Thunderbird;field1-0-1=short_desc


[]

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Axel

unread,
Jul 13, 2012, 12:45:51 PM7/13/12
to tb-pl...@mozilla.org


On 12/07/2012 18:07, BAUVENS Laurent wrote:
AFAIK, in term of number of users, Thunderbird has about 20 million users and some Mozilla sources say only 7 or 8 millions are individual users. So I guess the 12 other millions represent the professional users.
Possibly professional, but not necessarily. There's some factoring that gets applied to the metrics, I don't know what the exact details are, but I know that some people we don't see so much (e.g. not everyone logs on every day), and some people choose not to do the update checks (or redirect to their own update system).
If it is anything to go by, my main extension's Daily user base drops by around 60% (from 25,000 to 15,000) every weekend, which (assuming figures are correct) to me definitely suggests a large corporate / professional user base. Usually minor (4%) growth between Sat and Sun, so I guess these are home users who don't waste their rSaturday with Emails.

Mark Banner

unread,
Jul 13, 2012, 1:37:06 PM7/13/12
to tb-pl...@mozilla.org
On 13/07/2012 17:45, Axel wrote:


On 12/07/2012 18:07, BAUVENS Laurent wrote:
AFAIK, in term of number of users, Thunderbird has about 20 million users and some Mozilla sources say only 7 or 8 millions are individual users. So I guess the 12 other millions represent the professional users.
Possibly professional, but not necessarily. There's some factoring that gets applied to the metrics, I don't know what the exact details are, but I know that some people we don't see so much (e.g. not everyone logs on every day), and some people choose not to do the update checks (or redirect to their own update system).
If it is anything to go by, my main extension's Daily user base drops by around 60% (from 25,000 to 15,000) every weekend, which (assuming figures are correct) to me definitely suggests a large corporate / professional user base.
Firefox and Thunderbird sees this the same. I think it just reflects the working week versus weekend, obviously there will be some corporate influence, but I think there's a lot of people who don't check their email over the weekend, and with mobile devices there may not need to be (e.g. I frequently don't have my laptop on at the weekend, if someone emails me I can check on my phone).

Mark.

Wayne Mery (d531)

unread,
Jul 16, 2012, 9:46:26 AM7/16/12
to tb-pl...@mozilla.org

Axel

unread,
Jul 17, 2012, 7:30:44 AM7/17/12
to Blake Winton, tb-pl...@mozilla.org

On 11-07-12 11:33 , Joshua Cranmer wrote:
On 7/11/2012 11:20 AM, Wayne Mery wrote:
Quoting Joshua Cranmer <pidg...@gmail.com>:
On 7/11/2012 10:27 AM, Ludovic Hirlimann wrote:
On 7/11/12 11:18 AM, Vincent wrote:
Maybe we can create a meta bug on bugzilla and ask for everyone to add its bug to it. Then some "dictator" review it and remove all the bugs that don't seems to be relevant.
That's be confusing, I'm a bit against it. It generates a lot of bug mail :(
I have personally found bugzilla lacking in terms of being able to large-scale bug management. Note that the various Firefox teams have all built their own tools that pull data from Bugzilla but don't use it directly.
examples, references would be welcomed
<http://mozilla.github.com/devtools/status/index.html#news> is the foremost example in my mind. There's also <http://brasstacks.mozilla.com/orangefactor/>, but that's solving a moderately different issue.
Would http://www.joshmatthews.net/bugsahoy/ be a useful example, too?
One idea someone had for papercuts was a screenshot of Thunderbird where you could hover over various parts and get the last of papercuts in various issues.
Something like http://areweprettyyet.com/thunderbird/1/index.htm# ? ;)
nifty!

I also must say that I have already encountered users who recently updated from Thunderbird 3 to current and remarked how "ugly" it had become - a sentiment I partly would agree to (although I might prefer using the term "bland"). I immediately advised Theme installation for remedy.

In summary I think some UI improvements (such as monochrome icons or crippling large icons) aren't strictly necessary if they are based around a certain aesthetic mindset; they also have the disadvantage of taking away some of the individuality of this application, and not always to the benefit of the users; 'nuff said.

Axel

Ludovic Hirlimann

unread,
Aug 7, 2012, 7:09:42 AM8/7/12
to tb-pl...@mozilla.org
On 7/12/12 5:42 PM, Kent James wrote:
> On 7/12/2012 8:04 AM, Joshua Cranmer wrote:
>> really high-vote bugs also end up being "really complicated
>> things"--of the top 49 bugs by vote counts, there are maybe 5 bugs
>> which wouldn't require major invasive changes somewhere.
>
> One good example of that is bug 105169 "Filter for attachments". MIME
> information (such as attachment name or even existence) is not
> available at the time that filters are executed. It's a major backend
> change (with possible negative performance implications) to provide
> MIME information at that point.
>
> My first impulse was to toss those out of the "papercut" list as too
> complex, but as I think about it maybe what we should do is to tie
> these high-vote bugs to specific backend rework projects that we have
> talked about doing. (and actually "filter for attachments" is really
> an enhancement and not a failure to meet design specifications ("true
> bug"). I really think we need to focus on "true bugs" first).
I like that idea - true bugs first and enhancement laters.

How do you deal with bugs that *need* a redesign in that case (/me looks
at the AB) ?

How Many bugs should we extract from bugzilla to work on ?

How do we deal with perf in the long term (ie thinking something along
the line of snappy) ?

--
@lhirlimann on twitter
https://wiki.mozilla.org/Thunderbird:Testing

my photos http://www.flickr.com/photos/lhirlimann/collections/


Kent James

unread,
Aug 7, 2012, 3:26:36 PM8/7/12
to tb-pl...@mozilla.org
On 8/7/2012 4:09 AM, Ludovic Hirlimann wrote:
My first impulse was to toss those out of the "papercut" list as too complex, but as I think about it maybe what we should do is to tie these high-vote bugs to specific backend rework projects that we have talked about doing. (and actually "filter for attachments" is really an enhancement and not a failure to meet design specifications ("true bug"). I really think we need to focus on "true bugs" first).
I like that idea - true bugs first and enhancement laters.

How do you deal with bugs that *need* a redesign in that case (/me looks at the AB) ?

How Many bugs should we extract from bugzilla to work on ?

How do we deal with perf in the long term (ie thinking something along the line of snappy) ?
These are big questions. But I need to put off commenting for now, but perhaps we can come back to them in a month.

I (and I expect others) are currently focused on two questions, the first more urgent and the second bigger:

1) Can I finish my critical core patches in time to make it into TB 17 ESR? This I am doing quietly, fighting core bustages that seem to occur daily.

2) What will be the format and structure of the future Thunderbird community?

I hope to begin posting some possibilities for this in the near future, and I hope we continue to hear more official work from Mozilla and current Thunderbird staff about their thoughts on this.

rkent





Ludovic Hirlimann

unread,
Aug 8, 2012, 5:12:14 AM8/8/12
to Kent James, tb-pl...@mozilla.org
On 8/7/12 9:26 PM, Kent James wrote:

2) What will be the format and structure of the future Thunderbird community?

I hope to begin posting some possibilities for this in the near future, and I hope we continue to hear more official work from Mozilla and current Thunderbird staff about their thoughts on this.
Once I'm done catching up on some emails - I'll start shaping up how I think we should ensure the quality of the product post 17.


Ludo

Nomis101

unread,
Aug 8, 2012, 1:27:39 PM8/8/12
to tb-pl...@mozilla.org
There are some old piece of code in comm-central, for
powerpc-apple-darwin, prebinding, MacOSX10.5.sdk or (in c-sdk) for
MacOSX10.4u.sdk (and so on). Can this be cleaned up or is this old stuff
still needed for something I don't know? If this can be cleaned up, I
have a patch.

Ludovic Hirlimann

unread,
Aug 8, 2012, 1:45:03 PM8/8/12
to Nomis101, tb-pl...@mozilla.org
On 8/8/12 7:27 PM, Nomis101 wrote:
> There are some old piece of code in comm-central, for
> powerpc-apple-darwin, prebinding, MacOSX10.5.sdk or (in c-sdk) for
> MacOSX10.4u.sdk (and so on). Can this be cleaned up or is this old stuff
I still think we need 10.5
> still needed for something I don't know? If this can be cleaned up, I
> have a patch.
> _______________________________________________
>
It can please go on.

Ludo
Reply all
Reply to author
Forward
0 new messages