On Fri, 14 Mar 2014 18:18:54 +0100, Joel Madero jmadero@gmail.com
wrote:
I think we'll have the ability to add the additional version (branch)
once we have our own instance of bugzilla. My suggestion is three
version fields:
1. oldest version
2. latest version confirmed
3. branch
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
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:
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
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
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
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 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?
=bugzilla/bugzilla.git;a=shortlog;h=refs/heads/sightings
Unfortunately seems not finished yet but merged recently with up-to-date
code.
Best regards.
--
View this message in context:
http://nabble.documentfoundation.org/Libreoffice-qa-Version-field-options-way-too-fine-grained-tp4101391p4101433
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. My
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
Hi,
For the issues that I am in CC, it happens in an estimated 10-20% that
at some time any one touches, changes the version field (1) to a later
version. Which should not been done, once it is set properly with
submitting the bug.
Is there a possibility to set that field to locked, or only
12 matches
Mail list logo
