12 Jan
2018
12 Jan
'18
1:50 p.m.
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
12 Jan
12 Jan
2:49 p.m.
New subject: [xwiki-devs] [Proposal] [CodeStyle] Committing XML wiki page date changes
+1 to both proposals.
Thanks,
Marius
On Fri, Jan 12, 2018 at 2:50 PM, Eduard Moraru <enygma2002(a)gmail.com> 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
2:52 p.m.
New subject: [xwiki-devs] [Proposal] [CodeStyle] Committing XML wiki page date changes
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.florea(a)xwiki.com> wrote:
+1 to both proposals.
Thanks,
Marius
On Fri, Jan 12, 2018 at 2:50 PM, Eduard Moraru <enygma2002(a)gmail.com>
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
4:04 p.m.
New subject: [xwiki-devs] [Proposal] [CodeStyle] Committing XML wiki page date changes
On Fri, Jan 12, 2018 at 1:50 PM, Eduard Moraru <enygma2002(a)gmail.com> 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
13 Jan
13 Jan
3:16 p.m.
New subject: [xwiki-devs] [Proposal] [CodeStyle] Committing XML wiki page date changes
Same as Thomas.
--
Denis Gervalle
SOFTEC sa - CEO
Le 12 janv. 2018 à 16:04 +0100, Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>, a écrit
:
On Fri, Jan 12, 2018 at 1:50 PM, Eduard Moraru
<enygma2002(a)gmail.com> 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 
15 Jan
15 Jan
10:45 a.m.
New subject: [xwiki-devs] [Proposal] [CodeStyle] Committing XML wiki page date changes
+1 P2
Thanks,
Caty
On Sat, Jan 13, 2018 at 4:16 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
Same as Thomas.
--
Denis Gervalle
SOFTEC sa - CEO
Le 12 janv. 2018 à 16:04 +0100, Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>,
a écrit :
content
XWikiXMLFilesCodeStyle
On Fri, Jan 12, 2018 at 1:50 PM, Eduard Moraru
<enygma2002(a)gmail.com>
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 > 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/ is not fully up to date since what is indicated
for defaultLanguage is
not true in case of translations)
--
Thomas Mortagne
10:47 a.m.
New subject: [xwiki-devs] [Proposal] [CodeStyle] Committing XML wiki page date changes
Same as Thomas too.
Thanks
-Vincent
On 12 Jan 2018, at 13:50, Eduard Moraru
<enygma2002(a)gmail.com> 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
2:23 p.m.
New subject: [xwiki-devs] [Proposal] [CodeStyle] Committing XML wiki page date changes
+1 for both
2018-01-15 10:47 GMT+01:00 Vincent Massol <vincent(a)massol.net>et>:
Same as Thomas too.
Thanks
-Vincent
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
On 12 Jan 2018, at 13:50, Eduard Moraru
<enygma2002(a)gmail.com> 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
2533
days inactive
2536
days old
7 comments
8 participants
participants (8)
-
Alex Cotiugă -
Denis Gervalle -
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol