Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Pedro]

jmadero wrote
> On 12/01/2015 09:03 AM, Sophie wrote:
>> What he was trying to find imho is a compromise between what is needed
>> for QA and for users. Of course, the more granularity the better, but I
>> think also that a long list of version is confusing.

I think the problem here is that a compromise is not possible. 

It is absurd that the version list has 115 items !!!

LibreOffice_versions.ods
  

LibreOffice/TDF absolutely needs a user friendly Bug Submission Assistant
where users can report bugs they found in the stable releases of the live
branches (currently 4.4, 5.0 and 5.1). This would reduce the list to less
than 15 options...

The Bugzilla site has to be completely separate from this. Which user has
the patience (and knowledge) to register to a user unfriendly site with 115
options for a single variable, where several he doesn't even understand
their meaning?
Bugzilla is for QA and advanced users. There you can have all versions (I
would still exclude alphas, betas and rcs except for the latest version in
each live branch and exclude All versions) 


jmadero wrote
> I just wonder in terms of # of versions - how many are we talking about?
> 3-5 versions removed 2-3 months earlier? Given there area lot of
> versionsI'm just not sure if we'll see real gains from the proposal
> and there is a real possibility for loss.

Changing the period by months would not make a significant change...

However removing all alphas, betas and rcs except for the latest version in
each live branch and exclude All versions would reduce the list by nearly
one third (35/115). I think it's pretty impressive.

Again how many bugs are reported for the alpha, beta and rc stage for a
previous branch/version which are specific to that stage? How many are we
talking about?

I think need to improve the experience both for QA and (especially) for
users reporting bugs.

Regards,
Pedro



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Bugzila-4-3-x-versions-cleanup-tp4167758p4168006.html
Sent from the QA mailing list archive at Nabble.com.
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Joel Madero]

On 12/01/2015 03:19 PM, Pedro wrote:
> jmadero wrote
>> On 12/01/2015 09:03 AM, Sophie wrote:
>>> What he was trying to find imho is a compromise between what is needed
>>> for QA and for users. Of course, the more granularity the better, but I
>>> think also that a long list of version is confusing.
> I think the problem here is that a compromise is not possible. 
>
> It is absurd that the version list has 115 items !!!
>
> LibreOffice_versions.ods
>  
>  
>
> LibreOffice/TDF absolutely needs a user friendly Bug Submission Assistant
> where users can report bugs they found in the stable releases of the live
> branches (currently 4.4, 5.0 and 5.1). This would reduce the list to less
> than 15 options...
So . . . I think this is a completely separate issue and one that
perhaps we can discuss tendering somethingif I worked with you on
this front could you compromise and agree that bugzilla can stay as is
with current policies in place?


Best,
Joel
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Pedro]

jmadero wrote
>> LibreOffice/TDF absolutely needs a user friendly Bug Submission Assistant
>> where users can report bugs they found in the stable releases of the live
>> branches (currently 4.4, 5.0 and 5.1). This would reduce the list to less
>> than 15 options...
> So . . . I think this is a completely separate issue and one that
> perhaps we can discuss tendering somethingif I worked with you on
> this front could you compromise and agree that bugzilla can stay as is
> with current policies in place?

I will gladly work on such a proposal. However the bugzilla modifications
were not my idea, they were from Tommy. I just said I agreed that there are
too many versions. In any case I don't see how my opinion can affect the
current policies. I'm just a user, I'm not even a QA member.

Regards,
Pedro



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Bugzila-4-3-x-versions-cleanup-tp4167758p4168015.html
Sent from the QA mailing list archive at Nabble.com.
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Joel Madero]

On 12/01/2015 09:03 AM, Sophie wrote:
> Hi Joel,
> Le 01/12/2015 17:53, Joel Madero a écrit :
>>
>>
> Tommy's proposal was to simplify BZ approach on a user point of view. It
> is intimidating to go further when you're not sure what version you are
> using, and RC, beta are not clear things for users.
> What he was trying to find imho is a compromise between what is needed
> for QA and for users. Of course, the more granularity the better, but I
> think also that a long list of version is confusing.
> I'm not doing enough QA currently to have a firm opinion on Tommy's
> proposal, but I understand his request to shorten the 6 month period in
> this way.

I just wonder in terms of # of versions - how many are we talking about?
3-5 versions removed 2-3 months earlier? Given there area lot of
versionsI'm just not sure if we'll see real gains from the proposal
and there is a real possibility for loss.

Best,
Joel
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Joel Madero]

On 12/01/2015 02:59 AM, Pedro wrote:
> Hi Joel
>
>
> jmadero wrote
>>> If a user is able to tell that a bug was introduced between 4.0.0 and
>>> 4.0.1,
>>> a bibisect in that range should be able to find the problematic
>>> commit/patch?
>>> What would be the advantage to have the user install 4.0.0 Beta1, Beta2,
>>> RC1, etc?
>> Bibisect is really only at this point useful for Linux because the
>> documentation on OSX and Windows is still below par. That's at least my
>> understanding - have you tried to bibisect on other platforms?
> No, I never tried bibisect on Windows. But Sophie volunteered to give me a
> hand if I decided to try so I assume it is possible.
>
> Again, what would be the advantage to have the user install 4.0.0 Beta1,
> Beta2, RC1, etc? Reducing the search range to a 0.0.1 isn't good enough?
> Does the full footwork have to be on the QA side?
The benefit is narrowing it down by hundreds of commitshave you ever
looked at how many commits are between two alphas? Or between two point
releases? If we're sitting here screaming and yelling about regressions,
the more we narrow down the more likely regressions will be dealt with.

Example (commits between...):
5.0.0.1 beta1 and 5.0.0.5 release: 357
5.0.0.3 and 5.0.0.4 beta2: 42

As far as "all the footwork be on QA side" - yes.because all the
development work is on the developer side (it's not like they are asking
us to code.). It's our job to narrow down the issue as much as
possible (down to a single commit is best obviously) and then developers
can take over and do their magic with the code (that is almost always
way above my head).

This debate is going in circles - if no one else agrees with me then go
ahead (Tommy has permissions), just make sure to document it somewhere.
I'd give it a couple more weeks to see if someone else has additional
thoughts. My thought is that if a user is so super confused based on a
few extra versions thenwell then there bug reports are likely to be
bad anyways (it's not a high bar to understand versions).

@Tommy - I suggest clarifying what the proposal is at this time as you
and Pedro have deviated substantially.

Best,
Joel

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Joel Madero]

On 12/01/2015 02:59 AM, Pedro wrote:
> No, I never tried bibisect on Windows. But Sophie volunteered to give me a
> hand if I decided to try so I assume it is possible.
>
> Again, what would be the advantage to have the user install 4.0.0 Beta1,
> Beta2, RC1, etc? Reducing the search range to a 0.0.1 isn't good enough?
> Does the full footwork have to be on the QA side?

At least some developers agree with me btw - "precision is good" and
"lowering to the lowest common denominator doesn't seem ideal." Again,
certain developers have complained about QA tinkering without thinking
about the repercussions. Just because you can't see the benefits to
precision does not mean there aren't any.

Just food for thought as we debate changing things *once again*. Do we
actually know for a fact that users are getting confused by having a few
extra versions listed? Or are we just assuming (or it's a corner case
with a couple users complaining?) and in response we want to yet again
modify bugzilla versions?

*sighs*


Best,
Joel
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Sophie]

Hi Joel,
Le 01/12/2015 17:53, Joel Madero a écrit :
> 
> 
> On 12/01/2015 02:59 AM, Pedro wrote:
>> No, I never tried bibisect on Windows. But Sophie volunteered to give me a
>> hand if I decided to try so I assume it is possible.
>>
>> Again, what would be the advantage to have the user install 4.0.0 Beta1,
>> Beta2, RC1, etc? Reducing the search range to a 0.0.1 isn't good enough?
>> Does the full footwork have to be on the QA side?
> 
> At least some developers agree with me btw - "precision is good" and
> "lowering to the lowest common denominator doesn't seem ideal." Again,
> certain developers have complained about QA tinkering without thinking
> about the repercussions. Just because you can't see the benefits to
> precision does not mean there aren't any.
> 
> Just food for thought as we debate changing things *once again*. Do we
> actually know for a fact that users are getting confused by having a few
> extra versions listed? Or are we just assuming (or it's a corner case
> with a couple users complaining?) and in response we want to yet again
> modify bugzilla versions?

Tommy's proposal was to simplify BZ approach on a user point of view. It
is intimidating to go further when you're not sure what version you are
using, and RC, beta are not clear things for users.
What he was trying to find imho is a compromise between what is needed
for QA and for users. Of course, the more granularity the better, but I
think also that a long list of version is confusing.
I'm not doing enough QA currently to have a firm opinion on Tommy's
proposal, but I understand his request to shorten the 6 month period in
this way.

Cheers
Sophie

-- 
Sophie Gautier sophie.gaut...@documentfoundation.org
GSM: +33683901545
IRC: sophi
Co-founder - Release coordinator
The Document Foundation
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Christian Lohmaier]

Hi Joel,

On Tue, Dec 1, 2015 at 5:42 PM, Joel Madero  wrote:
>
>
> On 12/01/2015 02:59 AM, Pedro wrote:
>> Hi Joel
>>
>>
>> jmadero wrote
 If a user is able to tell that a bug was introduced between 4.0.0 and
 4.0.1,
 a bibisect in that range should be able to find the problematic
 commit/patch?
 What would be the advantage to have the user install 4.0.0 Beta1, Beta2,
 RC1, etc?
>>> Bibisect is really only at this point useful for Linux because the
>>> documentation on OSX and Windows is still below par. That's at least my
>>> understanding - have you tried to bibisect on other platforms?
>> No, I never tried bibisect on Windows. But Sophie volunteered to give me a
>> hand if I decided to try so I assume it is possible.
>>
>> Again, what would be the advantage to have the user install 4.0.0 Beta1,
>> Beta2, RC1, etc? Reducing the search range to a 0.0.1 isn't good enough?
>> Does the full footwork have to be on the QA side?
> The benefit is narrowing it down by hundreds of commitshave you ever
> looked at how many commits are between two alphas? Or between two point
> releases? If we're sitting here screaming and yelling about regressions,
> the more we narrow down the more likely regressions will be dealt with.
>
> Example (commits between...):
> 5.0.0.1 beta1 and 5.0.0.5 release: 357

you mixed nomenclature here it seems.
$ git log --oneline libreoffice-5.0.0.0.beta1..libreoffice-5.0.0.5 |wc -l
815

so 815 commits between 5.0.0 beta1 and 5.0.0 final

357 is the commit count between first RC and final
$ git log --oneline libreoffice-5.0.0.0.beta1..libreoffice-5.0.0.5 |wc -l
815

x.y.z.0… → LibreOfficeDev (alpha and beta),
x.y.z.1… → first RC, in release mode (LibreOffice)

> 5.0.0.3 and 5.0.0.4 beta2: 42

between rc3 and rc4

As long as the merge-to-one-version indicates what version was set
prior to the unification, I  don't see the information loss, but it
should be a standardized comment, so that you could still use queries
for those versions.

ciao
Christian
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Joel Madero]

On 12/01/2015 10:16 AM, Christian Lohmaier wrote:
>
> 5.0.0.3 and 5.0.0.4 beta2: 42
> between rc3 and rc4
>
> As long as the merge-to-one-version indicates what version was set
> prior to the unification, I  don't see the information loss, but it
> should be a standardized comment, so that you could still use queries
> for those versions.
Ah I see the confusion here. I'm talking about cases where _after the
merge happens_ we are asking users to go back and download archived
versions to try to narrow down where their regression was introduced. I
agree that if the version was already set to begin with then it's not a
big deal, but after the merge happens, if we're asking users to "narrow
down the regression 'as much as possible'" but then we are taking away
their ability to actually set the version...that seems like a problem
and pretty confusing.

This is why the 6 month rule IMHO makes sense. This gives QA 6 months to
triage the bug, try to determine if it's a regression, and try to get
users to assist as much as possible by narrowing down the version to the
most precise possible (absent bibisecting/bisecting). After 6 months it
probably is a lot less likely that the user would care enough to test
the bug against older versions so it makes sense to purge at this point.
2-3 months turnaround is IMHO too short when it can take 60 days just to
triage the bug (before there is a single touch by QA).

Best,
Joel
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Joel Madero]

>
> I will gladly work on such a proposal. However the bugzilla modifications
> were not my idea, they were from Tommy. I just said I agreed that there are
> too many versions. In any case I don't see how my opinion can affect the
> current policies. I'm just a user, I'm not even a QA member.
Don't be modest. You're a part of the team. And I know Tommy suggested
the change to begin with but you seemed to have stronger feelings about
going farther than Tommy's proposal :) But, if you can wait a couple
weeks I'll have a little time and we can try to draft something :) It'll
be a proposal to request funds (maybe through the grant request form).
I'll think about the best way to proceed.

Best,
Joel
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Pedro]

Hi Joel


jmadero wrote
>> If a user is able to tell that a bug was introduced between 4.0.0 and
>> 4.0.1,
>> a bibisect in that range should be able to find the problematic
>> commit/patch?
>> What would be the advantage to have the user install 4.0.0 Beta1, Beta2,
>> RC1, etc?
> 
> Bibisect is really only at this point useful for Linux because the
> documentation on OSX and Windows is still below par. That's at least my
> understanding - have you tried to bibisect on other platforms?

No, I never tried bibisect on Windows. But Sophie volunteered to give me a
hand if I decided to try so I assume it is possible.

Again, what would be the advantage to have the user install 4.0.0 Beta1,
Beta2, RC1, etc? Reducing the search range to a 0.0.1 isn't good enough?
Does the full footwork have to be on the QA side?

Regards,
Pedro



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Bugzila-4-3-x-versions-cleanup-tp4167758p4167899.html
Sent from the QA mailing list archive at Nabble.com.
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Pedro]

Hi Joel, all


jmadero wrote
> The problem really is that at least *I* do often time request users to
> go back and install older versions to help narrow down where a
> regression was introduced. This is particularly useful when a user is
> complaining about their regression not getting love - at this point I
> start heavily suggesting they do some of the lifting themselves to move
> it forward (bibisect themselves, if that's not possible to go back and
> install older versions and try to narrow down to a beta/rc where the
> issue was introduced). I've actually found this to not only be useful
> for the particular bug but also useful in recruiting new people.

I don't see any incompatibility in asking people to use several versions
(actually I do that using Portable versions of LibreOffice from WinPenPack)
and reducing the number of versions in the drop list. 
If a user is able to tell that a bug was introduced between 4.0.0 and 4.0.1,
a bibisect in that range should be able to find the problematic
commit/patch?
What would be the advantage to have the user install 4.0.0 Beta1, Beta2,
RC1, etc?

Regards,
Pedro



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Bugzila-4-3-x-versions-cleanup-tp4167758p4167859.html
Sent from the QA mailing list archive at Nabble.com.
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Joel Madero]

> Hi Joel, all
>
>
> jmadero wrote
>> The problem really is that at least *I* do often time request users to
>> go back and install older versions to help narrow down where a
>> regression was introduced. This is particularly useful when a user is
>> complaining about their regression not getting love - at this point I
>> start heavily suggesting they do some of the lifting themselves to move
>> it forward (bibisect themselves, if that's not possible to go back and
>> install older versions and try to narrow down to a beta/rc where the
>> issue was introduced). I've actually found this to not only be useful
>> for the particular bug but also useful in recruiting new people.
> I don't see any incompatibility in asking people to use several versions
> (actually I do that using Portable versions of LibreOffice from WinPenPack)
> and reducing the number of versions in the drop list. 
> If a user is able to tell that a bug was introduced between 4.0.0 and 4.0.1,
> a bibisect in that range should be able to find the problematic
> commit/patch?
> What would be the advantage to have the user install 4.0.0 Beta1, Beta2,
> RC1, etc?

Bibisect is really only at this point useful for Linux because the
documentation on OSX and Windows is still below par. That's at least my
understanding - have you tried to bibisect on other platforms?


Best,
Joel
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Joel Madero]

Hi All,

>
> As long as the comment moving all to the maj.min version includes the
> original version (or even adds it as a whiteboard item, I don't see
> need for having the versions available.
Well the comment doesn't always have the version - more often than not
it doesn't. I'm definitely not in favor of adding yet another thing to
whiteboard...too many opportunities for mistake, too often cluttered and
hard to follow.

Best,
Joel
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Joel Madero]

Hi All,

> I agree with Tommy. Bugzilla is unfriendly enough. Shortening the list is a
> good idea.
>
> How many people report bugs which are specific to a given RC? Are there more
> than 10 people in the world doing this? 
> In fact at the pace the RCs are released it is nearly impossible for someone
> to test and report bugs specific for an RC... Even if TDF had people
> contracted to do this, they still wouldn't have the time to thoroughly test
> and report bugs in time to be fixed before the next RC (and even the final
> version) is released.
>
> In my opinion the all the alpha, beta and RC bugs should be grouped ta o
> single version as soon as the following final version is released 
> E.g. All 5.0.0 alpha, beta and RCs should be grouped into 5.0.0 when the
> first RC for 5.0.1 is announced to the public (and added to the list).
>
> In fact, at this point there should be only the alphas, betas and RCs for
> the 4.4.7, 5.0.3 and 5.1.0 releases (and it's quite enough confusion to have
> 3 branches releasing at the same time...)
The problem really is that at least *I* do often time request users to
go back and install older versions to help narrow down where a
regression was introduced. This is particularly useful when a user is
complaining about their regression not getting love - at this point I
start heavily suggesting they do some of the lifting themselves to move
it forward (bibisect themselves, if that's not possible to go back and
install older versions and try to narrow down to a beta/rc where the
issue was introduced). I've actually found this to not only be useful
for the particular bug but also useful in recruiting new people.

Best,
Joel
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Tommy]

Joel Madero wrote:

Hi All,



As long as the comment moving all to the maj.min version includes the
original version (or even adds it as a whiteboard item, I don't see
need for having the versions available.

Well the comment doesn't always have the version - more often than not
it doesn't. I'm definitely not in favor of adding yet another thing to
whiteboard...too many opportunities for mistake, too often cluttered and
hard to follow.

Best,
Joel


+1 we don't need to make things even more complex


___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Tommy]

Pedro wrote:

Hi Tommy, all


Tommy wrote

1- I still think that the 6 months EOL embargo before cleanup is too
much... It would be better to do the cleanup earlier, let's say 4 or 3
months after the EOL


so leaving all those RCs in the list for such a long time still seems to
me just a waste of space...


I agree with Tommy. Bugzilla is unfriendly enough. Shortening the list is a
good idea.

.

In my opinion the all the alpha, beta and RC bugs should be grouped ta o
single version as soon as the following final version is released
E.g. All 5.0.0 alpha, beta and RCs should be grouped into 5.0.0 when the
first RC for 5.0.1 is announced to the public (and added to the list).



I wouldn't be so drastical...
my original proposal is just to shorten the cleanup waiting time from 6 
months to 3 months




___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Tommy]

Pedro wrote:



I don't see any incompatibility in asking people to use several versions
(actually I do that using Portable versions of LibreOffice from WinPenPack)
and reducing the number of versions in the drop list.

>

..

>

Regards,
Pedro



I use too winPenPack versions to identify regression points.
Tommy

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Pedro]

Hi Tommy, all


Tommy wrote
>>> 1- I still think that the 6 months EOL embargo before cleanup is too
>>> much... It would be better to do the cleanup earlier, let's say 4 or 3
>>> months after the EOL
>>
>> I still disagree :) I don't see that many benefits and I see potential
>> issues that cause headaches for users and contributors alike.
> 
> let's do practical examples...
> I'm not seeing many bug reports about RCs of old .1, .2, .3 ... .6 
> releases after 4 months that the final .7 RC1 has been released
> 
> so leaving all those RCs in the list for such a long time still seems to 
> me just a waste of space...

I agree with Tommy. Bugzilla is unfriendly enough. Shortening the list is a
good idea.

How many people report bugs which are specific to a given RC? Are there more
than 10 people in the world doing this? 
In fact at the pace the RCs are released it is nearly impossible for someone
to test and report bugs specific for an RC... Even if TDF had people
contracted to do this, they still wouldn't have the time to thoroughly test
and report bugs in time to be fixed before the next RC (and even the final
version) is released.

In my opinion the all the alpha, beta and RC bugs should be grouped ta o
single version as soon as the following final version is released 
E.g. All 5.0.0 alpha, beta and RCs should be grouped into 5.0.0 when the
first RC for 5.0.1 is announced to the public (and added to the list).

In fact, at this point there should be only the alphas, betas and RCs for
the 4.4.7, 5.0.3 and 5.1.0 releases (and it's quite enough confusion to have
3 branches releasing at the same time...)


Tommy wrote
> so where's the potential headache you see in users and developers if we 
> anticipate the cleanup removing obsolete RCs ?

I can't see that ANY users are affected.
In fact the RC system does not care about Users. It is not expected that
Users have intermediate RC versions (if that was the case then this bug
would not exist https://bugs.documentfoundation.org/show_bug.cgi?id=46354)

I don't see how this can be a problem for developers... If there is a need
to bibisect then it will point at a specific patch regardless of the stage
the bug was reported/added.

This is a QA problem only. And there are very few of us. 

If Bugzilla is more user friendly it is more likely that people will bother
to submit a bug. BTW what happened to the BSA?


Tommy wrote
> the gain is to shorten the list removing seldomly used items which are 
> not accurate helping us tracking the first release where a bug 
> appeared... if you say 4.3 all version may be any release between 4.3.0 
> and 4.3.7 which spans a range of hundreds commits

I agree. Again, the shorter the list the better. Having a All versions is
exactly the opposite logic of bibisecting. We want the user to point at a
specific version. Why broaden the search when we want to narrow it down?

Regards,
Pedro



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Bugzila-4-3-x-versions-cleanup-tp4167758p4167836.html
Sent from the QA mailing list archive at Nabble.com.
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Joel Madero]

Hi Tommy,

On 11/29/2015 09:40 AM, Tommy wrote:
> since 6 months passed by from the 4.3.x EOL I cleaned up the bugzilla
> version field from all the alphas, betas and RCs.
>
> now only final releases are available and a 4.3 all versions item has
> been added.
>
> just a few considerations I've already expressed to Joel few months ago:
>
> 1- I still think that the 6 months EOL embargo before cleanup is too
> much... It would be better to do the cleanup earlier, let's say 4 or 3
> months after the EOL

I still disagree :) I don't see that many benefits and I see potential
issues that cause headaches for users and contributors alike.
>
> 2- I think the "all versions" items are unnecessary... as far as I
> remember that was an item created for the BSA which is now not
> supported anymore. when we ask users to define the "earlier version"
> where the bug appeared we want them to exactly define in which release
> the bug appeared... so this generic "all versions" item is in contrast
> with our policy. I suggest to hide all those "all versions" items from
> the version admin page. doing this we would get rid of 8 items from
> our long version list.

Mixed feelings here. I don't think we should be tinkering a lot unless
there is a real gain. Again, here I see no real gain. Others have
appropriately criticized the QA team for "tinkering too much" and I
think that we should really think about if there is something concrete
to gain before tinkering a bunch.


Best,
Joel
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Tommy]

Joel Madero wrote:

Hi Tommy,


1- I still think that the 6 months EOL embargo before cleanup is too
much... It would be better to do the cleanup earlier, let's say 4 or 3
months after the EOL


I still disagree :) I don't see that many benefits and I see potential
issues that cause headaches for users and contributors alike.


let's do practical examples...
I'm not seeing many bug reports about RCs of old .1, .2, .3 ... .6 
releases after 4 months that the final .7 RC1 has been released


so leaving all those RCs in the list for such a long time still seems to 
me just a waste of space...


regarding the 4.3.x branch I've just cleaned,
the 4.3.0 RC1 was released in june 2014...
the 4.3.4 RC1 was released in november 2014 and
the 4.3.7 final release was out in april 2015
and EOL was set on may 27 2015

we currently wait 6 months after the EOL, that is late november 2015
which means that the first 4.3.x RCs have been on the list for almost an 
year and an half



so where's the potential headache you see in users and developers if we 
anticipate the cleanup removing obsolete RCs ?




2- I think the "all versions" items are unnecessary... as far as I
remember that was an item created for the BSA which is now not
supported anymore. when we ask users to define the "earlier version"
where the bug appeared we want them to exactly define in which release
the bug appeared... so this generic "all versions" item is in contrast
with our policy. I suggest to hide all those "all versions" items from
the version admin page. doing this we would get rid of 8 items from
our long version list.


Mixed feelings here. I don't think we should be tinkering a lot unless
there is a real gain. Again, here I see no real gain. Others have
appropriately criticized the QA team for "tinkering too much" and I
think that we should really think about if there is something concrete
to gain before tinkering a bunch.



the gain is to shorten the list removing seldomly used items which are 
not accurate helping us tracking the first release where a bug 
appeared... if you say 4.3 all version may be any release between 4.3.0 
and 4.3.7 which spans a range of hundreds commits




Best,
Joel


Bye, Tommy

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

[Libreoffice-qa] Bugzila 4.3.x versions cleanup

[Tommy]

since 6 months passed by from the 4.3.x EOL I cleaned up the bugzilla 
version field from all the alphas, betas and RCs.


now only final releases are available and a 4.3 all versions item has 
been added.


just a few considerations I've already expressed to Joel few months ago:

1- I still think that the 6 months EOL embargo before cleanup is too 
much... It would be better to do the cleanup earlier, let's say 4 or 3 
months after the EOL


2- I think the "all versions" items are unnecessary... as far as I 
remember that was an item created for the BSA which is now not supported 
anymore. when we ask users to define the "earlier version" where the bug 
appeared we want them to exactly define in which release the bug 
appeared... so this generic "all versions" item is in contrast with our 
policy. I suggest to hide all those "all versions" items from the 
version admin page. doing this we would get rid of 8 items from our long 
version list.


feel free to discuss this in the QA mailing list or in the next QA 
meeting... unfortunately I cannot be present in QA meetings because of 
work and family issue, but I'm interested to know what other people 
thinks about this


bye, Tommy

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/