Re: [xwiki-devs] [Proposal] CAPTCHA module refactoring

[Thomas Mortagne]

I agree that the default captcha we provide should not depend on an
external service but it should just be a default. IMO the most
important is to make sure it's easy to choose a different captcha
implementation and we should most probably provide the Google one as
an option (through a contrib extension to better follow Google captcha
API evolution).

On Fri, May 25, 2018 at 12:37 AM, Clément Aubin  wrote:
> Hi,
>
> On 05/24/2018 05:15 PM, Eduard Moraru wrote:
>> Question:
>>e
>> Do we need the captcha module to function without the DB as well?
>>
>> This would make it more difficult to create the configuration UI (in
>> Administration) and would also mean that some captchas implementations
>> might not respect this constraint (i.e. choosing to implement their UI in a
>> wiki page instead).
>>
>> IMO, it's not really worth the trouble and we should proceed to extending
>> the current captcha module into 2 parts: -api and -ui (the current module
>> would be converted from "jar" to "pom" and the current code will be
>> deprecated and moved to the new -api module).
>
> The only reason we could not to depend on the DB would be to transfer
> parts of the captcha module to xwiki-commons IMO. For now, I don't see
> any particular use case that could support this migration.
>
>> Thanks,
>> Eduard
>>
>> On Tue, May 22, 2018 at 8:35 PM, Eduard Moraru  wrote:
>>
>>> Hi, devs,
>>>
>>> XWiki's current CAPTCHA module [1] is very old and outdated for a while
>>> now and this is not news for anyone.
>>>
>>> I see 2 major problems:
>>> 1) The obvious one is that we just need a technologically better CAPTCHA
>>> implementation that the current JCaptcha-based one and JCaptcha is
>>> discontinued.
>>> 2) The current architecture is outdated as well (i.e. wrapped around
>>> Struts actions and initializing the VelocityContext with a custom binding)
>>> and hard to use (i.e. you have to write your CAPTCHA UI every time you use
>>> it, there is no rendering helper).
>>>
>>> For 1), as both determined a few years ago [2] and also observed from
>>> practice, the industry standard is now Google's reCaptcha service (either
>>> its v2 or invisible version, or both), so we definitely need an
>>> implementation that makes it easy to use in XWiki [3].
>>>
>>> For 2), we need:
>>> * to allow CAPTCHA implementations to provide their own rendering
>>> ** Can be done using a template .vm file (rendered with the
>>> TemplateManager), a wiki page or directly from Java code.
>>> ** The implementation-specific parameters could be passed to
>>> control/customize a particular rendering.
>>> ** The syntax ID may not be needed, since the only relevant output would
>>> be html.
>>> * to move to a ScriptService-based system and to leave the resource
>>> (image/audio) accessing concern to the individual implementation (that may
>>> choose to continue with Struts actions, or may choose to use something
>>> lighter like a REST resource or even or even something more inventive, like
>>> temporary attachments on some fixed page).
>>> * an administration UI that configures the default CAPTCHA service and its
>>> configuration
>>> * to allow callers to use a different CAPTCHA than the default configured
>>> one, as long as it is available (i.e. installed)
>>>
>>> Examples:
>>>
>>> = Display
>>> $services.captcha.display() -- default implementation, current
>>> configuration
>>> $services.captcha.recaptcha.display() -- explicitly requested
>>> implementation, current/default configuration
>>> $services.captcha.recaptcha.display({'theme' : 'dark', 'size' :
>>> 'compact', 'sitekey' : 'xyz'}) -- explicitly requested implementation and
>>> custom configuration overwrites
>>> $services.captcha.jcaptcha.display() -- other implementation,
>>> current/default configuration
>>>
>>> = Verification
>>> $services.captcha.isValid() -- default implementation, current
>>> configuration
>>> $services.captcha.recaptcha.isValid() -- explicitly requested
>>> implementation, current/default configuration
>>> $services.captcha.recaptcha.isValid({'secret' : 'xyz'}) -- explicitly
>>> requested implementation and custom configuration overwrites
>>> $services.captcha.jcaptcha.isValid() -- explicitly requested
>>> implementation and custom configuration overwrites
>>>
>>> Basically, the ScriptService API would be highly simplified to just
>>> displaying and validating, while the components would consist of 2 parts:
>>> * a generic Manager for the various implementations (listing,
>>> getting/setting the default)
>>> * various implementations, each responsible with rendering a form-friendly
>>> CAPTCHA input and using the current request for extracting the information
>>> they needs to read the user's answer and validate it.
>>>
>>> WDYT?
>
> I do agree that JCaptcha is getting quite old now, however, we might
> have a hard time finding new FOSS and self-hosted captcha solutions (at
> least, there's not a lot of interesting artifacts on maven central [1]).
>
> IMO, we shouldn't rely on

Re: [xwiki-devs] [Proposal] CAPTCHA module refactoring

[Clément Aubin]

Hi,

On 05/24/2018 05:15 PM, Eduard Moraru wrote:
> Question:
> 
> Do we need the captcha module to function without the DB as well?
> 
> This would make it more difficult to create the configuration UI (in
> Administration) and would also mean that some captchas implementations
> might not respect this constraint (i.e. choosing to implement their UI in a
> wiki page instead).
> 
> IMO, it's not really worth the trouble and we should proceed to extending
> the current captcha module into 2 parts: -api and -ui (the current module
> would be converted from "jar" to "pom" and the current code will be
> deprecated and moved to the new -api module).

The only reason we could not to depend on the DB would be to transfer
parts of the captcha module to xwiki-commons IMO. For now, I don't see
any particular use case that could support this migration.

> Thanks,
> Eduard
> 
> On Tue, May 22, 2018 at 8:35 PM, Eduard Moraru  wrote:
> 
>> Hi, devs,
>>
>> XWiki's current CAPTCHA module [1] is very old and outdated for a while
>> now and this is not news for anyone.
>>
>> I see 2 major problems:
>> 1) The obvious one is that we just need a technologically better CAPTCHA
>> implementation that the current JCaptcha-based one and JCaptcha is
>> discontinued.
>> 2) The current architecture is outdated as well (i.e. wrapped around
>> Struts actions and initializing the VelocityContext with a custom binding)
>> and hard to use (i.e. you have to write your CAPTCHA UI every time you use
>> it, there is no rendering helper).
>>
>> For 1), as both determined a few years ago [2] and also observed from
>> practice, the industry standard is now Google's reCaptcha service (either
>> its v2 or invisible version, or both), so we definitely need an
>> implementation that makes it easy to use in XWiki [3].
>>
>> For 2), we need:
>> * to allow CAPTCHA implementations to provide their own rendering
>> ** Can be done using a template .vm file (rendered with the
>> TemplateManager), a wiki page or directly from Java code.
>> ** The implementation-specific parameters could be passed to
>> control/customize a particular rendering.
>> ** The syntax ID may not be needed, since the only relevant output would
>> be html.
>> * to move to a ScriptService-based system and to leave the resource
>> (image/audio) accessing concern to the individual implementation (that may
>> choose to continue with Struts actions, or may choose to use something
>> lighter like a REST resource or even or even something more inventive, like
>> temporary attachments on some fixed page).
>> * an administration UI that configures the default CAPTCHA service and its
>> configuration
>> * to allow callers to use a different CAPTCHA than the default configured
>> one, as long as it is available (i.e. installed)
>>
>> Examples:
>>
>> = Display
>> $services.captcha.display() -- default implementation, current
>> configuration
>> $services.captcha.recaptcha.display() -- explicitly requested
>> implementation, current/default configuration
>> $services.captcha.recaptcha.display({'theme' : 'dark', 'size' :
>> 'compact', 'sitekey' : 'xyz'}) -- explicitly requested implementation and
>> custom configuration overwrites
>> $services.captcha.jcaptcha.display() -- other implementation,
>> current/default configuration
>>
>> = Verification
>> $services.captcha.isValid() -- default implementation, current
>> configuration
>> $services.captcha.recaptcha.isValid() -- explicitly requested
>> implementation, current/default configuration
>> $services.captcha.recaptcha.isValid({'secret' : 'xyz'}) -- explicitly
>> requested implementation and custom configuration overwrites
>> $services.captcha.jcaptcha.isValid() -- explicitly requested
>> implementation and custom configuration overwrites
>>
>> Basically, the ScriptService API would be highly simplified to just
>> displaying and validating, while the components would consist of 2 parts:
>> * a generic Manager for the various implementations (listing,
>> getting/setting the default)
>> * various implementations, each responsible with rendering a form-friendly
>> CAPTCHA input and using the current request for extracting the information
>> they needs to read the user's answer and validate it.
>>
>> WDYT?

I do agree that JCaptcha is getting quite old now, however, we might
have a hard time finding new FOSS and self-hosted captcha solutions (at
least, there's not a lot of interesting artifacts on maven central [1]).

IMO, we shouldn't rely on a captcha using an external verification
service (such as Google's captchas) as we might end up blocking users
that access their wiki with a filtered / controlled internet access. One
option could be to provide a challenge which asks the user to perform a
simple math operation, or respond to a control question instead, but I'm
not convinced of the efficiency of those solutions against real
captchas. As a captcha is usually quite simple to implement (apply
operations on a text written in an image in order to ma

Re: [xwiki-devs] Activating Wiki on a single host in fleet clears security cache for entire fleet

[ktc]

Hi Denis,

Thank you for your reply! We found out the reason is a document called
XWiki.XWikiServerXwiki whose title is empty. During the XWiki initialization
in 8.4.4 version(the version we use),  setDocumentFields

  
will mark the document as needsUpdate if the title is blank(It only has
StringUtils.isBlank(document.getTitle()) in if statement for 8.4.4 version).
So it will then remove the security cache and cause the issue. 

For the fix, we plan to add a title for XWiki.XWikiServerXwiki page, which
solved the issue in beta testing. Right now we didn't see any problem except
it will remove the security caches once more. Do you think it's safe doing
that? Thanks! 



--
Sent from: http://xwiki.475771.n2.nabble.com/XWiki-Dev-f475773.html

Re: [xwiki-devs] [Proposal] CAPTCHA module refactoring

[Eduard Moraru]

Question:

Do we need the captcha module to function without the DB as well?

This would make it more difficult to create the configuration UI (in
Administration) and would also mean that some captchas implementations
might not respect this constraint (i.e. choosing to implement their UI in a
wiki page instead).

IMO, it's not really worth the trouble and we should proceed to extending
the current captcha module into 2 parts: -api and -ui (the current module
would be converted from "jar" to "pom" and the current code will be
deprecated and moved to the new -api module).

Thanks,
Eduard

On Tue, May 22, 2018 at 8:35 PM, Eduard Moraru  wrote:

> Hi, devs,
>
> XWiki's current CAPTCHA module [1] is very old and outdated for a while
> now and this is not news for anyone.
>
> I see 2 major problems:
> 1) The obvious one is that we just need a technologically better CAPTCHA
> implementation that the current JCaptcha-based one and JCaptcha is
> discontinued.
> 2) The current architecture is outdated as well (i.e. wrapped around
> Struts actions and initializing the VelocityContext with a custom binding)
> and hard to use (i.e. you have to write your CAPTCHA UI every time you use
> it, there is no rendering helper).
>
> For 1), as both determined a few years ago [2] and also observed from
> practice, the industry standard is now Google's reCaptcha service (either
> its v2 or invisible version, or both), so we definitely need an
> implementation that makes it easy to use in XWiki [3].
>
> For 2), we need:
> * to allow CAPTCHA implementations to provide their own rendering
> ** Can be done using a template .vm file (rendered with the
> TemplateManager), a wiki page or directly from Java code.
> ** The implementation-specific parameters could be passed to
> control/customize a particular rendering.
> ** The syntax ID may not be needed, since the only relevant output would
> be html.
> * to move to a ScriptService-based system and to leave the resource
> (image/audio) accessing concern to the individual implementation (that may
> choose to continue with Struts actions, or may choose to use something
> lighter like a REST resource or even or even something more inventive, like
> temporary attachments on some fixed page).
> * an administration UI that configures the default CAPTCHA service and its
> configuration
> * to allow callers to use a different CAPTCHA than the default configured
> one, as long as it is available (i.e. installed)
>
> Examples:
>
> = Display
> $services.captcha.display() -- default implementation, current
> configuration
> $services.captcha.recaptcha.display() -- explicitly requested
> implementation, current/default configuration
> $services.captcha.recaptcha.display({'theme' : 'dark', 'size' :
> 'compact', 'sitekey' : 'xyz'}) -- explicitly requested implementation and
> custom configuration overwrites
> $services.captcha.jcaptcha.display() -- other implementation,
> current/default configuration
>
> = Verification
> $services.captcha.isValid() -- default implementation, current
> configuration
> $services.captcha.recaptcha.isValid() -- explicitly requested
> implementation, current/default configuration
> $services.captcha.recaptcha.isValid({'secret' : 'xyz'}) -- explicitly
> requested implementation and custom configuration overwrites
> $services.captcha.jcaptcha.isValid() -- explicitly requested
> implementation and custom configuration overwrites
>
> Basically, the ScriptService API would be highly simplified to just
> displaying and validating, while the components would consist of 2 parts:
> * a generic Manager for the various implementations (listing,
> getting/setting the default)
> * various implementations, each responsible with rendering a form-friendly
> CAPTCHA input and using the current request for extracting the information
> they needs to read the user's answer and validate it.
>
> WDYT?
>
> Thanks,
> Eduard
>
> --
> [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Captcha%20Module
> [2] http://design.xwiki.org/xwiki/bin/view/Proposal/CAPTCHAinvestigation70
> [3] https://jira.xwiki.org/browse/XWIKI-12964
>

Re: [xwiki-devs] [Translation] Translation migration

[Adel Atallah]

I fixed some issues you could find on the previous test commit. Here is the
new one

.

On Thu, May 24, 2018 at 2:33 PM, Adel Atallah 
wrote:
>
> On Thu, May 24, 2018 at 2:27 PM, Vincent Massol 
wrote:
> > Hi,
> >
> >> On 24 May 2018, at 13:58, Adel Atallah  wrote:
> >>
> >> Hi,
> >>
> >> To fix some issues we have, we want to transform translation files so
that
> >> they have the same structure as the english base translation file.
> >
> > As discussed together, I think it’s a very good idea that solves a lot
of issues we have ATM.
> >
> >> You can have a look at this test commit
> >> <
https://github.com/atallahade/xwiki-platform/commit/5b89e1d2fd856af58b68b3ba446948ec3de6930d
>
> >> to
> >> see what the migration is about.
> >> You obviously don't have to check every changes but if you manage to
find
> >> something wrong somewhere, please let us know here.
> >> We will lock the translations on l10.xwiki.org and do the migration
once we
> >> know for sure that it will not create other issues.
> >>
> >> Also, be aware that future translations added to the platform will
> >> automatically be changed as soon as a first modification is made by a
user.
> >
> > I think this is acceptable. It’ll cause some PRs with non-user-related
changes but it’s ok (I hope those changes will be done under the xwiki
weblate user and not under the user who’ll have contributed new
translations though ;)).
>
> In this case, these changes will be committed with the changes of the
> weblate user. We can avoid that by manually committed the "migrated"
> translations just after we add new translations or automatically with
> a script (but we still need to figure out how we add new translations
> to the platform).
>
> >
> > Thanks
> > -Vincent
> >
> >>
> >> Thanks,
> >> Adel
> >

Re: [xwiki-devs] [Translation] Translation migration

[Adel Atallah]

On Thu, May 24, 2018 at 2:27 PM, Vincent Massol  wrote:
> Hi,
>
>> On 24 May 2018, at 13:58, Adel Atallah  wrote:
>>
>> Hi,
>>
>> To fix some issues we have, we want to transform translation files so that
>> they have the same structure as the english base translation file.
>
> As discussed together, I think it’s a very good idea that solves a lot of 
> issues we have ATM.
>
>> You can have a look at this test commit
>> 
>> to
>> see what the migration is about.
>> You obviously don't have to check every changes but if you manage to find
>> something wrong somewhere, please let us know here.
>> We will lock the translations on l10.xwiki.org and do the migration once we
>> know for sure that it will not create other issues.
>>
>> Also, be aware that future translations added to the platform will
>> automatically be changed as soon as a first modification is made by a user.
>
> I think this is acceptable. It’ll cause some PRs with non-user-related 
> changes but it’s ok (I hope those changes will be done under the xwiki 
> weblate user and not under the user who’ll have contributed new translations 
> though ;)).

In this case, these changes will be committed with the changes of the
weblate user. We can avoid that by manually committed the "migrated"
translations just after we add new translations or automatically with
a script (but we still need to figure out how we add new translations
to the platform).

>
> Thanks
> -Vincent
>
>>
>> Thanks,
>> Adel
>

Re: [xwiki-devs] [Translation] Translation migration

[Vincent Massol]

Hi,

> On 24 May 2018, at 13:58, Adel Atallah  wrote:
> 
> Hi,
> 
> To fix some issues we have, we want to transform translation files so that
> they have the same structure as the english base translation file.

As discussed together, I think it’s a very good idea that solves a lot of 
issues we have ATM.

> You can have a look at this test commit
> 
> to
> see what the migration is about.
> You obviously don't have to check every changes but if you manage to find
> something wrong somewhere, please let us know here.
> We will lock the translations on l10.xwiki.org and do the migration once we
> know for sure that it will not create other issues.
> 
> Also, be aware that future translations added to the platform will
> automatically be changed as soon as a first modification is made by a user.

I think this is acceptable. It’ll cause some PRs with non-user-related changes 
but it’s ok (I hope those changes will be done under the xwiki weblate user and 
not under the user who’ll have contributed new translations though ;)).

Thanks
-Vincent

> 
> Thanks,
> Adel

Re: [xwiki-devs] [Proposal] XS 10.7 roadmap on BFD+Test

[Clément Aubin]

+1

Thanks,
Clément

On 05/24/2018 10:48 AM, Eduard Moraru wrote:
> +1
> 
> Thanks,
> Eduard
> 
> On Thu, May 24, 2018 at 11:20 AM, Thomas Mortagne > wrote:
> 
>> +1
>>
>> On Thu, May 24, 2018 at 9:34 AM, Vincent Massol 
>> wrote:
>>> Hi devs,
>>>
>>> We’re having a tough time maintaining the quality of XWiki Standard
>> these days (not enough people).
>>>
>>> We used to be able to contain bugs and have as many bugs closed than
>> created over 1600 days. We’ve now slipped back to 330+ bugs that have been
>> opened vs created over 1600 days. +116 over 500 days. +96 over 365 days.
>> And +49 over 120 days. BFD days have little impact with that many bugs
>> (since there are about 1-2 devs participating to XS’s BFDs).
>>>
>>> In addition I’ve measure our Test Coverage since end of 2017 and we’ve
>> lost coverage compared to before which is really bad (see my other emails).
>> In short this means that we’re hurrying to finish work from the roadmaps
>> without taking enough time to write the proper tests. This will have an
>> important impact in the future if we don’t react.
>>>
>>> Thus I’d like to propose that we spend the XS 10.7 roadmap (1 month in
>> August) on bug fixing and writing more tests. It’ll probably not be enough
>> but it’ll help a lot.
>>>
>>> Let me know if someone has a counter-proposal or an issue with this
>> proposal.
>>>
>>> Thanks
>>> -Vincent
>>
>>
>>
>> --
>> Thomas Mortagne
>>

[xwiki-devs] [Translation] Translation migration

[Adel Atallah]

Hi,

To fix some issues we have, we want to transform translation files so that
they have the same structure as the english base translation file.
You can have a look at this test commit

to
see what the migration is about.
You obviously don't have to check every changes but if you manage to find
something wrong somewhere, please let us know here.

We will lock the translations on l10.xwiki.org and do the migration once we
know for sure that it will not create other issues.

Also, be aware that future translations added to the platform will
automatically be changed as soon as a first modification is made by a user.

Thanks,
Adel

Re: [xwiki-devs] [Proposal] XS 10.7 roadmap on BFD+Test

[Eduard Moraru]

+1

Thanks,
Eduard

On Thu, May 24, 2018 at 11:20 AM, Thomas Mortagne  wrote:

> +1
>
> On Thu, May 24, 2018 at 9:34 AM, Vincent Massol 
> wrote:
> > Hi devs,
> >
> > We’re having a tough time maintaining the quality of XWiki Standard
> these days (not enough people).
> >
> > We used to be able to contain bugs and have as many bugs closed than
> created over 1600 days. We’ve now slipped back to 330+ bugs that have been
> opened vs created over 1600 days. +116 over 500 days. +96 over 365 days.
> And +49 over 120 days. BFD days have little impact with that many bugs
> (since there are about 1-2 devs participating to XS’s BFDs).
> >
> > In addition I’ve measure our Test Coverage since end of 2017 and we’ve
> lost coverage compared to before which is really bad (see my other emails).
> In short this means that we’re hurrying to finish work from the roadmaps
> without taking enough time to write the proper tests. This will have an
> important impact in the future if we don’t react.
> >
> > Thus I’d like to propose that we spend the XS 10.7 roadmap (1 month in
> August) on bug fixing and writing more tests. It’ll probably not be enough
> but it’ll help a lot.
> >
> > Let me know if someone has a counter-proposal or an issue with this
> proposal.
> >
> > Thanks
> > -Vincent
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [Proposal] XS 10.7 roadmap on BFD+Test

[Guillaume Delhumeau]

+1

2018-05-24 10:20 GMT+02:00 Thomas Mortagne :

> +1
>
> On Thu, May 24, 2018 at 9:34 AM, Vincent Massol 
> wrote:
> > Hi devs,
> >
> > We’re having a tough time maintaining the quality of XWiki Standard
> these days (not enough people).
> >
> > We used to be able to contain bugs and have as many bugs closed than
> created over 1600 days. We’ve now slipped back to 330+ bugs that have been
> opened vs created over 1600 days. +116 over 500 days. +96 over 365 days.
> And +49 over 120 days. BFD days have little impact with that many bugs
> (since there are about 1-2 devs participating to XS’s BFDs).
> >
> > In addition I’ve measure our Test Coverage since end of 2017 and we’ve
> lost coverage compared to before which is really bad (see my other emails).
> In short this means that we’re hurrying to finish work from the roadmaps
> without taking enough time to write the proper tests. This will have an
> important impact in the future if we don’t react.
> >
> > Thus I’d like to propose that we spend the XS 10.7 roadmap (1 month in
> August) on bug fixing and writing more tests. It’ll probably not be enough
> but it’ll help a lot.
> >
> > Let me know if someone has a counter-proposal or an issue with this
> proposal.
> >
> > Thanks
> > -Vincent
>
>
>
> --
> Thomas Mortagne
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Proposal] XS 10.7 roadmap on BFD+Test

[Thomas Mortagne]

+1

On Thu, May 24, 2018 at 9:34 AM, Vincent Massol  wrote:
> Hi devs,
>
> We’re having a tough time maintaining the quality of XWiki Standard these 
> days (not enough people).
>
> We used to be able to contain bugs and have as many bugs closed than created 
> over 1600 days. We’ve now slipped back to 330+ bugs that have been opened vs 
> created over 1600 days. +116 over 500 days. +96 over 365 days. And +49 over 
> 120 days. BFD days have little impact with that many bugs (since there are 
> about 1-2 devs participating to XS’s BFDs).
>
> In addition I’ve measure our Test Coverage since end of 2017 and we’ve lost 
> coverage compared to before which is really bad (see my other emails). In 
> short this means that we’re hurrying to finish work from the roadmaps without 
> taking enough time to write the proper tests. This will have an important 
> impact in the future if we don’t react.
>
> Thus I’d like to propose that we spend the XS 10.7 roadmap (1 month in 
> August) on bug fixing and writing more tests. It’ll probably not be enough 
> but it’ll help a lot.
>
> Let me know if someone has a counter-proposal or an issue with this proposal.
>
> Thanks
> -Vincent



-- 
Thomas Mortagne

Re: [xwiki-devs] [Proposal] XS 10.7 roadmap on BFD+Test

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Thu, May 24, 2018 at 7:34 AM, Vincent Massol  wrote:

> Hi devs,
>
> We’re having a tough time maintaining the quality of XWiki Standard these
> days (not enough people).
>
> We used to be able to contain bugs and have as many bugs closed than
> created over 1600 days. We’ve now slipped back to 330+ bugs that have been
> opened vs created over 1600 days. +116 over 500 days. +96 over 365 days.
> And +49 over 120 days. BFD days have little impact with that many bugs
> (since there are about 1-2 devs participating to XS’s BFDs).
>
> In addition I’ve measure our Test Coverage since end of 2017 and we’ve
> lost coverage compared to before which is really bad (see my other emails).
> In short this means that we’re hurrying to finish work from the roadmaps
> without taking enough time to write the proper tests. This will have an
> important impact in the future if we don’t react.
>
> Thus I’d like to propose that we spend the XS 10.7 roadmap (1 month in
> August) on bug fixing and writing more tests. It’ll probably not be enough
> but it’ll help a lot.
>
> Let me know if someone has a counter-proposal or an issue with this
> proposal.
>
> Thanks
> -Vincent

[xwiki-devs] [Proposal] XS 10.7 roadmap on BFD+Test

[Vincent Massol]

Hi devs,

We’re having a tough time maintaining the quality of XWiki Standard these days 
(not enough people).

We used to be able to contain bugs and have as many bugs closed than created 
over 1600 days. We’ve now slipped back to 330+ bugs that have been opened vs 
created over 1600 days. +116 over 500 days. +96 over 365 days. And +49 over 120 
days. BFD days have little impact with that many bugs (since there are about 
1-2 devs participating to XS’s BFDs).

In addition I’ve measure our Test Coverage since end of 2017 and we’ve lost 
coverage compared to before which is really bad (see my other emails). In short 
this means that we’re hurrying to finish work from the roadmaps without taking 
enough time to write the proper tests. This will have an important impact in 
the future if we don’t react. 

Thus I’d like to propose that we spend the XS 10.7 roadmap (1 month in August) 
on bug fixing and writing more tests. It’ll probably not be enough but it’ll 
help a lot.

Let me know if someone has a counter-proposal or an issue with this proposal.

Thanks
-Vincent

[xwiki-devs] [XWiki Day] BFD#178

[Alex Cotiugă]

Hello devs,

This Thursday is BFD#178:
http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays

Our current status is:
* -59 bugs over 120 days (4 months), i.e. we need to close 59 bugs to have
created bugs # = closed bugs #
* -96 bugs over 365 days (1 year)
* -131 bugs over 500 days (between 1 and 2 years)
* -310 bugs over 1600 days (4.3 years)

See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352

Here's the BFD#178 dashboard to follow the progress during the day:
https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14298

Happy Bug Fixing Day,
Alex