On Fri, 14 Mar 2014 18:18:54 +0100, Joel Madero
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 (automated based on either 1
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
illa.org/?p=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-tp4101
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
Sent: Friday, March 14, 2014 8:58 AM
To: Libreoffice QA List
Subject: [Libreoffice-qa] Version field options way too fine grained
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
difficu
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
14 matches
Mail list logo
