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 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 Tuesday, January 14, 2014 12:08:23 PM UTC-5, Kartikaya Gupta wrote:
> 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
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 purpo
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
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
>
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'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 wrote:
> On 1/9/14, 7:17 AM, Kartikaya Gupta wrote:
>>
>> I think the "Target
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
On 1/9/14 9:53 AM, Chris Peterson wrote:
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 wh
On Thu, Jan 9, 2014 at 9:53 AM, Chris Peterson wrote:
> 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 lande
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.
(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 practi
13 matches
Mail list logo
