[Libreoffice-qa] Bugzila 4.3.x versions cleanup
pedlino at gmail.com
Mon Nov 30 04:22:33 PST 2015
Hi Tommy, all
>>> 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
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...)
> 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?
> 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?
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.
More information about the Libreoffice-qa