[xwiki-devs] [GSOC] XWiki is applying for GSoC 2018. Proposals and mentors needed!

2018-01-12 Thread Eduard Moraru 
Hello fellow XWiki community members,

This year XWiki is planning to participate once more at Google's Summer of
Code [1].

The organization registration period has already started (January 4, 2018)
and the deadline is
January 23, 2018 [2] (in 1.5 weeks).

1. We need to provide by then a list of proposals and assign mentors for
the students that are going to implement them.

I would like to ask everybody that wants to participate as a mentor from
the XWiki organization to review the proposals [3] list (when projects are
being added) and add as many interesting proposals as possible.
The proposals can be either new, or they can be revived from previous
years. Just navigate to the previous years [4], find the proposal you like
and know about, go to its proposal page (click it) and press the "Clone to
this year" link. Now you can assign yourself as lead for that project,
update it's description if needed and wait for the student applications to
start pouring

2. We also need to submit the actual application [5] of the XWiki
organization to participate to the GSoC 2018 project so I would also like
to ask you to review it so that we have a better chance of being selected
into the program.

3. If you feel that you would like to help on improving XWiki's GSoC guides
and application forms, please find tips for students [6] on XWiki's GSoC
page, the student application form [7] and the lessons learned [8] from
previous years participations.

Thanks for your help,
Eduard

--

[1] https://summerofcode.withgoogle.com/
[2] https://summerofcode.withgoogle.com/how-it-works/#timeline
[3]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/#HProposedProjects2829
[4]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HPreviousGSoCeditions
[5]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/OrganizationApplicationForm
[6] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines
[7]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/student+application+form
[8] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/LessonsLearned

Re: [xwiki-devs] [Proposal] [CodeStyle] Committing XML wiki page date changes

2018-01-12 Thread Thomas Mortagne 
On Fri, Jan 12, 2018 at 1:50 PM, Eduard Moraru  wrote:
> Hi devs,
>
> These are the current code style rules for committed XML wiki pages:
> http://dev.xwiki.org/xwiki/bin/view/Community/XWikiXMLFilesCodeStyle
>
> = Proposal 1 =
>
> I was personally not aware we had documented these practices that we had
> been applying since forever. It's good that we have them, but there seems
> to be no mention about committing changes for the "creationDate", "date"
> and "contentUpdateDate" fields.
>
> Part of the committers (including myself) are applying the old practice of
> omitting changes to the date fields when committing a change to an XML wiki
> page. However, since this practice is not written and agreed upon, its
> usage is not consistent.
>
> So, the proposal is to include the rule of not committing changes on the
> date fields of XML wiki pages.
>
> The rationale, AFAIR, includes:
> * After an upgrade, users should not see "ghost" modifications in their
> wiki (e.g. when sorting by date in the Page Index). This affects even more
> manual imports with the "as backup" option enabled.
> * On release, any date changes of a default translation XML page will
> produce N other XML page changes, for each translation of the modified page
> (due to the way l10n exports the translations based on the latest version
> of the default language of that page).
> * others?
>
> = Proposal 2 =
>
> Now, building on this, I would like to make a second proposal (which I
> don't believe deserves a separate thread):
> 1) Let's remove all date fields from committed XML wiki pages in our source
> repository
> 2) Let's make sure that the XAR import properly handles empty or missing
> date fields and falls back on the current date

XAR input filter supports both but I don't see the point in having an
empty date, better remove it.

> 3) Let's update the xar:format goal to remove the date fields
> (configurable, since it could they might still be needed by some content
> projects, etc.)
> 4) Let's make the build fail (xar:verify) if the XML wiki pages contain
> date fields (again configurable, as above)
>
> Note: All the above still depend on the first proposal of not committing
> date changes to XML files (which will be simplified by point 3) above).
>
> The rationale for this is that we have always wanted to fix our "dates
> problem", since after installation, the wiki is populated with pages
> created in 2009, which is extremely odd to users that have just installed
> XWiki. This second proposal sounds to me like a solution for that.
>
> WDYT?
>
> Thanks,
> Eduard

- 1 for proposal 1 alone
+1 with proposal 2

I don't care too much about update date vs not update date but we
should not have to do any manual cleaning when exporting a page. So in
short I'm against anything not handled by xar:format.

(by the way http://dev.xwiki.org/xwiki/bin/view/Community/XWikiXMLFilesCodeStyle
is not fully up to date since what is indicated for defaultLanguage is
not true in case of translations)

-- 
Thomas Mortagne

Re: [xwiki-devs] [Proposal] [CodeStyle] Committing XML wiki page date changes

2018-01-12 Thread Alex Cotiugă 
I also agree with your proposals, it's better to have some tools to handle
date changes
instead of asking any contributor to exclude them from commits.

Thanks,
Alex

On Fri, Jan 12, 2018 at 3:49 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> +1 to both proposals.
>
> Thanks,
> Marius
>
> On Fri, Jan 12, 2018 at 2:50 PM, Eduard Moraru 
> wrote:
>
> > Hi devs,
> >
> > These are the current code style rules for committed XML wiki pages:
> > http://dev.xwiki.org/xwiki/bin/view/Community/XWikiXMLFilesCodeStyle
> >
> > = Proposal 1 =
> >
> > I was personally not aware we had documented these practices that we had
> > been applying since forever. It's good that we have them, but there seems
> > to be no mention about committing changes for the "creationDate", "date"
> > and "contentUpdateDate" fields.
> >
> > Part of the committers (including myself) are applying the old practice
> of
> > omitting changes to the date fields when committing a change to an XML
> wiki
> > page. However, since this practice is not written and agreed upon, its
> > usage is not consistent.
> >
> > So, the proposal is to include the rule of not committing changes on the
> > date fields of XML wiki pages.
> >
> > The rationale, AFAIR, includes:
> > * After an upgrade, users should not see "ghost" modifications in their
> > wiki (e.g. when sorting by date in the Page Index). This affects even
> more
> > manual imports with the "as backup" option enabled.
> > * On release, any date changes of a default translation XML page will
> > produce N other XML page changes, for each translation of the modified
> page
> > (due to the way l10n exports the translations based on the latest version
> > of the default language of that page).
> > * others?
> >
> > = Proposal 2 =
> >
> > Now, building on this, I would like to make a second proposal (which I
> > don't believe deserves a separate thread):
> > 1) Let's remove all date fields from committed XML wiki pages in our
> source
> > repository
> > 2) Let's make sure that the XAR import properly handles empty or missing
> > date fields and falls back on the current date
> > 3) Let's update the xar:format goal to remove the date fields
> > (configurable, since it could they might still be needed by some content
> > projects, etc.)
> > 4) Let's make the build fail (xar:verify) if the XML wiki pages contain
> > date fields (again configurable, as above)
> >
> > Note: All the above still depend on the first proposal of not committing
> > date changes to XML files (which will be simplified by point 3) above).
> >
> > The rationale for this is that we have always wanted to fix our "dates
> > problem", since after installation, the wiki is populated with pages
> > created in 2009, which is extremely odd to users that have just installed
> > XWiki. This second proposal sounds to me like a solution for that.
> >
> > WDYT?
> >
> > Thanks,
> > Eduard
> >
>

Re: [xwiki-devs] [Proposal] [CodeStyle] Committing XML wiki page date changes

2018-01-12 Thread Marius Dumitru Florea 
+1 to both proposals.

Thanks,
Marius

On Fri, Jan 12, 2018 at 2:50 PM, Eduard Moraru  wrote:

> Hi devs,
>
> These are the current code style rules for committed XML wiki pages:
> http://dev.xwiki.org/xwiki/bin/view/Community/XWikiXMLFilesCodeStyle
>
> = Proposal 1 =
>
> I was personally not aware we had documented these practices that we had
> been applying since forever. It's good that we have them, but there seems
> to be no mention about committing changes for the "creationDate", "date"
> and "contentUpdateDate" fields.
>
> Part of the committers (including myself) are applying the old practice of
> omitting changes to the date fields when committing a change to an XML wiki
> page. However, since this practice is not written and agreed upon, its
> usage is not consistent.
>
> So, the proposal is to include the rule of not committing changes on the
> date fields of XML wiki pages.
>
> The rationale, AFAIR, includes:
> * After an upgrade, users should not see "ghost" modifications in their
> wiki (e.g. when sorting by date in the Page Index). This affects even more
> manual imports with the "as backup" option enabled.
> * On release, any date changes of a default translation XML page will
> produce N other XML page changes, for each translation of the modified page
> (due to the way l10n exports the translations based on the latest version
> of the default language of that page).
> * others?
>
> = Proposal 2 =
>
> Now, building on this, I would like to make a second proposal (which I
> don't believe deserves a separate thread):
> 1) Let's remove all date fields from committed XML wiki pages in our source
> repository
> 2) Let's make sure that the XAR import properly handles empty or missing
> date fields and falls back on the current date
> 3) Let's update the xar:format goal to remove the date fields
> (configurable, since it could they might still be needed by some content
> projects, etc.)
> 4) Let's make the build fail (xar:verify) if the XML wiki pages contain
> date fields (again configurable, as above)
>
> Note: All the above still depend on the first proposal of not committing
> date changes to XML files (which will be simplified by point 3) above).
>
> The rationale for this is that we have always wanted to fix our "dates
> problem", since after installation, the wiki is populated with pages
> created in 2009, which is extremely odd to users that have just installed
> XWiki. This second proposal sounds to me like a solution for that.
>
> WDYT?
>
> Thanks,
> Eduard
>

Re: [xwiki-devs] [XWiki Day] BFD#161

2018-01-12 Thread Alex Cotiugă 
Results: http://www.xwiki.org/xwiki/bin/view/Blog/Bug%20Fixing%20Day%20161.

Thanks,
Alex

On Thu, Jan 11, 2018 at 9:10 AM, Alex Cotiugă 
wrote:

> Hello devs,
>
> This Thursday is BFD#161:
> http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays
>
> Our current status is:
>
> * -3 bugs over 120 days (4 months), i.e. we need to close 3 bugs to have
> created bugs # = closed bugs #
> * -74 bugs over 365 days (1 year)
> * -48 bugs over 500 days (between 1 and 2 years)
> * -242 bugs over 1600 days (4.3 years)
> * -688 bugs since the beginning of XWiki
>
> See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
>
>
> Here's the BFD#161 dashboard to follow the progress during the day:
> https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13941
>
> Happy Bug Fixing Day,
> Alex
>

[xwiki-devs] [Proposal] [CodeStyle] Committing XML wiki page date changes

2018-01-12 Thread Eduard Moraru 
Hi devs,

These are the current code style rules for committed XML wiki pages:
http://dev.xwiki.org/xwiki/bin/view/Community/XWikiXMLFilesCodeStyle

= Proposal 1 =

I was personally not aware we had documented these practices that we had
been applying since forever. It's good that we have them, but there seems
to be no mention about committing changes for the "creationDate", "date"
and "contentUpdateDate" fields.

Part of the committers (including myself) are applying the old practice of
omitting changes to the date fields when committing a change to an XML wiki
page. However, since this practice is not written and agreed upon, its
usage is not consistent.

So, the proposal is to include the rule of not committing changes on the
date fields of XML wiki pages.

The rationale, AFAIR, includes:
* After an upgrade, users should not see "ghost" modifications in their
wiki (e.g. when sorting by date in the Page Index). This affects even more
manual imports with the "as backup" option enabled.
* On release, any date changes of a default translation XML page will
produce N other XML page changes, for each translation of the modified page
(due to the way l10n exports the translations based on the latest version
of the default language of that page).
* others?

= Proposal 2 =

Now, building on this, I would like to make a second proposal (which I
don't believe deserves a separate thread):
1) Let's remove all date fields from committed XML wiki pages in our source
repository
2) Let's make sure that the XAR import properly handles empty or missing
date fields and falls back on the current date
3) Let's update the xar:format goal to remove the date fields
(configurable, since it could they might still be needed by some content
projects, etc.)
4) Let's make the build fail (xar:verify) if the XML wiki pages contain
date fields (again configurable, as above)

Note: All the above still depend on the first proposal of not committing
date changes to XML files (which will be simplified by point 3) above).

The rationale for this is that we have always wanted to fix our "dates
problem", since after installation, the wiki is populated with pages
created in 2009, which is extremely odd to users that have just installed
XWiki. This second proposal sounds to me like a solution for that.

WDYT?

Thanks,
Eduard