Re: [Libreoffice-qa] Bugzila 4.3.x versions cleanup
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
> 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
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
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
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
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
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
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/
