2 Nov
2017
2 Nov
'17
1:50 p.m.
On 2 Nov 2017, at 10:37, Clément Aubin
<aubincleme(a)gmail.com> wrote:
Hi,
On 11/02/2017 09:49 AM, Vincent Massol wrote:
One other idea : we have more active installs (see
http://www.xwiki.org/xwiki/bin/temp/space/page/chart/2142541496.png)
since … hmm … ok, hard to tell ^^ ; but it's globally increasing. We
then have more user feedback, which can lead to more issues.
Yes, I’ve noticed this too: the more tester you put for an app and the more bugs you get,
till you find the plateau and then it goes down (unless you add features which keeps
adding bugs).
I don’t know where we stand but with 10+ years, we should normally have reached that
plateau and even started going down for all past features. For new features it’s another
matter but the analysis I’ve done above doesn’t really show that the bugs are located in
recent features.
On 1 Nov 2017, at 18:41, Alexandru Cotiuga
<alexandru.cotiuga(a)xwiki.com> wrote:
Hello devs,
This Thursday is BFD#153:
http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays
Our current status is:
* -36 bugs over 120 days (4 months), i.e. we need to close 28 bugs to have
created bugs # = closed bugs #
I guess you meant 36 and not 28 :)
* -78 bugs over 365 days (1 year)
* -52 bugs over 500 days (between 1 and 2 years)
* -218 bugs over 1600 days (4.3 years)
Wow we’re really drifting… we were positive till roughly early 2015 and then we’ve kept
increasing then, see:
https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352#Created-vs-…
Note that we’ve changed the definition of the query (The query is: category = 10000 AND
issuetype = Bug ORDER BY key DESC), since we added some projects (CK, Tour, Templates,
Help) but those were inside platform before so in practice it doesn’t change the scope.
Also note that we’ve moved out several modules outside of platform and into contrib
projects so that should have removed issues/bugs! Thus the situation is even worse than it
appears...
I wonder what made this increase in bugs...
Some ideas:
* We have less devs active on the xwiki github org. See the commit stats on
http://dev.xwiki.org/xwiki/bin/temp/space/page/chart/2123416786.png (last bar on the right
is from June 2016 to June 2017). So this means less issues fixed but also less bugs
fixed.
* Out of the 639 open bugs I see in my query, the categories with > 15 open bugs are:
** Dev issues only: 21
** Extension: 17
** AS: 18
** Administration: 20
** AWM: 20
** Office: 18
** Old Core: 114
** WYSIWYG (including CKEditor): 30+10 = 40
(this accounts for 268 bugs, i.e. 41% only, the rest is scattered across other
categories)
* Less BFDs than before?
WDYT? 
Regarding the possibles solutions, here are some of
them :
* As we are now preparing for a new LTS release, it could be nice to
organize something like a BFW (Bug Fixing Week) or a BFM ; I didn't
checked if we are on time on the roadmap though, but this could help
lowering the number of bugs going in the 10.* versions ; especially
considering the fact that some difficult bugs take more than one day to
resolve.
Yes and this is what we used to do last year and previous years: we always had 2 releases
that we called “Stabilization Releases” at the end of the cycle.
Starting in Jan 2018 we’ve moved to doing monthly releases (from X.0 to X.11) and we
haven’t discussed this but it would be good that we continue. It’s a bit too late for
XWiki 9.10 but I propose that XWiki 9.11 be a stabilization release (ie no new features).
In practice we haven’t added new features since a very long time (last one I can think of
is the Notification one) and all the rest can be considered stabilization.
Now we cannot say that XWiki 9.11 will be only about bugs since we also need to finish
polishing all features introduced in the 9.x cycle, but we could say that the main goal of
9.11 is to do bug fixes. However we need to make Notifications usable/polished + I’d
really like that we implement https://jira.xwiki.org/browse/XWIKI-14377 which I believe
should help a lot to reduce upgrade issues on the long run. We also need urgently to fix
the performance regressions we’ve introduced in XWiki 9.x compared to the LTS.
So all in all and seen the number of active committers we’re going to have for XWiki 9.11,
I doubt that we’ll have the time to work exclusively on bug fixes…
However we could say that Jan 2018 is about bug fixing and release both XWiki 10.0 and
several XWiki 9.11.x during the month of Jan 2018, focusing on bug fixes.
* The GCI might help reducing the number of trivial /
easy bugs if done
correctly.
Let’s hope it works out that way :)
* The category having the most bugs is Old Core (about
17% of the total
number of bugs) and it's growing (see
https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13924). Maybe
we should either :
** Try to focus more on Old Core bugs during BFDs
** Try to solve the fact that, after 10+ years of «Moving away from the
Old Core» (see
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HMigrati…)
we are still heavily relying on it and integrate some solutions for
removing some Old Core components directly as part of the 2018 roadmap.
Yes we need that. Oldcore is most likely still growing in size (even though we removed
some plugins) and that’s bad. We need to brainstorm about this and find some tangible
actions.
Thanks for your good ideas Clement! :)
-Vincent
Hope it helps,
Clément
> Thanks
> -Vincent
>
>
>> * -690 bugs since the beginning of XWiki
>>
>> See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
>>
>>
>> Here's the BFD#153 dashboard to follow the progress during the day:
>> https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13923
>>
>> Happy Bug Fixing Day,
>> Alex