[Proposal] XS 10.2 and 10.3 roadmaps - Bug fix releases

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] XS 10.2 and 10.3 roadmaps - Bug fix releases

vmassol
Administrator
Hi devs,

We have already started defining the roadmap for XS 10.2, see https://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki11.2

However, it’s come to my realization that we’re having a lot of stability issue on XS these days. I see plenty of users messages on the forum about users failing to use XWiki or to upgrade XWiki and having problems in general. I have the feeling that our quality has regressed.

If we check our number of bugs created vs number of bugs closed for 2018, we can clearly see that we’re loosing the battle since Feb/March 2018, see:
https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352#Created-vs-Resolved-Chart/16742

Since Feb/March we’re at 820 vs 963 which means we have a relative difference of 143 bugs. Note that the BFD sessions are not enough and they don’t close a lot of bugs anymore (this can be seen on https://www.xwiki.org/xwiki/bin/view/Blog/XWiki%20Days).

I believe that XWiki’s stability and reducing user frustration for installation/upgrades is a key aspect and it’s one of the biggest possible contributor to Active Installs.

Thus I’m proposing to devote 2 releases (i.e. 2 months) to focus on bug fixing and thus on XWiki stability, namely
* XS 10.2
* XS 10.3

Note that this is something that I’ve already discussed with committers from XWiki SAS. Please voice your opinion if you disagree (or even if you agree, always good to get confirmation we’re going in the right direction ;)).

Thanks
-Vincent

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] XS 10.2 and 10.3 roadmaps - Bug fix releases

vmassol
Administrator
Hi devs,

No feedback so I guess everyone is ok with this.

I’ve now updated https://www.xwiki.org/xwiki/bin/view/Roadmaps/

I’ve also suggested to have an objective of collectively reducing the bug count by 50 in XWiki 11.2 and 50 more in XWiki 11.3, with the goals of closing bugs (not necessarily fixing them, BFD-like).

My computation: 1 bug closed per day (we can easily close 5-6 if we find dups/won’t fix/etc, taking 1 to have margin) * 5 (days of week) * 3.5 (for the month, keeping some margin) * 3 (active FTE devs on XS) = 52.5.

Ideally we should focus on quantity and not quality, and take bugs that don’t take more than 1-2 days to fix.

That seems doable to me, WDYT?

Thanks
-Vincent

> On 11 Feb 2019, at 16:33, Vincent Massol <[hidden email]> wrote:
>
> Hi devs,
>
> We have already started defining the roadmap for XS 10.2, see https://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki11.2
>
> However, it’s come to my realization that we’re having a lot of stability issue on XS these days. I see plenty of users messages on the forum about users failing to use XWiki or to upgrade XWiki and having problems in general. I have the feeling that our quality has regressed.
>
> If we check our number of bugs created vs number of bugs closed for 2018, we can clearly see that we’re loosing the battle since Feb/March 2018, see:
> https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352#Created-vs-Resolved-Chart/16742
>
> Since Feb/March we’re at 820 vs 963 which means we have a relative difference of 143 bugs. Note that the BFD sessions are not enough and they don’t close a lot of bugs anymore (this can be seen on https://www.xwiki.org/xwiki/bin/view/Blog/XWiki%20Days).
>
> I believe that XWiki’s stability and reducing user frustration for installation/upgrades is a key aspect and it’s one of the biggest possible contributor to Active Installs.
>
> Thus I’m proposing to devote 2 releases (i.e. 2 months) to focus on bug fixing and thus on XWiki stability, namely
> * XS 10.2
> * XS 10.3
>
> Note that this is something that I’ve already discussed with committers from XWiki SAS. Please voice your opinion if you disagree (or even if you agree, always good to get confirmation we’re going in the right direction ;)).
>
> Thanks
> -Vincent
>

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] XS 10.2 and 10.3 roadmaps - Bug fix releases

Simon Urli
Hi Vincent,

On 16/02/2019 12:25, Vincent Massol wrote:

> Hi devs,
>
> No feedback so I guess everyone is ok with this.
>
> I’ve now updated https://www.xwiki.org/xwiki/bin/view/Roadmaps/
>
> I’ve also suggested to have an objective of collectively reducing the bug count by 50 in XWiki 11.2 and 50 more in XWiki 11.3, with the goals of closing bugs (not necessarily fixing them, BFD-like).
>
> My computation: 1 bug closed per day (we can easily close 5-6 if we find dups/won’t fix/etc, taking 1 to have margin) * 5 (days of week) * 3.5 (for the month, keeping some margin) * 3 (active FTE devs on XS) = 52.5.
>
> Ideally we should focus on quantity and not quality, and take bugs that don’t take more than 1-2 days to fix.

I'm mixed with this idea of focusing on quantity and not quality here:
when it's about BFD I'm ok with it since we only got one day to fix
them. Now here we got two months, so we can use them to also focus on
more difficult bugs that are there for a while, at least to discuss on
what we plan to do to fix them.

To give some figures, out of 44 critical bugs in
Commons/Rendering/Platform 31 of them are there for more than one year.
I know those are pretty difficult to fix, but then we can spent a bit of
time on them to at least analyze them.

Now maybe I'm just too young on the project and all of them have been
thoroughly analyzed already and they're not fixed because basically we
cannot right now?

WDYT?
Simon

>
> That seems doable to me, WDYT?
>
> Thanks
> -Vincent
>
>> On 11 Feb 2019, at 16:33, Vincent Massol <[hidden email]> wrote:
>>
>> Hi devs,
>>
>> We have already started defining the roadmap for XS 10.2, see https://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki11.2
>>
>> However, it’s come to my realization that we’re having a lot of stability issue on XS these days. I see plenty of users messages on the forum about users failing to use XWiki or to upgrade XWiki and having problems in general. I have the feeling that our quality has regressed.
>>
>> If we check our number of bugs created vs number of bugs closed for 2018, we can clearly see that we’re loosing the battle since Feb/March 2018, see:
>> https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352#Created-vs-Resolved-Chart/16742
>>
>> Since Feb/March we’re at 820 vs 963 which means we have a relative difference of 143 bugs. Note that the BFD sessions are not enough and they don’t close a lot of bugs anymore (this can be seen on https://www.xwiki.org/xwiki/bin/view/Blog/XWiki%20Days).
>>
>> I believe that XWiki’s stability and reducing user frustration for installation/upgrades is a key aspect and it’s one of the biggest possible contributor to Active Installs.
>>
>> Thus I’m proposing to devote 2 releases (i.e. 2 months) to focus on bug fixing and thus on XWiki stability, namely
>> * XS 10.2
>> * XS 10.3
>>
>> Note that this is something that I’ve already discussed with committers from XWiki SAS. Please voice your opinion if you disagree (or even if you agree, always good to get confirmation we’re going in the right direction ;)).
>>
>> Thanks
>> -Vincent
>>
>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] XS 10.2 and 10.3 roadmaps - Bug fix releases

vmassol
Administrator
Hi Simon,

> On 19 Feb 2019, at 08:16, Simon Urli <[hidden email]> wrote:
>
> Hi Vincent,
>
> On 16/02/2019 12:25, Vincent Massol wrote:
>> Hi devs,
>> No feedback so I guess everyone is ok with this.
>> I’ve now updated https://www.xwiki.org/xwiki/bin/view/Roadmaps/
>> I’ve also suggested to have an objective of collectively reducing the bug count by 50 in XWiki 11.2 and 50 more in XWiki 11.3, with the goals of closing bugs (not necessarily fixing them, BFD-like).
>> My computation: 1 bug closed per day (we can easily close 5-6 if we find dups/won’t fix/etc, taking 1 to have margin) * 5 (days of week) * 3.5 (for the month, keeping some margin) * 3 (active FTE devs on XS) = 52.5.
>> Ideally we should focus on quantity and not quality, and take bugs that don’t take more than 1-2 days to fix.
>
> I'm mixed with this idea of focusing on quantity and not quality here: when it's about BFD I'm ok with it since we only got one day to fix them. Now here we got two months, so we can use them to also focus on more difficult bugs that are there for a while, at least to discuss on what we plan to do to fix them.
>
> To give some figures, out of 44 critical bugs in Commons/Rendering/Platform 31 of them are there for more than one year. I know those are pretty difficult to fix, but then we can spent a bit of time on them to at least analyze them.
>
> Now maybe I'm just too young on the project and all of them have been thoroughly analyzed already and they're not fixed because basically we cannot right now?
>
> WDYT?

Sure, we can have a look at the bugs existing in jira and try to take the “more important” one first. However be careful that the severity in JIRA may not reflect what we think. Any user having an issue that is blocking him/her will consider it critical even though it may be a special use case that we consider a not important at all compared to other more important bugs.

Also note that 1-2 days to fix a bug is quite large and show allow to fix a big majority of them.

Last point is that we’re not waiting for bug fix releases to fix important bugs, we do that every day already and that’s good. The point here is not just to do more of what we usually do, it’s also to do what we don’t do often (we do that once per week during BFDs only), i.e. fix easy bugs and also take the time to clean up our JIRA by closing bugs we won’t fix, that are duplicates, etc. Said differently closing 5 bugs that are marked ‘major’ can be a lot better for XWiki than fixing one hard bug marked critical but that’s specific to a seldom-used use case.

I’d still like that we keep the spirit of trying to close the maximum number of bugs and stay within the 1-2 days if we can, as the general rule. Remember that the reason we’re doing these 2 BFD releases is to close more bugs than there are bugs created over the past 1600 days and go back to 0, which is the situation we were in, about 1-2 years ago. Thus we’ve lost ground and the goal is to catch up.

Of course, if we notice an important bug, we can quickly discuss it between ourselves and decide if it’s really important and fix it. If you already have some ideas of such bugs, let’s discuss them.

Thanks
-Vincent

> Simon
>> That seems doable to me, WDYT?
>> Thanks
>> -Vincent
>>> On 11 Feb 2019, at 16:33, Vincent Massol <[hidden email]> wrote:
>>>
>>> Hi devs,
>>>
>>> We have already started defining the roadmap for XS 10.2, see https://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki11.2
>>>
>>> However, it’s come to my realization that we’re having a lot of stability issue on XS these days. I see plenty of users messages on the forum about users failing to use XWiki or to upgrade XWiki and having problems in general. I have the feeling that our quality has regressed.
>>>
>>> If we check our number of bugs created vs number of bugs closed for 2018, we can clearly see that we’re loosing the battle since Feb/March 2018, see:
>>> https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352#Created-vs-Resolved-Chart/16742
>>>
>>> Since Feb/March we’re at 820 vs 963 which means we have a relative difference of 143 bugs. Note that the BFD sessions are not enough and they don’t close a lot of bugs anymore (this can be seen on https://www.xwiki.org/xwiki/bin/view/Blog/XWiki%20Days).
>>>
>>> I believe that XWiki’s stability and reducing user frustration for installation/upgrades is a key aspect and it’s one of the biggest possible contributor to Active Installs.
>>>
>>> Thus I’m proposing to devote 2 releases (i.e. 2 months) to focus on bug fixing and thus on XWiki stability, namely
>>> * XS 10.2
>>> * XS 10.3
>>>
>>> Note that this is something that I’ve already discussed with committers from XWiki SAS. Please voice your opinion if you disagree (or even if you agree, always good to get confirmation we’re going in the right direction ;)).
>>>
>>> Thanks
>>> -Vincent
>>>
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com