On Jun 12, 4:49 am, Axel Hecht <l...@mozilla.com> wrote:
> My pet would be a truly-JSON API to get data out of bugzilla.
Bugzilla 3.6 will have a JSON-RPC API that duplicates the XML-RPC API.
> we'd really want something like > "number of open bugs per component in l10n" or "number of open blockers > of bugs with an alias matching 'fx35-l10n-.*'"
You could currently get that data using the CSV format of the tabular reports, if you want.
> A smaller thing would be to support filling in the alias via the URL.
This should be possible. If it's not, it's a bug.
> I guess that finding out a better way to have "fixed here, but needs > fixing somewhere else" would be cool, and support for that in queries.
Your current bmo customizations include a "Fixed In" field that isn't being used.
> Better caching? Not sure, but I think we reload a lot these days.
It's a bit tricky to cache bug pages, and impossible to cache bug searches, and I'm not quite sure what else we would cache that would have a performance impact.
On Jun 12, 9:26 am, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> * Remove the Hardware and OS fields:
Agree. Usually this data is just useful in the description only. I never have to search or chart against it.
> * Remove the severity field
Disagree. The Bugzilla Project definitely uses this field.
> * Combine Status and Resolution
Unfortunately, RESOLVED FIXED and VERIFIED FIXED mean different things. For some projects, RESOLVED WONTFIX and VERIFIED WONTFIX also mean different things. I think there is something to be gained in workflow for most projects (even if not for Mozilla) from having separate fields.
> * Track FIXEDness per-branch
> This is by far the hardest and most pie-in-the-sky request, but one which I > think would be most valuable.
You do already have a "Fixed In" field that you can use, if you want. It's a per-product multi-select field that my company added to bmo at MoCo's request.
On Jun 12, 3:59 pm, Alex Faaborg <faab...@mozilla.com> wrote:
> For the autocomplete, it would be even better if we searched against > full name and all associated email addresses on an account,
We do this already, FWIW.
Autocomplete actually isn't even that hard. We just have to find a good XML-RPC or JSON-RPC client in JavaScript that we can include in Bugzilla that has a license compatible with the MPL, so that it can get the data it requires.
> and started by ranking results
I'd be fine with this as long as the it only sorted people to the top of they were *significantly* active, and left everybody else in alphabetical order.
> And from that ranking start to bring in some quicksilver / Ed Lee / > adaptive learning awesomesauce.
Sounds cool, but just remember that Bugzilla is not a central, hosted application where we have total control over the hardware and scaling (like most Web 2.0 sites), but a shipping app that runs on single servers. So if we can do this client-side, we're good, but if it puts too much load on the server-side, it couldn't be supported.
> 1 - User Profile Pages.
bugzilla.gnome.org has describeuser.cgi and we could port something like that over, upstream. I've often wanted this information in Bugzilla, myself.
> 2 - API for accessing the same type of activity that is exposed > through bugmail.
We actually have a Bug.get_history XML-RPC API method in Bugzilla 3.4 that will let you do this, if you want. It could also be possible to add an Atom feed, but the data wouldn't be as structured.
>> This is by far the hardest and most pie-in-the-sky request, but one >> which I >> think would be most valuable.
> You do already have a "Fixed In" field that you can use, if you > want. It's a per-product multi-select field that my company added to > bmo at MoCo's request.
"Fixed In" isn't even close to what we want, unfortunately. This has been hashed out over and over, so I won't go into detail again, but we basically need to know the status of bugs across branches, especially status/resolution. Right now we do that with a mix of keywords and flags, which sucks in so many ways.
On Jun 12, 5:21 pm, Samuel Sidler <s...@mozilla.com> wrote:
> "Fixed In" isn't even close to what we want, unfortunately. This has > been hashed out over and over, so I won't go into detail again, but we > basically need to know the status of bugs across branches, especially > status/resolution. Right now we do that with a mix of keywords and > flags, which sucks in so many ways.
Yeah, I knew all that, but two people on the thread specifically said, "I want a way to see what branches a bug has been FIXED in", and that does exist.
> > Gervase Markham wrote: > >> Over the next few months, I will be working on improving > >> bugzilla.mozilla.org to better meet the needs of the Mozilla > >> development community.[0] I am therefore gathering 'requirements' - > >> that is to say, > > ... > >> Please say what the change you are requesting is, and why making it > >> would improve your life. References to previous discussions and bug > >> numbers would help.
> > Remove all of the relative version number aspects of bugzilla, eg > > 'trunk'. Since some bugs live longer than the binding of 'trunk' to > > 1.9.1, the word is ambiguous and you always have to double check it.
> I'd just remove the version field, it mostly isn't used for anything useful.
On Jun 12, 12:26 pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> > Please say what the change you are requesting is, and why making it > > would improve your life. References to previous discussions and bug > > numbers would help.
> * Remove the Hardware and OS fields:
> The Hardware/OS fields are constantly misunderstood or misused: bug-filers > don't know whether they mean "I'm using windows" or "this bug is > windows-specific", and this means that the data is inconsistent, which makes > searching based on the OS/Hardware meaningless. Asking bug filers to fill in > metadata that isn't actually required is an unnecessary burden.
> * Remove the severity field
> The "blocker" and "enhancement" severities actually mean something to us > currently, but everything inbetween is basically "a bug of some sort" > without much actionable difference. I think we should instead have a > "blocking trunk" flag which we use to mark bugs which should close the > mozilla-central tree, and an enhancement keyword to mark enhancement bugs.
> * Combine Status and Resolution
> Status and Resolution always come in pairs... it seems silly to have two > fields where one would do quite well.
> * Track FIXEDness per-branch
> This is by far the hardest and most pie-in-the-sky request, but one which I > think would be most valuable.
> --BDS
This is probably the third discussion that has been had about changes to BMO and yet still people are suggesting selfish, Firefox-centric changes. There are a number of projects using BMO that are not related to Firefox or the Firefox workflow.
The version field is definitely useful when tracking down where a bug crept in.
The OS/Platform fields could be useful in keeping track of OS-specific bugs if they weren't automatically set to whatever OS the user reporting the bug was on. Instead of removing them, they should default to All/All, so that they have to be purposely changed. Maybe even exclude them from the reporting form and only allow changes after the bug has been filed.
It is also very useful to have the severity field, because the documentation has specific descriptions for what each one means. If anything should go, it's the priority field, as those are just arbitrary numbers.
I'm not so sure that it would make sense to combine resolution and status, either. Especially because of the difference between RESOLVED and VERIFIED, which can each be use with any of the different statuses.
As for tracking FIXEDness, I think that's actually the most logical of the bunch. Assuming, of course, that it'd be customizable per product/ component.
I've got some suggestions of my own, but I had to get this comment in here before I organized them.
Well, yes. Changesets should be marked by bugzilla numbers, changeset-deltas per build should lead to bugzilla numbers per build, and bugs should record the builds that include the changesets that support the FIXED claim. There should be an entry in the bug following FIXED linking the build in red/orange/green according to the unit tests. If I want to verify the fix, I just click.
> This is probably the third discussion that has been had about changes > to BMO and yet still people are suggesting selfish, Firefox-centric > changes. There are a number of projects using BMO that are not related > to Firefox or the Firefox workflow.
You may take most of the suggestions here as suggestions for what we should do in Core/Toolkit/Firefox... what happens in other products is probably best left to the module owners of those products. That there are other products hosted on bugzilla.mozilla.org shouldn't stop us from improving the primary problem space.
> The version field is definitely useful when tracking down where a bug > crept in.
Except we don't use it that way: the field is normally set to the version a bug was fixed. This is similar for most of the other metadata: it could have multiple meanings, and getting everyone to agree on a single meaning is usually not worth the cost of maintaining the metadata.
> The OS/Platform fields could be useful in keeping track of OS-specific > bugs if they weren't automatically set to whatever OS the user > reporting the bug was on. Instead of removing them, they should > default to All/All, so that they have to be purposely changed. Maybe > even exclude them from the reporting form and only allow changes after > the bug has been filed.
Yes, there could be value if the field were kept correctly. However, the cost of maintaining the field, confusing new bug filers, confusing the bug query forms, etc, is much higher than the potential benefits. We need to think in cost/benefit terms, not simply whether some field might have some value.
> It is also very useful to have the severity field, because the > documentation has specific descriptions for what each one means. If > anything should go, it's the priority field, as those are just > arbitrary numbers.
Sure, each value has meaning. But does that meaning cause us to actually treat the bug differently? I think that other than "blocker", which can cause the tree to close, in most cases the other values are basically all treated the same, and it is mainly a source of argument for people who think the field somehow affects our decision-making.
GPHemsley <gphems...@gmail.com> wrote: > This is probably the third discussion that has been had about changes > to BMO and yet still people are suggesting selfish, Firefox-centric > changes. There are a number of projects using BMO that are not related > to Firefox or the Firefox workflow.
Would it be crazy to propose being able to vary the presence and default state of all the fields on a per-product basis?
> > This is probably the third discussion that has been had about changes > > to BMO and yet still people are suggesting selfish, Firefox-centric > > changes. There are a number of projects using BMO that are not related > > to Firefox or the Firefox workflow.
> You may take most of the suggestions here as suggestions for what we should > do in Core/Toolkit/Firefox... what happens in other products is probably > best left to the module owners of those products. That there are other > products hosted on bugzilla.mozilla.org shouldn't stop us from improving the > primary problem space.
> > The version field is definitely useful when tracking down where a bug > > crept in.
> Except we don't use it that way: the field is normally set to the version a > bug was fixed. This is similar for most of the other metadata: it could have > multiple meanings, and getting everyone to agree on a single meaning is > usually not worth the cost of maintaining the metadata.
> > The OS/Platform fields could be useful in keeping track of OS-specific > > bugs if they weren't automatically set to whatever OS the user > > reporting the bug was on. Instead of removing them, they should > > default to All/All, so that they have to be purposely changed. Maybe > > even exclude them from the reporting form and only allow changes after > > the bug has been filed.
> Yes, there could be value if the field were kept correctly. However, the > cost of maintaining the field, confusing new bug filers, confusing the bug > query forms, etc, is much higher than the potential benefits. We need to > think in cost/benefit terms, not simply whether some field might have some > value.
> > It is also very useful to have the severity field, because the > > documentation has specific descriptions for what each one means. If > > anything should go, it's the priority field, as those are just > > arbitrary numbers.
> Sure, each value has meaning. But does that meaning cause us to actually > treat the bug differently? I think that other than "blocker", which can > cause the tree to close, in most cases the other values are basically all > treated the same, and it is mainly a source of argument for people who think > the field somehow affects our decision-making.
> --BDS
If all the suggestions you make could be implemented on a product/ component-specific basis, then fine. But the suggestions are not often made within that context, IMO. I just want to make sure that no one forgets about the little guys (in my case, Bespin).
On 6/12/2009 9:26 AM, Benjamin Smedberg wrote [in part]:
> On 6/12/09 4:35 AM, Gervase Markham wrote:
>> Please say what the change you are requesting is, and why making it >> would improve your life. References to previous discussions and bug >> numbers would help.
The following comments are from the point of view of a user of Mozilla products, not a developer.
> * Remove the Hardware and OS fields:
> The Hardware/OS fields are constantly misunderstood or misused: bug-filers > don't know whether they mean "I'm using windows" or "this bug is > windows-specific", and this means that the data is inconsistent, which makes > searching based on the OS/Hardware meaningless. Asking bug filers to fill in > metadata that isn't actually required is an unnecessary burden.
If one bug says WinXP and another says Windows XP, I can't do a simple search and find all the bugs for the same operating system. Having fields with preset values for OS solves this problem. A similar case can be made for hardware.
> * Remove the severity field
> The "blocker" and "enhancement" severities actually mean something to us > currently, but everything inbetween is basically "a bug of some sort" > without much actionable difference. I think we should instead have a > "blocking trunk" flag which we use to mark bugs which should close the > mozilla-central tree, and an enhancement keyword to mark enhancement bugs.
Severities are quite well defined and should remain.
> * Combine Status and Resolution
> Status and Resolution always come in pairs... it seems silly to have two > fields where one would do quite well.
One gives the status (Unconfirmed, Resolved, Closed, etc). The other gives why the bug has that status (Fixed, Wontfix, etc). These should be kept so that they can be readily seen in a one-line query result without having to open the bug report.
Go to Mozdev at <http://www.mozdev.org/> for quick access to extensions for Firefox, Thunderbird, SeaMonkey, and other Mozilla-related applications. You can access Mozdev much more quickly than you can Mozilla Add-Ons.
> Except we don't use it that way: the field is normally set to the version a > bug was fixed.
That's the job of the target milestone field, not the version field. We (the Bugzilla project) also use the Version field to track when a bug appeared. This helps us to narrow the regression range. We maintain 4 branches; this information is really important.
> cost of maintaining the field, confusing new bug filers, confusing the bug > query forms, etc, is much higher than the potential benefits.
There is no cost if projects which don't need these fields ignore them. There is also no confusion for query forms as long as you don't include these fields in your queries.
> Sure, each value has meaning. But does that meaning cause us to actually > treat the bug differently? I think that other than "blocker", which can > cause the tree to close, in most cases the other values are basically all > treated the same, and it is mainly a source of argument for people who think > the field somehow affects our decision-making.
We definitely treat bugs differently based on their severity, both as reviewers and as developers. The priority I give to a bug marked as major or critical is completely different from a bug marked as normal or lower.
> That's the job of the target milestone field, not the version field. We (the > Bugzilla project) also use the Version field to track when a bug appeared. > This helps us to narrow the regression range. We maintain 4 branches; this > information is really important.
What do you do if a bug appears in multiple branches, but not all of them? Similarly with them being fixed? Our branches aren't always strictly ordered in time (periodic merges between tracemonkey and mozilla-central are one example), so we can get almost arbitrary combinations of these characteristics on different branches.
If "target milestone" is what we are Supposed To Use to indicate when a bug was fixed, why isn't it called "fixed milestone"? That would certainly have made its proper use clearer to me! (b.m.o's explanatory link for "target milestone" points at a document dated Jan 1, 2009 that talks about the path to Firefox 2, so we can probably improve things a bit by explaining it on fields.html and linking there.)
>> Does the target milestone on there indicate that it's already fixed in >> the bugzilla 3.6 branch?
> Status is ASSIGNED. So no, it's not fixed yet. This bug is planned to be > fixed in 3.6 before it's released (that's why it's named "target" > milestone).
But earlier:
>> Except we don't use it that way: the field is normally set to the version >> a bug was fixed.
> That's the job of the target milestone field, not the version field.
So now I'm confused again -- if the target milestone is used to indicate the version in which it was fixed, as well as the version in which it was planned to be fixed, how would we indicate, f.e. "this was fixed in Firefox 3.5.6, and we plan to also fix it in Firefox 3.0.14"? It's not at all an uncommon situation for us, since basically every fix that goes into an "older" branch was in a "newer" branch first.
Not that you guys need to use bugzilla the same way we do, of course, but if you're going to argue that we're using it wrong, it would be good to know how using it right might work out better.
On Fri, Jun 12, 2009 at 11:23 PM, GPHemsley<gphems...@gmail.com> wrote: > This is probably the third discussion that has been had about changes > to BMO and yet still people are suggesting selfish, Firefox-centric > changes.
Sure, and you're requesting selfish, Bespin-centric things too. That's the purpose of the requirements gathering exercise here: figure out what everyone wants, and *then* we can figure out how to reconcile it.
TBH, I don't know why Firefox and Bespin need or want to share a common bugzilla instance -- you're going to have different platforms of interest (you probably care more about "Browser" than "Hardware" for narrowing down bugs, for example) and it doesn't seem like we get much value from being in the same database. If we weren't, then Bespin folk could also have much wider administrative access to their instance, making it easier for them to tune configuration and privileges themselves without needing to worry about Firefox's security-bug policies and access control.
Gervase Markham wrote: > Please say what the change you are requesting is, and why making it > would improve your life. References to previous discussions and bug > numbers would help.
Bug 218917 would really help me, as it would probably also change what is displayed as the "who" of flags settings. We currently have a good number of people who are using a bugzi...@foo.tld Bugzilla account, and it's very unhelpful to see "bugzilla: review+" on an attachment.
A faster, more lightweight solution to that may be to have a tooltip with the full name/mail appearing when mousing over such a shortened name (usually with flag settings).
A helpful function might also be a possibility to directly forward flags from an attachment you're obsoleting to the new one you're adding, which would keep the setter of the flag intact in some way. The use-case for this is addressing review comments/nits on a patch that already has reviews, and e.g. still needs super-review or just needed some small tweak before being checked in and the user requests checkin-needed on it.
> What do you do if a bug appears in multiple branches, but not all of > them? Similarly with them being fixed?
It depends on the severity of the bug: - if a bug is present on all supported branches and trunk, then the target milestone points to the oldest affected branch which we plan to fix. It may be the oldest supported branch or not, depending on how severe the bug is. - if a bug is only present on some branches but not on the trunk, then we either mark it as a duplicate of the bug which fixed the problem in newer branches/trunk if we think the bug is not severe enough to be backported, or we mark it as WFM if we don't know which bug fixed the problem on trunk but not on older branches, or we decide to fix it on older branches and we set the target milestone to the oldest branch we plan to fix with a comment in the status whiteboard saying [doesn't affect 3.4 or newer]. - A big difference between the Bugzilla project and Firefox is that we land all patches at once for all branches. We never land a patch on trunk if backports are not ready and reviewed. So we don't have this "FIXED on trunk but not on branches" problem.
> If "target milestone" is what we are Supposed To Use to indicate when > a bug was fixed, why isn't it called "fixed milestone"?
What is important is the combination of the target milestone + the bug status. If the bug is still open, then this means that we *plan* to fix it for the version mentioned in the target milestone. if we miss the release, then the bug is retargetted. If the bug is FIXED, then this means that the bug has been fixed in the release mentioned by the target milestone.
> So now I'm confused again -- if the target milestone is used to > indicate the version in which it was fixed, as well as the version in > which it was planned to be fixed, how would we indicate, f.e. "this > was fixed in Firefox 3.5.6, and we plan to also fix it in Firefox > 3.0.14"? It's not at all an uncommon situation for us, since
We don't have this problem because we land all backports at the same time as patches on trunk, so all branches are fixed at the same time. I agree this is a problem for you.
David E. Ross wrote: > If one bug says WinXP and another says Windows XP, I can't do a simple > search and find all the bugs for the same operating system. Having > fields with preset values for OS solves this problem. A similar case > can be made for hardware.
Most bugs are either immediately seen to be tied to one system (an OS X address book is obviously OS X-specific code), or are cross-platform. The setup of the field, however, tends to default to assuming platform-specific bugs, which is wrong most of the time.
With respect to hardware, I don't see how anyone outside of NSPR or XPCOM (for the reflection bit) has hardware-specific bugs.
The original intent of target milestone was to provide a planning and scheduling tool.
The exercise way-back-when was for each engineer to arrange their bugs distributed over several milestones
beta 1 - bugs x, w, and z beta 2 - bugs a, b, and c beta 3 - bugs e, f, and g
The scheduling part of this was to look across the entire project and all engineers and engineering groups to see which fixes and features where landing in each milestone. That provided and improved view of the likelyhood for risk in each beta/milestone, and the also the size and impact could be roughly derived from the total number of bugs assigned to each target milestone. When bugs had to be moved over from one milestone to the next people also started to develop a better sense of scheduling and which items continued to lag from one milestone to the next. This also signaled possible risk areas.
Its clear that other uses and explainations for target milestone have evolved, and we have move away from trying to do this kind of scheduling.
Mike Shaver wrote: > 2009/6/13 Fr�d�ric Buclin <LpSo...@gmail.com>:
>> That's the job of the target milestone field, not the version field. We (the >> Bugzilla project) also use the Version field to track when a bug appeared. >> This helps us to narrow the regression range. We maintain 4 branches; this >> information is really important.
> What do you do if a bug appears in multiple branches, but not all of > them? Similarly with them being fixed? Our branches aren't always > strictly ordered in time (periodic merges between tracemonkey and > mozilla-central are one example), so we can get almost arbitrary > combinations of these characteristics on different branches.
> If "target milestone" is what we are Supposed To Use to indicate when > a bug was fixed, why isn't it called "fixed milestone"? That would > certainly have made its proper use clearer to me! (b.m.o's > explanatory link for "target milestone" points at a document dated Jan > 1, 2009 that talks about the path to Firefox 2, so we can probably > improve things a bit by explaining it on fields.html and linking > there.)
>> How then would you discover bugs that are OS dependent? I'm dealing >> with them every day, and it would awfully complicate my work if that >> field was not there.
>> As a compromise one could remove the OS and Hardware fields from the >> guided form. But then I am not sure how I could reliably search for >> all OS/2 bugs that were filed over the last 5 days...
> I think that specific search requirements can be better met with keywords, > since most bugs are not platform-specific. I think the principle should be > "don't have metadata fields where a keyword will work".
OK, if I would only ever search for OS/2 bugs, that would work. But keywords are a mess to search. And as the keyword field already has many uses, adding more purposes to it will cause it to "overflow" on even more bugs.
I still think that All+All default and hiding on the guided form would solve most of your problems while retaining their usefulness for all the ports.
