Hello, all,
On Fri, 2014-03-14 at 10:11 -0700, bfoman wrote:
> Michael Stahl-2 wrote
> > definitely a problem, but i think it's a pretty fundamental limitation:
> > bugzilla simply has no concept of branches.
>
> Hi!
> Bugzilla branch support (called sightings):
> - progress - follow https://bugz
On 03/14/2014 10:11 AM, bfoman wrote:
> Michael Stahl-2 wrote
>> definitely a problem, but i think it's a pretty fundamental limitation:
>> bugzilla simply has no concept of branches.
I think we'll have the ability to add the additional version (branch)
once we have our own instance of bugzilla. M
Michael Stahl-2 wrote
> definitely a problem, but i think it's a pretty fundamental limitation:
> bugzilla simply has no concept of branches.
Hi!
Bugzilla branch support (called sightings):
- progress - follow https://bugzilla.mozilla.org/show_bug.cgi?id=55970
- code -
http://git.mozilla.org/?p=bu
On 14/03/14 14:58, Kohei Yoshida wrote:
> IMO we should only have 4.0, 4.1, 4.2 etc as version. All these too
> fine grained version numbers only serve to make bugs discoverable.
but then you can't easily tell what bugs are regressions on release
branches.
> What do you guys think about this?
Hi Kohei,
On Fri, Mar 14, 2014 at 09:58:00AM -0400, Kohei Yoshida wrote:
> I have my saved query and try to select all relevant versions but it's
> prone to errors. Today I just discovered a regression that I didn't see
> before because its version field was set to 4.2.0.0alpha0+Master which I
>
On Fri, 2014-03-14 at 08:19 -0700, m.a.riosv wrote:
> Hi,
> perhaps only two digits could be a bit short, IMO three can be a more
> balanced option, because it has a good correspondence with public releases.
Yeah, I think I'd be happy with this.
Also, part of the problems comes from the total-uns
Hi,
It is just a matter of querying...
All unconfirmed bugs for 4.2 release:
https://bugs.freedesktop.org/buglist.cgi?f1=version&list_id=404608&o1=regexp&query_format=advanced&bug_status=UNCONFIRMED&v1=%5E4%5C.2&product=LibreOffice
--
Liebe Grüße | Yours,
Florian Reisinger
Hi,
perhaps only two digits could be a bit short, IMO three can be a more
balanced option, because it has a good correspondence with public releases.
Miguel Ángel.
--
View this message in context:
http://nabble.documentfoundation.org/Libreoffice-qa-Version-field-options-way-too-fine-grained-t
@Kohei,
Not so sure, because it goes the other way as well.
When attempting to triage a bug, having the correct release --or better the
commit information to exactly reproduce the issue as reported, and work
backward to point of origin-- the granular field remains very helpful.
So perhaps i
Hey Kohei,
>
> What do you guys think about this?
Well I see a few potential issues but all in all it's QA's job to make
it easier for the developers and users so if it's thought that doing
this would do so we can discuss. We have substantially reduced the
number of versions listed (I removed all
On Fri, 2014-03-14 at 14:56 +, V Stuart Foote wrote:
> @Kohei,
>
> Not so sure, because it goes the other way as well.
>
> When attempting to triage a bug, having the correct release --or
> better the commit information to exactly reproduce the issue as
> reported, and work backward to poin
On Fri, 2014-03-14 at 09:58 -0400, Kohei Yoshida wrote:
> IMO we should only have 4.0, 4.1, 4.2 etc as version. All these too
> fine grained version numbers only serve to make bugs discoverable.
I mean "make bugs *un*-discoverable".
___
List Name: Li
Hi there,
Another thing I'd like to inquire about is that currently we have way
too fine-grained version field options it's becoming increasingly
difficult to query for "give me all bugs for 4.2" and similar. For
instance, even for the 4.2 branch we have
4.2.0.0alpha0+Master,
4.2.0.0alpha1
4.2.0
On Thu, Mar 13, 2014 at 08:12:49PM -0400, Kohei Yoshida wrote:
> I'm just wondering whether it's possible to disallow reopening of bugs
> if they are at least more than a year old (or whatever some arbitrary
> time period)? I've seen people re-opening bugs that were closed more
> than 2-3 years ag
14 matches
Mail list logo
