On 1/9/2014 9:47 AM, Gavin Sharp wrote:
In theory (mine at least), the field is free to be used for planning
which release you want the bug fixed in, before the bug is fixed.
After the bug is fixed, it should be used as you describe.
Some groups do use the field this way, for example the NSS
On 1/16/14 11:36 AM, Daniel Veditz wrote:
On 1/9/2014 9:47 AM, Gavin Sharp wrote:
In theory (mine at least), the field is free to be used for planning
which release you want the bug fixed in, before the bug is fixed.
After the bug is fixed, it should be used as you describe.
Some groups do use
On Friday, January 10, 2014 4:56:45 PM UTC-5, David Lawrence wrote:
Currently Bugzilla does not support relabeling of fields in the UI based
on some criteria. They are pretty well hard coded with the names. It would
be a non-trivial amount of work to add the support and it would definitely
After some discussion with other BMO devs, how about this proposal?
We add a (info) link next to the Milestone label on the show_bug.cgi page that
has some custom documentation explaining the purpose of the field for the
selected product? We can make the text different for different products as
That sounds pretty reasonable to me.
Cheers,
kats
On 14-01-14 10:59 , dklaw...@gmail.com wrote:
After some discussion with other BMO devs, how about this proposal?
We add a (info) link next to the Milestone label on the show_bug.cgi page that
has some custom documentation explaining the
On 01/09/2014 12:47 PM, Gavin Sharp wrote:
It should be possible to have the field label change only for a
specific set of products, in theory. Having the ability to customize
on a per-product basis like this would make a lot of these proposals
easier. I think we should ask our b.m.o devs
I think the Target Milestone field is poorly named, at least with
respect to what we use it for. In practice this field is set to the
version of m-c on which the patches originally landed, and doesn't
change when patches are uplifted to other branches.
However, I've seen many people mistake
(It's probably a good idea scope this discussion to common practice in
the Firefox components i.e. Core/Firefox/Toolkit/etc. Bugzilla
discussions like this one can get into the weeds pretty quickly when
people bring up other projects who use our Bugzilla installation and
who have different
On 1/9/14, 7:17 AM, Kartikaya Gupta wrote:
I think the Target Milestone field is poorly named, at least with
respect to what we use it for. In practice this field is set to the
version of m-c on which the patches originally landed, and doesn't
change when patches are uplifted to other branches.
On Thu, Jan 9, 2014 at 9:53 AM, Chris Peterson cpeter...@mozilla.comwrote:
On 1/9/14, 7:17 AM, Kartikaya Gupta wrote:
I think the Target Milestone field is poorly named, at least with
respect to what we use it for. In practice this field is set to the
version of m-c on which the patches
On 1/9/2014 12:53 PM, Chris Peterson wrote:
What is the use case for Target Milestone (in the Patches Landed In
sense)? As you point out, the Target Milestone is not updated if a fix
is uplifted, so Target Milestone does not even represent the first Gecko
release that contains the fix. That
I'm sure there are other use cases, but the most common one for me is
using it to sort out tracking flags for regressions and otherwise
complicated dependency trees.
Gavin
On Thu, Jan 9, 2014 at 9:53 AM, Chris Peterson cpeter...@mozilla.com wrote:
On 1/9/14, 7:17 AM, Kartikaya Gupta wrote:
I
12 matches
Mail list logo
