Re: [Libreoffice-qa] LibreOffice releases (was: Reminder: QA Meeting on Wednesday)

[Bjoern Michaelsen]

Hi,

On Wed, Nov 25, 2015 at 04:27:58PM -0700, Pedro wrote:
> But since you can't ask the developers to do such a boring job, even that
> won't solve the problem...

Thats not entirely true. Yes, just asking some random developer to fix some
random regression (likely by another developer) is a very bad idea as it
assumes guilt by association. Bibisecting a regression and asking the developer
who causes the regression to fix it ... is less of a problem. There still might
be valid reasons from this developer not being able to care for this particular
regression at this point in time, so dont assume this to be a strictly mechanic
thing.

Note however that regressions _are_ being watched at the ESC. And people are
also watching who caused them (which is only possible when they are
bibisected) and where -- at least I am doing this already for quite a while. Im
not calling names in public though, as that would likely be very
counterproductive. It would only be a last resort if things go really out of
hands.

So QA can help here by really bibisecting bugs: Bibisected bugs tell developers
where we cant be braver and we are going too fast and loose. Good data on
bibisected regressions allows developer to handle things properly. However,
organizing the response has to happen between the developers (e.g. on the ESC)
as it would be foolish to assume a strictly mechanical handling to be helpful
here.

Best,

Bjoern

P.S.: If you want to raise visibility to regressions in a helpful way, I
suggest you start with a _positive_ motivation for developers. E.g. QA giving
out a badge each month for the three developers with (most simple approach):

- a/ the most commits
- b/ without a regression known to be bibisected down to a commit of him/her

I assume something like that might create some good and _positive_ motivation
in the right direction ...
___
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] LibreOffice releases (was: Reminder: QA Meeting on Wednesday)

[Pedro]

Hi Bjoern


Bjoern Michaelsen wrote
> Note however that regressions _are_ being watched at the ESC. And people
> are
> also watching who caused them (which is only possible when they are
> bibisected) and where -- at least I am doing this already for quite a
> while. Im
> not calling names in public though, as that would likely be very
> counterproductive. It would only be a last resort if things go really out
> of
> hands.

I'm glad to read this. Obviously the goal is not to point fingers (in fact
that would be a really bad move)


Bjoern Michaelsen wrote
> So QA can help here by really bibisecting bugs: Bibisected bugs tell
> developers
> where we cant be braver and we are going too fast and loose. Good data on
> bibisected regressions allows developer to handle things properly.

I'm well aware of that. However bibisecting is not a trivial task (in terms
of setting up a system and in terms of time). It would indeed be good to
have more people doing this but it is not so easy to recruit people when the
project's visibility is low. I'm on the QA mailing list for Apache
OpenOffice and some days (not every day, of course) there are 3 or 4 people
volunteering to join QA...


Bjoern Michaelsen wrote
> P.S.: If you want to raise visibility to regressions in a helpful way, I
> suggest you start with a _positive_ motivation for developers. E.g. QA
> giving
> out a badge each month for the three developers with (most simple
> approach):
> 
> - a/ the most commits
> - b/ without a regression known to be bibisected down to a commit of
> him/her
> 
> I assume something like that might create some good and _positive_
> motivation
> in the right direction ...

This is a positive suggestion.
Thank you! 

Best regards,
Pedro



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Reminder-QA-Meeting-on-Wednesday-tp4167253p4167478.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] LibreOffice releases (was: Reminder: QA Meeting on Wednesday)

[Pedro]

Hi Bjoern


Bjoern Michaelsen wrote
> On Wed, Nov 25, 2015 at 03:40:37AM -0700, Pedro wrote:
>> A sugestion: maybe have a branch dedicated to bug fixes every other year?
>> Example: let's say 5.1 is dedicated to fixes. Then a slight change of
>> schedule would postpone 5.2.0 to some months later so that most devs
>> would
>> concentrate on 5.1 (of course new features would still be added to Master
>> in
>> this period) instead of being split by two concurrent branches...
> 
> We have a "branch dedicated to bug fixes" twice a year. They are called
> "release
> branches" and live for about a year each. More details at:

Maybe my suggestion wasn't clear. I know about the "twice a year" release
branches. My suggestion was exactly to delay the second release of the year
so that developers could have more time to dedicate to a single branch (of
course they could always submit new features to the Master branch)

Looking at this chart
 

you will notice that there are very few times when developers are working on
a single branch. In fact most of the times they are working on 3 branches
simultaneously and therefore the constant "rush before release" that Sophie
mentions.

My suggestion was (as an example) to branch 5.2 later in the year (e.g. in
late October) so that there is 3-4 months to dedicate to 5.1 and therefore
have time to reduce the backlog of confirmed bugs (and even for QA people to
bisect some bugs without having to worry about testing a new branch).

My other suggestion was for TDF to organize a Bug Squashing Session during
this period.

Therefore this does not change the Timed release logic, it just spaces it a
bit to allow time for bug fixing...

Best regards,
Pedro



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Reminder-QA-Meeting-on-Wednesday-tp4167253p4167378.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/

[Libreoffice-qa] LibreOffice releases (was: Reminder: QA Meeting on Wednesday)

[Bjoern Michaelsen]

Hi,

On Wed, Nov 25, 2015 at 03:40:37AM -0700, Pedro wrote:
> A sugestion: maybe have a branch dedicated to bug fixes every other year?
> Example: let's say 5.1 is dedicated to fixes. Then a slight change of
> schedule would postpone 5.2.0 to some months later so that most devs would
> concentrate on 5.1 (of course new features would still be added to Master in
> this period) instead of being split by two concurrent branches...

We have a "branch dedicated to bug fixes" twice a year. They are called "release
branches" and live for about a year each. More details at:

 https://www.youtube.com/watch?v=7DBzRfW8R5k
 
http://conference.libreoffice.org/assets/Conference/Aarhus/Slides/BjoernMichaelsenreleases.pdf

If you need a branch that is living longer than a year, that is possible too,
but nothing volunteers would commit to. It is offered by various L3 supporters
of LibreOffice though:

 http://www.documentfoundation.org/certification/developers/

Best,

Bjoern
___
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] LibreOffice releases (was: Reminder: QA Meeting on Wednesday)

[Pedro]

Bjoern Michaelsen wrote
> That wouldnt help at all, "delaying the release" is just another name for
> "not
> making an release from master for a longer period of time" and thus would
> result in _more_ regressions, not less.

Let's see: If releases are slowed down there are more regressions, if they
aren't slowed down then there is no time/human resources to fix existing
regressions. Ergo the future is an always increasing number of regressions.
Unless the number of developers increases. But since you can't ask the
developers to do such a boring job, even that won't solve the problem...

Ah, well, sorry for the noise... Back to bugzilla...



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Reminder-QA-Meeting-on-Wednesday-tp4167253p4167433.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] LibreOffice releases

[Joel Madero]

>
> Maybe my suggestion wasn't clear. I know about the "twice a year" release
> branches. My suggestion was exactly to delay the second release of the year
> so that developers could have more time to dedicate to a single branch (of
> course they could always submit new features to the Master branch)
>
> Looking at this chart
> 
>  
>
> you will notice that there are very few times when developers are working on
> a single branch. In fact most of the times they are working on 3 branches
> simultaneously and therefore the constant "rush before release" that Sophie
> mentions.
>
> My suggestion was (as an example) to branch 5.2 later in the year (e.g. in
> late October) so that there is 3-4 months to dedicate to 5.1 and therefore
> have time to reduce the backlog of confirmed bugs (and even for QA people to
> bisect some bugs without having to worry about testing a new branch).
>
> My other suggestion was for TDF to organize a Bug Squashing Session during
> this period.
>
> Therefore this does not change the Timed release logic, it just spaces it a
> bit to allow time for bug fixing...
Nothing prevents developers now to dedicate 100% of their time to
regression squashing between major releasesA developer could have
(by choice) focused entirely on new features for 5.0, and entirely on
regression for 5.1. The fact that they did not implies that as
volunteers, that wasn't of any interest to them. I'm not seeing what
exactly you're proposing anyone do. Do you want TDF to lock LibreOffice
every other major release and say "absolutely no new features or bug
squashing, only regression fixing?" I think you have a misunderstanding
of the relationship that the Document Foundation (entity) has with it's
contributors (volunteers).

Again, nothing is preventing you from reaching out and trying to recruit
developers to focus on regressions.


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] LibreOffice releases (was: Reminder: QA Meeting on Wednesday)

[Bjoern Michaelsen]

Hi,

On Wed, Nov 25, 2015 at 10:10:58AM -0700, Pedro wrote:
> Maybe my suggestion wasn't clear. I know about the "twice a year" release
> branches. My suggestion was exactly to delay the second release of the year
> so that developers could have more time to dedicate to a single branch (of
> course they could always submit new features to the Master branch)

That wouldnt help at all, "delaying the release" is just another name for "not
making an release from master for a longer period of time" and thus would
result in _more_ regressions, not less. LibreOffice is already doing
exceptionally long release cycles compared to the rest of the open source
software world.

All of this is being discussed in the linked video, I suggest you watch it.

Best,

Bjoern
___
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/