Changing how we use flags for branch management in Bugzilla
Samuel Sidler
As a follow up to what we talked a bit about during the Platform
meeting today, here's a pretty detailed explanation for how we're
going to use flags for branch management going forward (1.9.1.2 and
later but not 1.9.0.x).
== First, the new: status1.9.1. ==
This new flag will replace the "wanted1.9.1.x" flag as well as all
fixed1.9.1.x keywords (starting after 1.9.1.1). We previously used the
wanted flag to mean a few things: if minused, it meant "this doesn't
affect 1.9.1.x"; if plussed, it had two possible meanings, it's either
a bug we want or a bug we need eventually.
The current possible values for status1.9.1 are:
* needstriage - basically '?', meaning we need to determine the status
of this bug on 1.9.1.x
* unaffected - this bug doesn't affect 1.9.1
* wontfix - this bug affects 1.9.1, but we do not plan on fixing it
* wanted - this bug affects 1.9.1 and we'd like to fix it
* .3-fixed - this bug was fixed in 1.9.1.3
* .2-fixed - this bug was fixed in 1.9.1.2
* (and so on... fixed options will exist for all versions we do)
Verifications will be handled using the "verified1.9.1" keyword, in
conjunction with the ".n-fixed" status.
== Now, the old-ish: blocking1.9.1. ==
The new "blocking1.9.1" flag replaces the flag-per-release system
we've used in the past to indicate blocking each release. Where before
we had "blocking1.9.1.1" and "blocking1.9.1.2" active at the same
time, we'll now only have one "blocking1.9.1" flag.
The current possible values for blocking1.9.1 are:
* needed - this bug needs to block on the 1.9.1 branch but aren't sure
which release it will block
* ? - nomination for blocking a 1.9.1.x release
* "minus" - this bug will not block a 1.9.1.x release
* .3+ - this bug blocks 1.9.1.3
* .2+ - this bug blocks 1.9.1.2
* (and so on... "plus" options will exist for all version we do)
== Where are the flags? ==
Flag are located beneath all other flags on the current page where
your friendly "blocking-fennec" flag is. Because they're technically
"custom fields" in Bugzilla, this is where they'll always be.
== What can I set? ==
We set specific permissions on the flags as follows:
* blocking1.9.1: anyone can set "?", only branch drivers can set other
options
* status1.9.1: canconfirm users can set all options except "wanted",
which only branch drivers can set
== Questions? ==
Let me know if you have any questions. We hope this setup works better
than our previous setup, but it will take some getting used to. For a
number of you who work on the branch, this will be confusing since
we're not implementing it for 1.9.0.x. Hopefully after we end-of-life
that branch things will be easier. :)
-Sam
Frédéric Buclin
> * .3+ - this bug blocks 1.9.1.3
> * .2+ - this bug blocks 1.9.1.2
How do you track "emergency" releases? E.g. you are working on 1.9.1.2,
suddenly realize there is a major security bug which worths its own
release, and you decide to rename 1.9.1.2 to 1.9.1.3 so that you can
release 1.9.1.2 asap. Till now, you were setting blocking1.9.1.2+ and
blocking1.9.1.3+ at the same time, as you already created the 1.9.1.2
mini-branch. This is no longer possible here.
LpSolit
Samuel Sidler
> Le 15. 07. 09 01:27, Samuel Sidler a écrit :
I'm guessing you mean specific bugs that need to land both on the
release branch (created for, in your example, 1.9.1.1) and on the
regular 1.9.1 branch.
In those cases, the bug will block the emergency release (in your
example, 1.9.1.2). We'll ensure that it's checked in in both places
before moving forward with the release (again in your example,
1.9.1.2) since we do that anyway to ensure tests get run on the patch
as checked in.
To answer the follow up question of how we track that it's been fixed
in two places, we'll use the emergency release number for the fixed
status (in your example, "status1.9.1.2-fixed") and QA will verify
both the emergency build and the 1.9.1 nightly build during their
verifications.
-Sam
Jean-Marc Desperrier
> The new "blocking1.9.1" flag replaces the flag-per-release system we've
> used in the past to indicate blocking each release
Wouldn't it be more explicit if written as "blocking1.9.1.x" ?
Samuel Sidler
A little bit more explicit, but also more confusing. We're hoping this
type of flag works well and we can use them going forward for other
branches (but maybe not 1.9.2 since it's already pretty far along
now). In that case, it'd be the same custom flag for blocking1.9.2
final as it would be for a dot release. We're not there yet, but
optimism is good.
-Sam
John J. Barton
> Hey everyone,
>
> As a follow up to what we talked a bit about during the Platform meeting
> today, here's a pretty detailed explanation for how we're going to use
> flags for branch management going forward (1.9.1.2 and later but not
> 1.9.0.x).
>
> == First, the new: status1.9.1. ==
>
> This new flag will replace the "wanted1.9.1.x" flag as well as all
> fixed1.9.1.x keywords (starting after 1.9.1.1). We previously used the
> wanted flag to mean a few things: if minused, it meant "this doesn't
> affect 1.9.1.x"; if plussed, it had two possible meanings, it's either a
> bug we want or a bug we need eventually.
>
> The current possible values for status1.9.1 are:
> * needstriage - basically '?', meaning we need to determine the status
> of this bug on 1.9.1.x
But then what does "---" mean?
> * unaffected - this bug doesn't affect 1.9.1
> * wontfix - this bug affects 1.9.1, but we do not plan on fixing it
> * wanted - this bug affects 1.9.1 and we'd like to fix it
> * .3-fixed - this bug was fixed in 1.9.1.3
> * .2-fixed - this bug was fixed in 1.9.1.2
> * (and so on... fixed options will exist for all versions we do)
What does ".2-fixed" mean to the reporting user? Maybe "All the work is
done and the fix will appear in FF 3.5.2?"
jjb
Mike Beltzner
> But then what does "---" mean?
It means that the flag hasn't been set. Because these aren't actually
bugzilla "flags" (they're special fields) there's no way, AIUI, to
have " "
> What does ".2-fixed" mean to the reporting user? Maybe "All the work
> is done and the fix will appear in FF 3.5.2?"
Yes, it means that the fix was taken on the branch (mozilla-1.9.1) in
time for the 1.9.1.2 release branch.
cheers,
mike
John J. Barton
> On 17-Jul-09, at 12:59 PM, John J. Barton wrote:
>
>> But then what does "---" mean?
>
> It means that the flag hasn't been set. Because these aren't actually
> bugzilla "flags" (they're special fields) there's no way, AIUI, to have
> " "
So what value should status1.9.1 have when the bug has a patch in review?
jjb
Dave Townsend
Any of '---', 'needstriage', 'unaffected', 'wontfix', 'wanted' are
applicable depending on the status of the bug on the 1.9.1 branch.
Whether there is a patch on the bug or whether there is a review request
on the patch makes no difference.
Mike Beltzner
> So what value should status1.9.1 have when the bug has a patch in
> review?
Depends. As Sam wrote, the possible values are:
--- no flag set
wanted drivers have indicated that this is an issue they would like
to see fixed on branch
needstriage drivers have been asked, but have not answered, if this
issue affects branch
unaffected drivers have indicated that this issue does not affect
the branch
wontfix drivers have indicated they they do not want to take this
fix on the branch
.2-fixed shouldn't be set in this case, as the patch is in review
and issue isn't fixed
cheers,
mike
John J. Barton
Ok, it just seems silly to have a system with all these flags and values
then folks have to put [FIX] it the bug title to signal that the
developers work is done but the fix has not landed for building.
jjb
John J. Barton
> On 17-Jul-09, at 1:41 PM, John J. Barton wrote:
>
>> Ok, it just seems silly to have a system with all these flags and
>> values then folks have to put [FIX] it the bug title to signal that
>> the developers work is done but the fix has not landed for building.
>
> marked FIXED or status1.9.1.2-fixed once the fix has landed.
I guess I don't understand the relationship between a patch under review
and "landed". I thought that maybe the attached patches under review
were not in the hg tree until 'landed'. At that point FIXED or
status..fixed applies. Before then the patch is only on the developers
tree and in the bug.
For me the state "there is a patch" is very important. It completely
changes the state of the bug. But it does not seem to be reflected in
any of the bugzilla flags.
>
> What are you specifically talking about?
eg
https://bugzilla.mozilla.org/show_bug.cgi?id=504032
https://bugzilla.mozilla.org/show_bug.cgi?id=495176
jjb
Benjamin Smedberg
> For me the state "there is a patch" is very important. It completely
> changes the state of the bug. But it does not seem to be reflected in
> any of the bugzilla flags.
Indeed, there's hardly any reason to create another flag for something like
that, which is just likely to get out of sync with reality. The best way to
see whether a bug has a patch is to see whether the bug has a patch ;-)
--BDS
Michael Lefevre
Sure. But what if you want to know which out of a large list of bugs
has a patch? You can't (as far as I know) see it from a bug list, and
you presumably don't want to have to open up dozens of bugs in turn to
check each one of them? I assume that is why some developers put [FIX]
in the bug description when there is a patch.
Michael
Boris Zbarsky
>> What are you specifically talking about?
>
> eg
> https://bugzilla.mozilla.org/show_bug.cgi?id=504032
> https://bugzilla.mozilla.org/show_bug.cgi?id=495176
I tend to flag bugs that I own where I've put up a patch (and hence am
now just waiting on review and such) with that, so that when I look at
my buglist I know I don't need to worry about them.
A flag wouldn't really address this usecase.
-Boris
Benjamin Smedberg
> Sure. But what if you want to know which out of a large list of bugs
> has a patch? You can't (as far as I know) see it from a bug list, and
> you presumably don't want to have to open up dozens of bugs in turn to
> check each one of them? I assume that is why some developers put [FIX]
> in the bug description when there is a patch.
Sure... in the bug charts, add "Attachment is patch" "is equal to" "1"
You can exclude obsolete patches in a similar way.
All open bugs with non-obsolete patches in the XPCOM component:
or, if your client mangles long URLs: http://tinyurl.com/m3qzoc
--BDS
Daniel Veditz
> I tend to flag bugs that I own where I've put up a patch (and hence am
> now just waiting on review and such) with that, so that when I look at
> my buglist I know I don't need to worry about them.
>
> A flag wouldn't really address this usecase.
No, but a "next-step" field as proposed by Jesse and others would. In
the meantime Jesse proposes standardizing on "[needs ....]" in the
status whiteboard, which can be made visible in bug lists. It also shows
up at the top of each bug and could be a handy summary.
[needs patch]
(unnecessary? an unfixed bug w/out [needs something else needs a patch)
[needs r=bob]
[needs landing]
[needs 1.9.0 backport]
etc.
Probably most useful if we standardize on putting that first in the
whiteboard.
Daniel Veditz
> Ok, it just seems silly to have a system with all these flags and values
> then folks have to put [FIX] it the bug title to signal that the
> developers work is done but the fix has not landed for building.
These are flags are specifically for the 1.9.1 branch (and future
branches if it seems to work). There's a larger project led by Gerv to
revamp BMO in general and if mainline bug development sprouts more
statuses we can echo that in the branch status field.
Boris Zbarsky
> No, but a "next-step" field as proposed by Jesse and others would. In
> the meantime Jesse proposes standardizing on "[needs ....]" in the
> status whiteboard, which can be made visible in bug lists.
If it also showed up in dep trees, that would cover my usecases, yes.
-Boris
John J. Barton
And perhaps Gerv will succeed. But most likely these incremental fixes
will dominate. There are three majors groups of users for BMO: managers,
developers, and reporters (users). While I understand that managers have
a difficult job and need the bulk of the support, the incremental
improvements for them are arcane and focused on a narrow part of the bug
lifecycle. They build up and now dominate the UI. Almost nothing goes
towards helping reporters know: Did my contribution make a difference?
jjb
Mike Shaver
Barton<johnj...@johnjbarton.com> wrote:
> And perhaps Gerv will succeed. But most likely these incremental fixes will
> dominate. There are three majors groups of users for BMO: managers,
> developers, and reporters (users). While I understand that managers have a
> difficult job and need the bulk of the support, the incremental improvements
> for them are arcane and focused on a narrow part of the bug lifecycle. They
> build up and now dominate the UI. Almost nothing goes towards helping
> reporters know: Did my contribution make a difference?
Man.
I think that's a really important insight. I'm going to be thinking
about that for days.
Thanks, John.
Mike
Mike Shaver
> On Tue, Jul 21, 2009 at 11:51 PM, John J.
> Barton<johnj...@johnjbarton.com> wrote:
>> reporters know: Did my contribution make a difference?
>
> about that for days.
There has been some confusion (people watch this group like a hawk, it
seems), so to be clear:
I am not being sarcastic at all. We need to build tools that reflect
the value we place on contributions, and that welcome people into what
is (likely necessarily) a very complex and fast-moving process. The
*least* we can do is show people how the bug they helped us find
(test, reduce, confirm) has been handled so far, and what's left to
do. It's easy to lose sight of that, especially for those of us who
have spent a third of our lives working on the project, and are
surrounded by its smells and textures all day.
Myself and other people who wake up in the morning thinking "pants are
a blocker but toast is only wanted, and I wouldn't touch the leftover
eggs without a lot more testing" should have tools available to Read
The Matrix of bug annotations, but even we would benefit from a big
top-level indicator of where the bug is in the wilds of our workflow.
I have a lot of hope for Jesse's GTD and other people's streamlining
suggestions, but we should be looking for incremental fixes to help
clean it up in the meantime as well.
I think Gerv will succeed in getting us a lot closer to that state,
but perhaps not in the way that you're thinking of. :)
Mike
Zack Weinberg
> On Wed, Jul 22, 2009 at 12:05 AM, Mike Shaver<mike....@gmail.com>
> wrote:
> > On Tue, Jul 21, 2009 at 11:51 PM, John J.
> > Barton<johnj...@johnjbarton.com> wrote:
> >> Almost nothing goes towards helping
> >> reporters know: Did my contribution make a difference?
> >
> > I think that's a really important insight. I'm going to be thinking
> > about that for days.
>
> There has been some confusion (people watch this group like a hawk, it
> seems), so to be clear:
>
> I am not being sarcastic at all. We need to build tools that reflect
> the value we place on contributions, and that welcome people into what
> is (likely necessarily) a very complex and fast-moving process. The
> *least* we can do is show people how the bug they helped us find
> (test, reduce, confirm) has been handled so far, and what's left to
> do. It's easy to lose sight of that, especially for those of us who
> have spent a third of our lives working on the project, and are
> surrounded by its smells and textures all day.
I've said this before and it's not really any more than what John said,
but: I know a bunch of people who have *given up* on reporting bugs to
Mozilla because their expectation is that no matter how much effort
they put into it, their report will be silently ignored. These are not
the great unwashed, either; these are people (mostly web developers) who
*could* be sending us valuable feedback if we demonstrated that we
wanted it.
zw
Justin Dolske
> I've said this before and it's not really any more than what John said,
> but: I know a bunch of people who have *given up* on reporting bugs to
> Mozilla because their expectation is that no matter how much effort
> they put into it, their report will be silently ignored.
Are there other large projects that do a good (or even just "better")
job in this respect?
Justin
Robert Kaiser
> We need to build tools that reflect
> the value we place on contributions
IMHO, it would be really nice if we had a tool that would make visible
contributions to the code in a similar style to what Jonathan Corbet
does for the Linux kernel, see e.g. http://lwn.net/Articles/334721/
We could have stats for written code and reviews there, probably, it's
shouldn't require more than some time and a collection of scripts to do
that.
I know that's probably something slightly different from what you were
talking of in that post, but I think it would be really nice if we would
have something like that.
Robert Kaiser
Mike Shaver
> I've said this before and it's not really any more than what John said,
> but: I know a bunch of people who have *given up* on reporting bugs to
> Mozilla because their expectation is that no matter how much effort
> the great unwashed, either; these are people (mostly web developers) who
> *could* be sending us valuable feedback if we demonstrated that we
> wanted it.
Surely if they cc: you, you can make sure that it's not silently
ignored? It doesn't solve the general problem, but it seems like
you're talking about specific high-value people with whom you have a
relationship, so it seems like they could use that. (I get people to
cc: me on bugs, because I know they're going to ask me about their
bugs, and I'd rather have the answer when they do.)
But you've been working on Mozilla for a while now, and know your way
around: how have you changed to be more responsive to bug reporters in
the areas you work on? what's worked and what hasn't? how do you
indicate to people that their report was useful (or how it could be
more useful, if it wasn't actually especially useful the first time)?
Do your web-developer friends report bugs to other browser projects
and get better results?
(TBH, I don't know of many bugs that are silently ignored, but many
don't get fixed right away. If they're clear and have an example,
it's much more common that there is initial commentary and then the
bug goes idle until progress is made on fixing it. Could you mail me
some bug examples that were just silently ignored? Might be something
strange going on with a certain component or type of bug.)
Mike
Mike Shaver
> Mike Shaver wrote:
>>
>> We need to build tools that reflect
>> the value we place on contributions
>
> IMHO, it would be really nice if we had a tool that would make visible
> contributions to the code in a similar style to what Jonathan Corbet does
> for the Linux kernel, see e.g. http://lwn.net/Articles/334721/
>
> We could have stats for written code and reviews there, probably, it's
> shouldn't require more than some time and a collection of scripts to do
> that.
What tools would you need to write such a script? Or do you mean that
it would be really nice to have that, but not so nice that you would
devote time to it? :)
Mike
Robert Kaiser
> On Wed, Jul 22, 2009 at 7:54 AM, Robert Kaiser<ka...@kairo.at> wrote:
>> Mike Shaver wrote:
>>>
>>> We need to build tools that reflect
>>> the value we place on contributions
>>
>> IMHO, it would be really nice if we had a tool that would make visible
>> contributions to the code in a similar style to what Jonathan Corbet does
>> for the Linux kernel, see e.g. http://lwn.net/Articles/334721/
>>
>> We could have stats for written code and reviews there, probably, it's
>> shouldn't require more than some time and a collection of scripts to do
>> that.
>
> What tools would you need to write such a script?
Time. I've been thinking a bit about how it could be done in idle time I
spend away from the computer, but I didn't find the time to try actually
coding something. Having access to the pushlog database itself could be
helpful in some way, though, for someone looking into such a thing.
If someone would take off a number of SeaMonkey tasks off my shoulders,
I may have time to look into this, but I think it's more likely we'll
find some student or so to look into such a script - it would probably
even make a nice paper or such in a university or college.
> Or do you mean that
> it would be really nice to have that, but not so nice that you would
> devote time to it? :)
I've thought a few times about actually doing it, but it just doesn't
make my priority list usually. Still, I wanted to bring it up, perhaps
there's someone just waiting for an idea like that. ;-)
Robert Kaiser
John J. Barton
> On Wed, Jul 22, 2009 at 12:22 AM, Zack Weinberg<zwei...@mozilla.com> wrote:
>> I've said this before and it's not really any more than what John said,
>> but: I know a bunch of people who have *given up* on reporting bugs to
>> Mozilla because their expectation is that no matter how much effort
>> they put into it, their report will be silently ignored. These are not
>> the great unwashed, either; these are people (mostly web developers) who
>> *could* be sending us valuable feedback if we demonstrated that we
>> wanted it.
I second Zack's observation.
>
> Surely if they cc: you, you can make sure that it's not silently
> ignored? It doesn't solve the general problem, but it seems like
> you're talking about specific high-value people with whom you have a
> relationship, so it seems like they could use that. (I get people to
> cc: me on bugs, because I know they're going to ask me about their
> bugs, and I'd rather have the answer when they do.)
I have begun CC-ing developers on bugs only very recently. There are
many practical barriers to making this generally useful. Most of all I
don't often understand where the bug belongs and who there would
understand it.
> But you've been working on Mozilla for a while now, and know your way
> around: how have you changed to be more responsive to bug reporters in
> the areas you work on? what's worked and what hasn't? how do you
> indicate to people that their report was useful (or how it could be
> more useful, if it wasn't actually especially useful the first time)?
I'll give the other side of this question:
I can usually tell within 24 hours if my bug report will ever get
results. I usually get one of three results:
"silence": nothing will ever happen on this report.
"you're an idiot, you did not do XYZ": if I understand XYZ, I try to
provide it, knowing that the changes are maybe 1/5 of a success; else I
know the report will vanish. Generally I think the "you're an idiot"
part could be elided as obvious and it would make me feel better.
"joe, does this look like bax?": I put a much energy as I can into
these reports since once a developer make a cogent comment the
probability of resolution is very high.
I'll also say that my personal experience has radically changed from my
first reports (almost all silence) to today (almost all positive).
>
> Do your web-developer friends report bugs to other browser projects
> and get better results?
I've reported many bugs to eclipse. Bizarrely different: total silence
for about a year, followed by some activity on almost all of them
eventually.
I deal with Firebug bugs. Based on my experience as a reporter, I almost
never close bugs as INVALID, I try to always say something on dupes, I
try to avoid being snippy (not 100% effective ;-). Bug fixes are the
great prize for bug reporters so I always invite reporters to verify
bugs when the release with the fix goes out. Of course our software is
a tiny fraction of mozilla's.
>
> (TBH, I don't know of many bugs that are silently ignored, but many
I think most reporters of bugs would get a good laugh out of your
understatement.
> don't get fixed right away. If they're clear and have an example,
> it's much more common that there is initial commentary and then the
> bug goes idle until progress is made on fixing it.
I think this is the critical area and central point where everyone's
interests align. Describing bugs in text to the level of detail required
for an other person to reproduce is difficult; lots of people don't have
the skill or understanding of how to do it. Providing a test case that
reproduces the bug is an even higher bar. But in the end a detailed
scheme and test case is almost always the only way to get a fix.
Whatever technology we can create to encourage reports with these
ingredients will pay off for everyone.
yes, I know this now has nothing to do with the subject line, but I hope
Gerv is reading.
jjb
Zack Weinberg
I don't know. My own experience with reporting bugs to other large
free software projects that I am not much involved with (notably Debian
and GNOME) matches John Barton's in outline: about 50% of bugs either
get no response at all or get an immediate blow-off response, and are
never fixed. The other 50% get a constructive reply within a few days
and do eventually get fixed.
When I worked on GCC I had the impression that we were somewhat better
at replying to all bug reports, but I also had the impression that that
was because there was one guy who liked mocking people who submitted
unclear bug reports, so it may have been that there was more "immediate
blow-off", less "no response at all", and about the same rate of
constructive replies. :-/
I don't have as many data points for other people trying to report bugs
to other projects as I do for other people trying to report bugs to
Mozilla, but for them, the track record is near-100% no response at all.
It seems to me that writing bug reports that attract developer
attention may be a trainable skill, and my solution would be to hire
people whose entire job is to trawl through the UNCONFIRMED bugs and
clean them up to the point where they will attract attention. There
should be enough of these people that all bugs do get a reply within
48 hours or so, and they should be trained never to blow people off, no
matter how vague or impossible their problem is.
zw
Dao
> Could you mail me
> some bug examples that were just silently ignored? Might be something
> strange going on with a certain component or type of bug.
There are currently 7765 unconfirmed bugs in Firefox:General...
Zack Weinberg
>
> Surely if they cc: you, you can make sure that it's not silently
> ignored? It doesn't solve the general problem, but it seems like
> you're talking about specific high-value people with whom you have a
> relationship, so it seems like they could use that. (I get people to
> cc: me on bugs, because I know they're going to ask me about their
> bugs, and I'd rather have the answer when they do.)
I do do that -- more accurately, they tell me about bugs via another
channel, and I file them -- but it doesn't scale. :)
Also, the odds that a bug *I* file does not get ignored is only about
two out of three. (See below.)
> But you've been working on Mozilla for a while now, and know your way
> around: how have you changed to be more responsive to bug reporters in
> the areas you work on? what's worked and what hasn't? how do you
> indicate to people that their report was useful (or how it could be
> more useful, if it wasn't actually especially useful the first time)?
I'm far enough in the back-end of the rendering engine that I basically
never see "raw" bug reports. So I can't really answer this question.
(I probably should be putting some of my own time into trawling
components I know about for unconfirmeds, but I haven't been.)
> Do your web-developer friends report bugs to other browser projects
> and get better results?
No, they've given up on reporting bugs in general.
From their perspective, it doesn't really *matter* whether the bug gets
fixed in some future release of Browser X or not; they have to work
around it regardless, because they still have to support as far back as
IE6, Firefox 2, and Safari 2. Time spent reporting the bug is time
taken away from hacking up a workaround, and when their expectation is
that the bug report will be ignored, why bother?
One person has said that it would be worth it to her if she could spend
less than five minutes filing the bug, and she could be certain of
getting a constructive response. As is, a report filed by me with 2/3
chance of response takes ten to twenty minutes of her time and an hour
or two of mine (mostly reducing the test case).
No, I don't think "less than five minutes" is an unrealistic target,
with mechanical and QA staff support. I'll start another thread for the
concrete idea I have there.
> (TBH, I don't know of many bugs that are silently ignored, but many
> don't get fixed right away. If they're clear and have an example,
> it's much more common that there is initial commentary and then the
> bug goes idle until progress is made on fixing it. Could you mail me
> some bug examples that were just silently ignored? Might be something
> strange going on with a certain component or type of bug.)
It's strongly component dependent, in my experience: some components
just never get looked at for new bugs , and when I complain on IRC I get
told "why the heck did you file it here? That belongs over there!"
Perhaps this bites me more than casual bug filers because I try to
pick a component that makes sense rather than dumping in
Firefox:General or Core:General ... but I wouldn't be surprised if
casual bug filers feel like they have to at least *try* to pick the
right one.
Bugs I have filed that have gotten no attention whatsoever include
431394, 451591, 455980, 456312, 460146, 462452, 477358, and 488337.
(I expect someone will now tell me that at least half of them are in
the wrong component.) Also, 503924 is a good example of a bug that was
initially filed in what *seemed* like the correct place (Embedding:Gtk
Widget) but is only getting attention now that bsmedberg refiled it
under Widget:Gtk.
zw
Daniel Veditz
If you look at the dependency tree in the "buglist" view you can then
show the whiteboard column. Of course then you lose the tree-ness of it.
L. David Baron
As far as bugs from Web developers go, I think it would help this a
lot if "Core" were more prominent (rather than completely hidden
under "Other Products") in the default version of
https://bugzilla.mozilla.org/enter_bug.cgi . (Remember that many of
us may have changed the preference so we see the full list of
components, but that's not the default.) This would make their bugs
a lot less likely to sit untouched and unconfirmed in
Firefox:General.
Dare I suggest Core even go first in the chooser (with a good
description)? Of FIXED bugs reported in the past year, 7490 were in
Core, 5667 in mozilla.org, 2131 in Firefox, 1885 in Websites, 1551
in addons.mozilla.org, 1156 in Mozilla Localizations, and 1104 in
Toolkit, with other products under 1000.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Mike Beltzner
> There are currently 7765 unconfirmed bugs in Firefox:General...
Which is something that the QA group is trying to correct, FWIW.
Tomcat and others are building a triage group to help us cut through
that list.
I think it's universally known that Bugzilla requires users to
understand not only how our product is built, but also to understand
what is important to us at any time and how we're using flags to
express that. There are some simple things we can do to immediately
make things better (improving the "basic" bug filing form, adding
links to a wiki page that explains what the flags mean and how to use
them) and there are a pile of things we can do to make the entire
Bugzilla experience better, as well as the entire engagement for
people who want to help us understand and tackle problems together.
It's easy for the scope to creep here.
As I've said before, if we're to make things better here, the project
needs a clear owner (gerv has expressed interest) and plan (gerv has
said he was going to take the input and deliver one) and a proper
place for interested parties to participate (I hope all people on this
thread will join!) that isn't dev.planning, as it makes this newsgroup
noisy in ways that I think ultimately will be counterproductive (we
need to keep this group low-volume so it can be globally subscribed by
those who want to know what new plans and changes to our development
process are coming).
cheers,
mike
Daniel Veditz
> And perhaps Gerv will succeed. But most likely these incremental fixes
> will dominate. There are three majors groups of users for BMO: managers,
> developers, and reporters (users). While I understand that managers have
> a difficult job and need the bulk of the support, the incremental
> improvements for them are arcane and focused on a narrow part of the bug
> lifecycle. They build up and now dominate the UI. Almost nothing goes
> towards helping reporters know: Did my contribution make a difference?
How so? It seems if there's any activity at all, especially if there's a
patch and the bug gets resolved FIXED, that the contribution has
obviously made a difference. If the bug is ignored and there's no
activity then adding new fields that sit there unchanged doesn't improve
the situation.
One question I do see reporters ask often is "does the latest/will the
next 3.0.x contain this patch?" and that I agree is often unclear.
Better branch tracking is definitely part of what I'd like to get out of
Gerv's latest BMO planning effort. Even then, though, it's not going to
be all that clear that "fixed on the 1.9.1 branch" means "Firefox 3.5.x"
(or Thunderbird 3, or SeaMonkey 2), but as long as we have a "Core"
serving multiple products there's not a whole lot bugzilla can do.
-Dan
Boris Zbarsky
> It's strongly component dependent, in my experience: some components
> just never get looked at for new bugs
One other thing to note. I'd watch a lot more components for new bugs
if I had a way to do that. That's why I keep asking for a way to get
mail when a bug is moved into a given component (via component change or
being filed).
That said, even if I get notifications it's not clear what I'd do with
it. I can probably fix some. I can cc people on others if I know
they're in their area of expertise. I can add student-project to some
(assuming that's not just a black hole). But we have no setup for
tracking "this should be fixed but isn't a blocker and we'd like to fix
it sooner than these other things" (e.g. pretty much any bug that we're
minusing for 1.9.2 today!).
-Boris
John J. Barton
> On Wednesday 2009-07-22 19:23 +0200, Dao wrote:
>> On 22.07.2009 14:54, Mike Shaver wrote:
>>> Could you mail me
>>> some bug examples that were just silently ignored? Might be something
>>> strange going on with a certain component or type of bug.
>> There are currently 7765 unconfirmed bugs in Firefox:General...
>
> As far as bugs from Web developers go, I think it would help this a
> lot if "Core" were more prominent (rather than completely hidden
> under "Other Products") in the default version of
> https://bugzilla.mozilla.org/enter_bug.cgi .
Perhaps the top branch point is complete wrong. The ultimate goal is to
get a fix; to get a fix one needs a clear report. Maybe the top branch
should be
1) Do you have step by step instructions and a test case?
2) Else we try to help guide you to create those.
Dispatching bug reports with clear instructions is easy and perhaps best
done by someone on the team, rather than having the web dev guess wrong.
jjb
Boris Zbarsky
> That said, even if I get notifications it's not clear what I'd do with
> it.
And even more to the point, we never have developers with nothing to do.
So what's to make sure that anyone ever works on a bug? The
mechanisms in place now are:
1) Blocker flags (once minused, the bug is forgotten).
2) Tracking bugs (e.g. compliance to a test suite).
3) Developers just deciding to work on the bug for whatever reason.
Front-end has been doing "polish" bugs recently; perhaps we need
something similar in Core....
-Boris
L. David Baron
Whenever I go through a round of blocker-flag triage I end up with a
long list (maybe 10%-20% of the number triaged) of bugs that I'd
really like to work on, but weren't (all) bad enough to call
blockers. [1]
I think we need to get better about going through old bugs. This
includes the ones that aren't getting nominated, since some people
know our process better than others. But it's competing for
priority with a lot of other things that we also need to keep doing
(or, in some cases, get better about doing more).
-David
[1] For example, while triaging blocking1.9.2? and wanted1.9.2? over
the past few days (the bugs aren't marked yet since it was in a
spreadsheet, but probably will be later today), the list I ended up
with was
https://bugzilla.mozilla.org/buglist.cgi?bug_id=376690,379272,391238,399994,426082,467914,468436,478321,488581,490216,492564,502553,497519,498254,502447
which includes both blockers and non-blockers
John J. Barton
> Boris Zbarsky wrote:
>> That said, even if I get notifications it's not clear what I'd do with
>> it.
>
> And even more to the point, we never have developers with nothing to do.
> So what's to make sure that anyone ever works on a bug? The mechanisms
> in place now are:
>
> 1) Blocker flags (once minused, the bug is forgotten).
> 2) Tracking bugs (e.g. compliance to a test suite).
> 3) Developers just deciding to work on the bug for whatever reason.
jjb
Boris Zbarsky
>> And even more to the point, we never have developers with nothing to
>> do. So what's to make sure that anyone ever works on a bug? The
>> mechanisms in place now are:
>>
>> 1) Blocker flags (once minused, the bug is forgotten).
>> 2) Tracking bugs (e.g. compliance to a test suite).
>> 3) Developers just deciding to work on the bug for whatever reason.
> 4) Reporters who ping the bug, hopefully adding more info.
While that's really useful, as far as getting resources allocated to the
bug goes it at best increases likelihood of #3 above. Which is nothing
to sneer at, since #1 and #2 are so limited. I'm just saying we need a
better mechanism here.
-Boris
Robert O'Callahan
> I've said this before and it's not really any more than what John said,
> but: I know a bunch of people who have *given up* on reporting bugs to
> Mozilla because their expectation is that no matter how much effort
> they put into it, their report will be silently ignored. These are not
> the great unwashed, either; these are people (mostly web developers) who
> *could* be sending us valuable feedback if we demonstrated that we
> wanted it.
Of course, there are a lot of bug reporters who we DO want to give up
because they don't add value, just consume the energy of Mozilla
contributors. The trick is recognizing the good ones among the bad ones.
"CC my Mozilla contributor friend on the bug" is a crude social-network
approach to this problem. Maybe someone can come up with a better one.
Rob
Robert O'Callahan
> One person has said that it would be worth it to her if she could spend
> less than five minutes filing the bug, and she could be certain of
> getting a constructive response.
I don't think we can ever guarantee a constructive response. Our reality
is finite developer and QA resources, and for that reason alone a lot of
bugs just aren't going to get fixed in the short term. Furthermore I
think "Web developer polish" is less important than performance, feature
work, and architectural changes like compositor that can fix clusters of
big bugs, and we should not increase our investment in this area.
I care more about regressions, and bugs in new features that we haven't
shipped yet. I would like to find ways to get more people to report
those bugs. I don't think we need to empower more people to report bugs
less important than those.
Rob
Dennis Melentyev
Sad thing is: I do understand your position as a developer, but as a
project manager - can't agree (unless I misread your point here, sorry
if it is the case).
An average _user_ (millions in your case!!!) does not care about arch
perfection or queue processing milliseconds. They need relatively fast,
awesome and easy to use tool.
Your statement above would rather result in migration to Google chorme,
because they just give user what they want. Regardless of actual
[programmer-wise] efficiency of the tool, standard compliance, resource
shortage or other really important things.
In fact this affects most of OpenSource projects - cool internals, low
usability. Same also apply, unfortunately, to TB, Lightning and Bugzilla
(not using other Mozilla projects, have no clues about them).
The real art of PM work is balancing project and user needs. FF is in
much better shape than other mentioned projects, but still give the
source of frustration and sadness when simple [user-wise] things take
years to implement.
Ask your marketing people on this. I do believe it is possible to make a
temporary freeze in internals and polish usability, then return to
complex refactoring tasks. Or find a way to split the team into
"polishers" and "futurists" working on different branches. IMO project
will highly benefit from this.
PS. If you'd like to see me continuing the conversation, please CC me,
since I just briefly glancing over this thread and could miss the answer.
PPS. Sorry for adding more burden to this thread with my 0.02UAH.
/dennis
Robert Kaiser
> Your statement above would rather result in migration to Google chorme,
> because they just give user what they want. Regardless of actual
> [programmer-wise] efficiency of the tool, standard compliance, resource
> shortage or other really important things.
On how many bug reports (which surely are openly queryable the same way
or you couldn't make the assumption above) do people get a good response
in Google Chrome which you state that people will go to if they don't
get useful replies in Bugzilla with us?
Robert Kaiser
Robert O'Callahan
> On 07/23/2009 12:46 AM, Robert O'Callahan wrote:
>> I don't think we can ever guarantee a constructive response. Our reality
>> is finite developer and QA resources, and for that reason alone a lot of
>> bugs just aren't going to get fixed in the short term. Furthermore I
>> think "Web developer polish" is less important than performance, feature
>> work, and architectural changes like compositor that can fix clusters of
>> big bugs, and we should not increase our investment in this area.
>>
>> I care more about regressions, and bugs in new features that we haven't
>> shipped yet. I would like to find ways to get more people to report
>> those bugs. I don't think we need to empower more people to report bugs
>> less important than those.
>
> project manager - can't agree (unless I misread your point here, sorry
> if it is the case).
>
> An average _user_ (millions in your case!!!) does not care about arch
> perfection or queue processing milliseconds. They need relatively fast,
> awesome and easy to use tool.
The average user also does not care about the kind of bugs that Web
developers report.
Neither do the Google Chrome developers; Google invests almost nothing
in fixing generic Webkit standards-compliance bugs.
Rob
Dennis Melentyev
Well, we are going more and more off-topic.
They do not have such a long history and rumors. Also project backed by
Google definitely sounds more "solid", regardless it is just a buzzword
(as was Mozilla/Netscape when there were not other concurrents to MS)
and still same opensource (at least chromium part,
http://code.google.com/p/chromium/issues/list).
So, that's not [yet] aplicable to them. From marketing point of view
that sounds much better for end-user. And this makes it more interesting
product on the market.
As of your question, there are 6.5K open issues, with oldest dated
September 2008. Many of them still Unco or untriaged. So their shape is
not significantly better than ours. But promoted better.
It is not about comparison of browsers. It's more about marketing and
people feelings, improving and leading the product market and "sales".
Aren't FF people trying to get most of the browser' market? So
commercial rules apply to this opensource free project.
If I am wrong in the previous sentence, then I'd better just shut up,
because in non-commercial world, this really has little meaning over
technical perfection (no irony, absolutely serious and supportive). It
is not bad, it's just a different paradigm.
/dennis
Dennis Melentyev
from user perspective (Flash and JavaScript rendering tenth of tabs
worth browsed almost dead on modern PC kind of things).
> Neither do the Google Chrome developers; Google invests almost nothing
> in fixing generic Webkit standards-compliance bugs.
They have better "excuses". And thus looks more interesting with this
regard.
/dennis
Mike Beltzner
This thread is now officially OFF-TOPIC for mozilla.dev.planning.
Please take the discussion elsewhere, like mozilla.dev.governance or
mozilla.dev.platform.
cheers,
your friendly dev-planning moderator
Robert Kaiser
> It is not about comparison of browsers. It's more about marketing and
> people feelings, improving and leading the product market and "sales".
You're right, it's not about browser comparisons. It's not about
marketing either though, it's about responsiveness to bug reports, the
whole thread is about Bugzilla topics. I doubt you can count Bugzilla
activities of any kind as marketing, as the vast majority of normal
users don't even know that Bugzilla exists and for normal feedback, we
don't point to Bugzilla as it's the wrong channel for that.
All the other things you spoke of in comparison belong on the marketing
list and not even here in planning and are in no way connected with the
Bugzilla topic this thread is about.
What counts is that it's just hard to get all bug reports treated, esp.
as there are a good number that are hard to reproduce, badly reported or
otherwise not too interesting to handle - and esp. in a volunteer
community (which most of Mozilla is) the only thing that really counts
is things being interesting for contributors of any kind to handle (and
actually, I believe it's mostly the same in companies with the
difference that it's more hidden from the public).
Robert Kaiser