> On 2 Nov 2017, at 10:37, Clément Aubin <aubincl...@gmail.com> wrote: > > Hi, > > On 11/02/2017 09:49 AM, Vincent Massol wrote: >> >>> On 1 Nov 2017, at 18:41, Alexandru Cotiuga <alexandru.coti...@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-Resolved-Chart/13610 >> >> 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? > > 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. > 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#HMigratingawayfromtheOldCore) > 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
