3 Dec
2014
3 Dec
'14
3:57 p.m.
Hi committers (and devs in general),
I’m submitting to you this idea, to try to improve the xwiki open source project and to
give it a new dynamism. I believe the topics discussed below are made even more important
since we’re soon going to develop the notion of flavors in XWiki.
Note that this proposal obsoletes the http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of some extensions in the xwiki github organization), which itself
was obsoleting http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the xwiki github organization, the less easy it
is for non-“XWiki Dev Team” committers to participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github organization by only
keeping “core” modules
* A “core" module is defined by being a generic transversal module (i.e. that can be
used in lots of XWiki flavors, if not all). This is opposed to “vertical” modules which
are modules specific of a usage of XWiki.
** Examples of “core" modules: logging module, configuration module, distribution
wizard, statistics application, annotations, active installs, one base flavor (the “XWiki”
flavor), etc
** Example of “vertical” modules: meeting manager application, blog application, FAQ
application, flavors (except the base flavor), etc
Some consequences:
* We need a new location for several modules that would go out of the xwiki github
organization repos
* It would be good to separate sandbox extensions from 1st class extensions that are
maintained and developed following best practices. We need some way to maintain the
quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core” (it’s too complex to
rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in there are called
“XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github organizations (technically we rename it to
“xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed extensions or
abandoned extensions are located
** “xwiki-contrib-extensions”, where maintained extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would be granted one and
he/she’d be given write access to all repos in the xwiki-contrib-sandbox organization.
* We define some rules for graduating from xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in xwiki-contrib-sandbox at least 6 months (this gives
time to see if the extension is maintained during that time and will survive the test of
time - most extensions will die in the first months)
** The extension should have had more than 2 releases and be published on
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
** The extension should work with the latest LTS version of XWiki + the latest stable
version of XWiki (right now that would be 5.4.5 + 6.3). Note that if the extension has to
use new API it’s ok that it doesn’t work on the latest LTS.
** Generally follow the practices defined at http://dev.xwiki.org
* Each extension in xwiki-extensions has a leader/maintainer. He/she’s the one proposing
to move the extension from xwiki-sandbox to xwiki-extensions. He/she’s responsible for
ensuring that the extension gets regular releases and is maintained in general. He/she
defines initially the list of committers in his email proposal for moving the extension.
* We create a PMC (Project Management Committee) for XWiki Contrib, generally in charge of
both xwiki-contrib-sandbox and xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I would send a mail
on devs@ asking who’s interested to be part of this committee. I expect some core
committers + some contrib committers to stand up.
* Contrib extensions keep using the org.xwiki.contrib package name and groupid as
currently defined at http://contrib.xwiki.org
Note: The idea is that xwiki core is developed as a team maintaining all code in there,
xwiki contrib is developed extension by extension (each extension is an island). This
allows anyone to propose extensions in XWiki Contrib without the need for everyone to
support them.
WDYT?
Thanks
-Vincent
3 Dec
3 Dec
4:16 p.m.
Sounds good. +1
On Wed, Dec 3, 2014 at 3:57 PM, vincent(a)massol.net <vincent(a)massol.net> wrote:
Hi committers (and devs in general),
I’m submitting to you this idea, to try to improve the xwiki open source project and to
give it a new dynamism. I believe the topics discussed below are made even more important
since we’re soon going to develop the notion of flavors in XWiki.
Note that this proposal obsoletes the http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of some extensions in the xwiki github organization), which itself
was obsoleting http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the xwiki github organization, the less easy
it is for non-“XWiki Dev Team” committers to participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github organization by only
keeping “core” modules
* A “core" module is defined by being a generic transversal module (i.e. that can be
used in lots of XWiki flavors, if not all). This is opposed to “vertical” modules which
are modules specific of a usage of XWiki.
** Examples of “core" modules: logging module, configuration module, distribution
wizard, statistics application, annotations, active installs, one base flavor (the “XWiki”
flavor), etc
** Example of “vertical” modules: meeting manager application, blog application, FAQ
application, flavors (except the base flavor), etc
Some consequences:
* We need a new location for several modules that would go out of the xwiki github
organization repos
* It would be good to separate sandbox extensions from 1st class extensions that are
maintained and developed following best practices. We need some way to maintain the
quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core” (it’s too complex to
rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in there are called
“XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github organizations (technically we rename it to
“xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed extensions or
abandoned extensions are located
** “xwiki-contrib-extensions”, where maintained extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would be granted one and
he/she’d be given write access to all repos in the xwiki-contrib-sandbox organization.
* We define some rules for graduating from xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in xwiki-contrib-sandbox at least 6 months (this gives
time to see if the extension is maintained during that time and will survive the test of
time - most extensions will die in the first months)
** The extension should have had more than 2 releases and be published on
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
** The extension should work with the latest LTS version of XWiki + the latest stable
version of XWiki (right now that would be 5.4.5 + 6.3). Note that if the extension has to
use new API it’s ok that it doesn’t work on the latest LTS.
** Generally follow the practices defined at http://dev.xwiki.org
* Each extension in xwiki-extensions has a leader/maintainer. He/she’s the one proposing
to move the extension from xwiki-sandbox to xwiki-extensions. He/she’s responsible for
ensuring that the extension gets regular releases and is maintained in general. He/she
defines initially the list of committers in his email proposal for moving the extension.
* We create a PMC (Project Management Committee) for XWiki Contrib, generally in charge
of both xwiki-contrib-sandbox and xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I would send a mail
on devs@ asking who’s interested to be part of this committee. I expect some core
committers + some contrib committers to stand up.
* Contrib extensions keep using the org.xwiki.contrib package name and groupid as
currently defined at http://contrib.xwiki.org
Note: The idea is that xwiki core is developed as a team maintaining all code in there,
xwiki contrib is developed extension by extension (each extension is an island). This
allows anyone to propose extensions in XWiki Contrib without the need for everyone to
support them.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
10:35 p.m.
Hi,
On Wed, Dec 3, 2014 at 5:16 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
xwiki-contrib-extensions
"A generic *maven groupId*: org.xwiki.contrib (or org.xwiki.contrib.<module
name> if the project has several modules). That's until the project reaches
a certain size and visibility, in which case it can have its own maven
group id."
Projects part of xwiki-contrib-extensions seem to qualify the for the
"until the project reaches a certain size and visibility" part.
Do we really want to enforce the org.xwiki.contrib group? Personally, I
never did understand *why* we are enforcing it, above the simple fact that
we just can.
I don't have something in particular against new projects in
xwiki-contrib-sandbox, but for projects we are migrating from the xwiki
organization, if they are java projects, we are forcing anybody that was
using them in the past to rewrite their code (so no longer a simple
dependency change in their pom.xml), since package name would change (due
to our maven group id policy) and any code using those packages needs an
update.
Thanks,
Eduard
Sounds good. +1
On Wed, Dec 3, 2014 at 3:57 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
So no plan at this point to address
http://xwiki.markmail.org/thread/zohkn73srh7dwom4 and
http://xwiki.markmail.org/thread/cuqpsqsxtvslmlkp , right?
Hi committers (and devs in general),
I’m submitting to you this idea, to try to improve the xwiki open source
project
and to give it a new dynamism. I believe the topics discussed below
are made even more important since we’re soon going to develop the notion
of flavors in XWiki.
Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the
xwiki github
organization, the less easy it is for non-“XWiki Dev Team” committers
to
participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by
only keeping “core” modules
* A “core" module is defined by being a
generic transversal module (i.e.
that can be used in lots of XWiki flavors, if not
all). This is opposed to
“vertical” modules which are modules specific of a usage of XWiki.
** Examples of “core" modules: logging
module, configuration module,
distribution wizard, statistics application,
annotations, active installs,
one base flavor (the “XWiki” flavor), etc
** Example of “vertical” modules: meeting manager
application, blog
application, FAQ application, flavors (except the base flavor),
etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github
organization repos
* It would be good to separate sandbox extensions
from 1st class
extensions that are maintained and developed following best
practices. We
need some way to maintain the quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core”
(it’s too
complex to rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team”
(and committers in
there are called “XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github
organizations (technically we
rename it to “xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly proposed
extensions or abandoned extensions are
located
** “xwiki-contrib-extensions”, where maintained
extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would
be granted
one and he/she’d be given write access to all repos in the
xwiki-contrib-sandbox organization.
* We define some rules for graduating from
xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in
xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is
maintained during that
time and will survive the test of time - most extensions will die in the
first months)
** The extension should have had more than 2
releases and be published
on extensions.xwiki.org(http://extensions.xwiki.org) with
documentation
** The extension should work with the latest LTS
version of XWiki + the
latest stable version of XWiki (right now that would be
5.4.5 + 6.3). Note
that if the extension has to use new API it’s ok that it doesn’t work on
the latest LTS.
** Generally
follow the practices defined at http://dev.xwiki.org
* Each extension in xwiki-extensions
has a leader/maintainer. He/she’s the one proposing to
move the extension
from xwiki-sandbox
xwiki-contrib-sandbox
to xwiki-extensions. He/she’s responsible for ensuring
that the extension
gets regular releases and is maintained in general. He/she defines
initially the list of committers in his email proposal for moving the
extension.
I propose that all XWiki core committers are, by default, members of this
PMC. They can choose not to get involved in every decision, but they should
have a voice if they need it, without needing to pass through a vote
process from the current members of the PMC.
* We create a PMC (Project Management Committee)
for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to stand
up.
* Contrib
extensions keep using the org.xwiki.contrib package name and
groupid as currently
defined at http://contrib.xwiki.org
Note: The idea is that xwiki core is developed as a team maintaining all
code in
there, xwiki contrib is developed extension by extension (each
extension is an island). This allows anyone to propose extensions in XWiki
Contrib without the need for everyone to support them.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4 Dec
4 Dec
9:44 a.m.
Hi Edy,
On 3 Dec 2014 at 22:36:34, Eduard Moraru
(enygma2002@gmail.com(mailto:enygma2002@gmail.com)) wrote:
xwiki-contrib-extensions
I didn’t proposa this for a very simple reason: One very big point of this proposal (if
not the main one) is to make equal citizenship in the XWiki community between XWiki Core
Devs and Contributors of xwiki-contrib. It’s about shifting the balance: have XWiki Core
devs focus on core and have contributors focus on providing extensions to the core. Thus
they need to have separate decision power.
In addition, not all Core Devs may want to spend extra time to handle Contrib Extensions.
This is why it’ll be a mail asking who’s interested. If Core Devs are not interested I’ll
certainly not force them to have to attend Contrib duties, that would be stupid IMO and
not productive since they wouldn’t participate if they’re not interested, and thus block
decision making. I remind you that when there’s a VOTE it’s a duty of the committers to
reply (among other duties, which span doing code review, etc).
"A generic *maven groupId*: org.xwiki.contrib (or org.xwiki.contrib.> name> if
the project has several modules). That's until the project reaches
a certain size and visibility, in which case it can have its own maven
group id."
Projects part of xwiki-contrib-extensions seem to qualify the for the
"until the project reaches a certain size and visibility" part.
Do we really want to enforce the org.xwiki.contrib group? Personally, I
never did understand *why* we are enforcing it, above the simple fact that
we just can.
The reason is simple, each project needs a group id for its artifact. When people join
xwiki-contrib it’s about joining a community and doing community-based developmment (ie
the code doesn’t belong to you anymore). So imagine that I publish an extension with a
groupid of “net.massol.vincent” or “com.google.xxx", do you think it makes this
project a nice community project owned by everyone? :)
The second reason reason is that we wanted to keep open the org.xwiki.XXX (where XXX !=
“contrib”) namespace for the xwiki github organization. Imagine some uses org.xwiki.job
for an Extension about Job Reruitment. Then Thomas would not have been able org.xwiki.job
for the Job module he coded...
Hi,
On Wed, Dec 3, 2014 at 5:16 PM, Thomas Mortagne
wrote:
This proposal and the one referenced are orthogonal.
That said, my proposal does solve a lot of the problem you mention since:
- we move several extensions out of xwiki-platform into xwiki-contrib-extensions and thus
they’ll have their lifecycle and can specify the dep versions they wish
- I have explicitly mentioned in my proposal that a good condition for joining
xwiki-contrib-extensions would be that: "The extension should work with the latest
LTS version of XWiki + the latest stable version of XWiki (right now that would be 5.4.5 +
6.3).”. Note that I said “should” and not “must” since this is hard to do *initially* if
we move out extensions from xwiki-platform but as time goes by, XWiki versions will
increase but the moved extension doesn’t have to increase its dep versions at the same
rate.
- what will remain in xwiki-platform is just core extensions, i.e. extensions that are
bundled and that you don’t install!
This proposal has not much to do with "XWiki Core" since it’s about extensions
currently in xwiki-contrib. Also AFAIK we’ve already agreed that we want these apps to
work with the latest XWiki LTS (except when they have to use newer APIs/features that only
exist in more recent versions). And this is very compatible with my proposal: "The
extension should work with the latest LTS version of XWiki + the latest stable version of
XWiki (right now that would be 5.4.5 + 6.3).”
So I don’t see any problem at all. Either I don’t understand your point or you’re trying
to make this proposal something much bigger than what it is.
Sounds good. +1
On Wed, Dec 3, 2014 at 3:57 PM, vincent(a)massol.net
wrote:
So no plan at this point to address
http://xwiki.markmail.org/thread/zohkn73srh7dwom4 and Hi committers (and devs in general),
I’m submitting to you this idea, to try to improve the xwiki open source
project
and to give it a new dynamism. I believe the topics discussed below
are made even more important since we’re soon going to develop the notion
of flavors in XWiki.
Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the
xwiki github
organization, the less easy it is for non-“XWiki Dev Team” committers
to
participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by
only keeping “core” modules
* A “core" module is defined by being a
generic transversal module (i.e.
that can be used in lots of XWiki flavors, if not
all). This is opposed to
“vertical” modules which are modules specific of a usage of XWiki.
** Examples of “core" modules: logging
module, configuration module,
distribution wizard, statistics application,
annotations, active installs,
one base flavor (the “XWiki” flavor), etc
** Example of “vertical” modules: meeting manager
application, blog
application, FAQ application, flavors (except the base flavor),
etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github
organization repos
* It would be good to separate sandbox extensions
from 1st class
extensions that are maintained and developed following best
practices. We
need some way to maintain the quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core”
(it’s too
complex to rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team”
(and committers in
there are called “XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github
organizations (technically we
rename it to “xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly proposed
extensions or abandoned extensions are
located
** “xwiki-contrib-extensions”, where maintained
extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would
be granted
one and he/she’d be given write access to all repos in the
xwiki-contrib-sandbox organization.
* We define some rules for graduating from
xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in
xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is
maintained during that
time and will survive the test of time - most extensions will die in the
first months)
** The extension should have had more than 2
releases and be published
on extensions.xwiki.org(http://extensions.xwiki.org) with
documentation
** The extension should work with the latest LTS
version of XWiki + the
latest stable version of XWiki (right now that would be
5.4.5 + 6.3). Note
that if the extension has to use new API it’s ok that it doesn’t work on
the latest LTS.
** Generally follow the practices defined at
http://dev.xwiki.org
* Each extension in xwiki-extensions
has a leader/maintainer. He/she’s the one
proposing to move the extension
from xwiki-sandbox
xwiki-contrib-sandbox
to xwiki-extensions. He/she’s responsible for
ensuring that the extension
gets regular releases and is maintained in general. He/she defines
initially the list of committers in his email proposal for moving the
extension.
I propose that all XWiki core committers are, by default, members of this
PMC. They can choose not to get involved in every decision, but they should
have a voice if they need it, without needing to pass through a vote
process from the current members of the PMC. * We create a PMC (Project Management Committee)
for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to stand
up.
* Contrib extensions keep using the org.xwiki.contrib
package name and
groupid as currently defined at http://contrib.xwiki.org
I don't have something in particular against new
projects in
xwiki-contrib-sandbox, but for projects we are migrating from the xwiki
organization, if they are java projects, we are forcing anybody that was
using them in the past to rewrite their code (so no longer a simple
dependency change in their pom.xml), since package name would change (due
to our maven group id policy) and any code using those packages needs an
update.
This is still a grey area for projects moved out of the xwiki github organization. For
groupid/artifact it’s not really a problem with the relocation feature. For package names
it’s much harder and I propose an exception there till the next big refactoring of the
module when it’ll next break backward compat. That said there won’t be many java code
moved out, it’ll be mainly XARs and thus the problem won’t happen much.
You forgot to voice your opinion about this proposal!
Thanks
-Vincent
Thanks,
Eduard
> >
> > Note: The idea is that xwiki core is developed as a team maintaining all
> code in there, xwiki contrib is developed extension by extension (each
> extension is an island). This allows anyone to propose extensions in XWiki
> Contrib without the need for everyone to support them.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
10:28 a.m.
Hi
2014-12-03 15:57 GMT+01:00 vincent(a)massol.net <vincent(a)massol.net>et>:
Hi committers (and devs in general),
I’m submitting to you this idea, to try to improve the xwiki open source
project and to give it a new dynamism. I believe the topics discussed below
are made even more important since we’re soon going to develop the notion
of flavors in XWiki.
Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the xwiki github organization,
the less easy it is for non-“XWiki Dev Team” committers to participate and
we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by only keeping “core” modules
* A “core" module is defined by being a generic transversal module (i.e.
that can be used in lots of XWiki flavors, if not all). This is opposed to
“vertical” modules which are modules specific of a usage of XWiki.
** Examples of “core" modules: logging module, configuration module,
distribution wizard, statistics application, annotations, active installs,
one base flavor (the “XWiki” flavor), etc
** Example of “vertical” modules: meeting manager application, blog
application, FAQ application, flavors (except the base flavor), etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github organization repos
* It would be good to separate sandbox extensions from 1st class
extensions that are maintained and developed following best practices. We
need some way to maintain the quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core” (it’s
too complex to rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in there
are called “XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github organizations (technically we
rename it to “xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed
extensions or abandoned extensions are located
I prefer xwiki-contrib-incubator because the "sandbox" name gives me the
impression of projects that are not serious. I would not like to create a
project in a "sandbox", but I would be OK to put it in an
"incubator".
** “xwiki-contrib-extensions”, where maintained
extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would be
granted one and he/she’d be given write access to all repos in the
xwiki-contrib-sandbox organization.
* We define some rules for graduating from xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is maintained during that
time and will survive the test of time - most extensions will die in the
first months)
** The extension should have had more than 2 releases and be published on
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
** The extension should work with the latest LTS version of XWiki + the
latest stable version of XWiki (right now that would be 5.4.5 + 6.3). Note
that if the extension has to use new API it’s ok that it doesn’t work on
the latest LTS.
** Generally follow the practices defined at http://dev.xwiki.org
* Each extension in xwiki-extensions has a leader/maintainer. He/she’s the
one proposing to move the extension from xwiki-sandbox to xwiki-extensions.
He/she’s responsible for ensuring that the extension gets regular releases
and is maintained in general. He/she defines initially the list of
committers in his email proposal for moving the extension.
* We create a PMC (Project Management Committee) for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to stand
up.
* Contrib extensions keep using the org.xwiki.contrib package name and
groupid as currently defined at http://contrib.xwiki.org
Note: The idea is that xwiki core is developed as a team maintaining all
code in there, xwiki contrib is developed extension by extension (each
extension is an island). This allows anyone to propose extensions in XWiki
Contrib without the need for everyone to support them.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
+1 for the proposal.
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
10:37 a.m.
On 4 Dec 2014 at 10:28:43, Guillaume Louis-Marie Delhumeau
(gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
Hi
2014-12-03 15:57 GMT+01:00 vincent(a)massol.net :
There’s just 2 problems with “incubator”:
1) we’re going to not have any place to put our extensions/modules that are no longer
supported… And I’d rather not create another org just for that…
2) incubator means that it’s a transient location and that the goal is always to go in
xwiki-contrib-extensions while “sandbox” is more neutral.
Thanks
-Vincent
Hi committers (and devs in general),
I’m submitting to you this idea, to try to improve the xwiki open source
project and to give it a new dynamism. I believe the topics discussed below
are made even more important since we’re soon going to develop the notion
of flavors in XWiki.
Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the xwiki github organization,
the less easy it is for non-“XWiki Dev Team” committers to participate and
we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by only keeping “core” modules
* A “core" module is defined by being a generic transversal module (i.e.
that can be used in lots of XWiki flavors, if not all). This is opposed to
“vertical” modules which are modules specific of a usage of XWiki.
** Examples of “core" modules: logging module, configuration module,
distribution wizard, statistics application, annotations, active installs,
one base flavor (the “XWiki” flavor), etc
** Example of “vertical” modules: meeting manager application, blog
application, FAQ application, flavors (except the base flavor), etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github organization repos
* It would be good to separate sandbox extensions from 1st class
extensions that are maintained and developed following best practices. We
need some way to maintain the quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core” (it’s
too complex to rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in there
are called “XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github organizations (technically we
rename it to “xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed
extensions or abandoned extensions are located
I prefer xwiki-contrib-incubator because the "sandbox" name gives me the
impression of projects that are not serious. I would not like to create a
project in a "sandbox", but I would be OK to put it in an "incubator”.
**
“xwiki-contrib-extensions”, where maintained extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would be
granted one and he/she’d be given write access to all repos in the
xwiki-contrib-sandbox organization.
* We define some rules for graduating from xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is maintained during that
time and will survive the test of time - most extensions will die in the
first months)
** The extension should have had more than 2 releases and be published on
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
** The extension should work with the latest LTS version of XWiki + the
latest stable version of XWiki (right now that would be 5.4.5 + 6.3). Note
that if the extension has to use new API it’s ok that it doesn’t work on
the latest LTS.
** Generally follow the practices defined at http://dev.xwiki.org
* Each extension in xwiki-extensions has a leader/maintainer. He/she’s the
one proposing to move the extension from xwiki-sandbox to xwiki-extensions.
He/she’s responsible for ensuring that the extension gets regular releases
and is maintained in general. He/she defines initially the list of
committers in his email proposal for moving the extension.
* We create a PMC (Project Management Committee) for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to stand
up.
* Contrib extensions keep using the org.xwiki.contrib package name and
groupid as currently defined at http://contrib.xwiki.org
Note: The idea is that xwiki core is developed as a team maintaining all
code in there, xwiki contrib is developed extension by extension (each
extension is an island). This allows anyone to propose extensions in XWiki
Contrib without the need for everyone to support them.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
+1 for the proposal.
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
1:35 p.m.
In theory the proposal sounds good, although it increases the process rules
and number of organizations, etc.
We still have things to figure out, but it looks ok +1
Thanks,
Caty
On Thu, Dec 4, 2014 at 11:37 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 4 Dec 2014 at 10:28:43, Guillaume Louis-Marie Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
There’s just 2 problems with “incubator”:
1) we’re going to not have any place to put our extensions/modules that
are no longer supported… And I’d rather not create another org just for
that…
2) incubator means that it’s a transient location and that the goal is
always to go in xwiki-contrib-extensions while “sandbox” is more neutral.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi
2014-12-03 15:57 GMT+01:00 vincent(a)massol.net :
> Hi committers (and devs in general),
>
> I’m submitting to you this idea, to try to improve the xwiki open
source
> project and to give it a new dynamism. I
believe the topics discussed
below
> are made even more important since we’re
soon going to develop the
notion
> of flavors in XWiki.
>
> Note that this proposal obsoletes the
> http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move
of
> some extensions in the xwiki github
organization), which itself was
> obsoleting http://markmail.org/message/ppw2slpgqou2ihai
>
> Issues to solve
> ===============
>
> * The scope of the code maintained by the XWiki Dev Team (== the xwiki
> github organization) is increasing but the team stays relatively small
> * The more stuff we move into the repos of the xwiki github
organization,
> the less easy it is for non-“XWiki Dev Team”
committers to participate
and
> we want more contributions
>
> Proposed solution
> =================
>
> Executive summary:
> * Reduce the scope of all the code located in the xwiki github
> organization by only keeping “core” modules
> * A “core" module is defined by being a generic transversal module
(i.e.
> that can be used in lots of XWiki flavors,
if not all). This is
opposed to
> “vertical” modules which are modules
specific of a usage of XWiki.
> ** Examples of “core" modules: logging module, configuration module,
> distribution wizard, statistics application, annotations, active
installs,
> one base flavor (the “XWiki” flavor), etc
> ** Example of “vertical” modules: meeting manager application, blog
> application, FAQ application, flavors (except the base flavor), etc
>
> Some consequences:
> * We need a new location for several modules that would go out of the
> xwiki github organization repos
> * It would be good to separate sandbox extensions from 1st class
> extensions that are maintained and developed following best practices.
We
> need some way to maintain the quality of
important extensions
>
> Detailed Implementation:
> * The “xwiki” github organization’s description becomes “XWiki Core”
(it’s
> too complex to rename the org to
“xwiki-core” IMO)
> * “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in
there
are
called “XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github organizations (technically we
rename it to “xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed
extensions or abandoned extensions are located
I prefer xwiki-contrib-incubator because the "sandbox" name gives me the
impression of projects that are not serious. I would not like to create a
project in a "sandbox", but I would be OK to put it in an "incubator”.
> ** “xwiki-contrib-extensions”, where
maintained extensions are located.
> * These 2 organizations are commonly referred to as “XWiki Contrib"
> * Same as now, anyone requesting a repo in xwiki-contrib-sandbox would
be
> granted one and he/she’d be given write
access to all repos in the
> xwiki-contrib-sandbox organization.
> * We define some rules for graduating from xwiki-contrib-sandbox to
> xwiki-contrib-extensions. For example:
> ** The extension should have been in xwiki-contrib-sandbox at least 6
> months (this gives time to see if the extension is maintained during
that
> time and will survive the test of time -
most extensions will die in
the
> first months)
> ** The extension should have had more than 2 releases and be published
on
>
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
> ** The extension should work with the latest LTS version of XWiki + the
> latest stable version of XWiki (right now that would be 5.4.5 + 6.3).
Note
> that if the extension has to use new API
it’s ok that it doesn’t work
on
> the latest LTS.
> ** Generally follow the practices defined at http://dev.xwiki.org
> * Each extension in xwiki-extensions has a leader/maintainer. He/she’s
the
> one proposing to move the extension from
xwiki-sandbox to
xwiki-extensions.
> He/she’s responsible for ensuring that the
extension gets regular
releases
> and is maintained in general. He/she defines
initially the list of
> committers in his email proposal for moving the extension.
> * We create a PMC (Project Management Committee) for XWiki Contrib,
> generally in charge of both xwiki-contrib-sandbox and
> xwiki-contrib-extensions (voting new extensions in
> xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it,
I
> would send a mail on devs@ asking who’s
interested to be part of this
> committee. I expect some core committers + some contrib committers to
stand
> up.
> * Contrib extensions keep using the org.xwiki.contrib package name and
> groupid as currently defined at http://contrib.xwiki.org
>
> Note: The idea is that xwiki core is developed as a team maintaining
all
> code in there, xwiki contrib is developed
extension by extension (each
> extension is an island). This allows anyone to propose extensions in
XWiki
Contrib
without the need for everyone to support them.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
+1 for the proposal.
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
6 Dec
6 Dec
9:56 p.m.
On Thu, Dec 4, 2014 at 10:37 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
It sounds to me a bit like Apple policies for its app store... Do we really
want to keep that level of control ? Is it really fair ?.
If you look at other software that provide extensions, most of them as not
follow that way, but they have left the users vote and put their most
useful and preferred extensions at the top of the results. I am not sure we
are making the good choice by creating that committee. I understand that
you want a way to keep the quality of good extensions. Wouldn't this be
naturally done if the extension has a maintainer (that self design himself)
and a way for user to express their happiness about extensions ?
I am just afraid by more policies (which is opposite to the issues you try
to solve), and I am pleading for more natural selection.
Also, aren't we mixing two different aspects of the problem:
1) repositories, and developper tools for extensions
2) publishing extension in the XWiki "central" repository
For 1), we can provide helps, keeping our actual very open policies
For 2), we can have some more strict rules, since it does not prevent
anyone to provide their extension from any external repository.
Maybe we could make something in the line of Ubuntu packages, and their
Personal Package Repositories. I mean:
- provide tools for developers (and simple users) to create good
extensions without annoying them with policies
- provide way to publish those extension into our maven repository, and
require for this purpose that the project follow some rules. We may even
provide two different maven repos, one for first grade and one for others.
I do not think separating first grade and other extensions are useful for
the sources repositories. The sources could be anywhere, in our github
contrib, or anywhere else. Of course, only well managed project, which
imply well managed sources has a chance to be accepted in the first grade
extension maven repository. This repository will be only recommandation,
but we will never imply that an extension should be in that repository to
be good.
This would allow IMO a better and more acceptable control. Moreover, again
like what debian/ubuntu, the users of XWiki will be able to decide from
which repositories they accept to pull extension from.
IMO, in that context, the rules and voting for releasing an extension into
the first grade repository could be managed as a committers vote. Providing
ratings on extension will help committers make good proposals and
decisions. Moreover, anyone as the right to make a non binding vote, and
therefore help in the decision process. So, with this approach, we do not
have to add more complexity to the management of the project.
WDYT ?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
On 4 Dec 2014 at 10:28:43, Guillaume Louis-Marie Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
There’s just 2 problems with “incubator”:
1) we’re going to not have any place to put our extensions/modules that
are no longer supported… And I’d rather not create another org just for
that…
2) incubator means that it’s a transient location and that the goal is
always to go in xwiki-contrib-extensions while “sandbox” is more neutral.
I agree with Guillaume, the Sandbox is not motivating, and create for those
who do not catch with the rules a nice place to stay. I agree that it will
push for moving to a better repository, but if it slow down the initial
contribution, there will be nothing to move. Why not keeping the first
naming, even if the rules will differ: xwiki-extensions and xwiki-contrib
(or xwiki-contrib-extensions if you prefer) ?
Hi
2014-12-03 15:57 GMT+01:00 vincent(a)massol.net :
> Hi committers (and devs in general),
>
> I’m submitting to you this idea, to try to improve the xwiki open
source
> project and to give it a new dynamism. I
believe the topics discussed
below
> are made even more important since we’re
soon going to develop the
notion
> of flavors in XWiki.
>
> Note that this proposal obsoletes the
> http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move
of
> some extensions in the xwiki github
organization), which itself was
> obsoleting http://markmail.org/message/ppw2slpgqou2ihai
>
> Issues to solve
> ===============
>
> * The scope of the code maintained by the XWiki Dev Team (== the xwiki
> github organization) is increasing but the team stays relatively small
> * The more stuff we move into the repos of the xwiki github
organization,
> the less easy it is for non-“XWiki Dev Team”
committers to participate
and
> we want more contributions
>
> Proposed solution
> =================
>
> Executive summary:
> * Reduce the scope of all the code located in the xwiki github
> organization by only keeping “core” modules
> * A “core" module is defined by being a generic transversal module
(i.e.
> that can be used in lots of XWiki flavors,
if not all). This is
opposed to
> “vertical” modules which are modules
specific of a usage of XWiki.
> ** Examples of “core" modules: logging module, configuration module,
> distribution wizard, statistics application, annotations, active
installs,
> one base flavor (the “XWiki” flavor), etc
> ** Example of “vertical” modules: meeting manager application, blog
> application, FAQ application, flavors (except the base flavor), etc
>
> Some consequences:
> * We need a new location for several modules that would go out of the
> xwiki github organization repos
> * It would be good to separate sandbox extensions from 1st class
> extensions that are maintained and developed following best practices.
We
> need some way to maintain the quality of
important extensions
>
> Detailed Implementation:
> * The “xwiki” github organization’s description becomes “XWiki Core”
(it’s
> too complex to rename the org to
“xwiki-core” IMO)
> * “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in
there
are
called “XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github organizations (technically we
rename it to “xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed
extensions or abandoned extensions are located
I prefer xwiki-contrib-incubator because the "sandbox" name gives me the
impression of projects that are not serious. I would not like to create a
project in a "sandbox", but I would be OK to put it in an "incubator”.
Thanks
-Vincent
Well, there are several kind of extension, and their level of risk are very
different. For example, a mostly Javascript base extension, with a bit of
XWiki Macro, could really be stable since its version 1.0, not having much
compatibility issue over time, and therefore, works on the latest versions,
being a nice helper, all this without any maintenance work. Let take the
ShowHide Macro or the LiveValidation Macros, both are now generally
following the best practice, works on latest versions, but I doubt I will
have to make any new release of them in the near future.
I do not think we can really measure the maintenance quality of an
extension with the frequency of its release.
I also think that simple extension could be really well done while being
only release as simple XAR, putting the contribution to the level of the
advance user, not necessarily programmers.
So, I am afraid that the separation between first class extension and other
ones is more subtil than you would like it to be.
What you describe is well adapted to large extension, like meeting
applications, filemanager, etc...
> ** “xwiki-contrib-extensions”, where
maintained extensions are located.
> * These 2 organizations are commonly referred to as “XWiki Contrib"
> * Same as now, anyone requesting a repo in xwiki-contrib-sandbox would
be
> granted one and he/she’d be given write
access to all repos in the
> xwiki-contrib-sandbox organization.
> * We define some rules for graduating from xwiki-contrib-sandbox to
> xwiki-contrib-extensions. For example:
> ** The extension should have been in xwiki-contrib-sandbox at least 6
> months (this gives time to see if the extension is maintained during
that
> time and will survive the test of time -
most extensions will die in
the
> first months)
> ** The extension should have had more than 2 releases and be published
on
>
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
> ** The extension should work with the latest LTS version of XWiki + the
> latest stable version of XWiki (right now that would be 5.4.5 + 6.3).
Note
> that if the extension has to use new API
it’s ok that it doesn’t work
on
> the latest LTS.
> ** Generally follow the practices defined at http://dev.xwiki.org
> * Each
extension in xwiki-extensions has a leader/maintainer. He/she’s
the
> one proposing to move the extension from
xwiki-sandbox to
xwiki-extensions.
> He/she’s responsible for ensuring that the
extension gets regular
releases
> and is maintained in general. He/she defines
initially the list of
> committers in his email proposal for moving the extension.
> * We create a PMC (Project Management Committee) for XWiki Contrib,
> generally in charge of both xwiki-contrib-sandbox and
> xwiki-contrib-extensions (voting new extensions in
> xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it,
I
> would send a mail on devs@ asking who’s
interested to be part of this
> committee. I expect some core committers + some contrib committers to
stand
> up.
* Contrib
extensions keep using the org.xwiki.contrib package name and
> groupid as currently defined at http://contrib.xwiki.org
>
> Note: The idea is that xwiki core is developed as a team maintaining
all
> code in there, xwiki contrib is developed
extension by extension (each
> extension is an island). This allows anyone to propose extensions in
XWiki
Contrib
without the need for everyone to support them.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
+1 for the proposal.
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7 Dec
7 Dec
10:52 a.m.
On Sat, Dec 6, 2014 at 9:56 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Thu, Dec 4, 2014 at 10:37 AM, vincent(a)massol.net
<vincent(a)massol.net>
wrote:
It sounds to me a bit like Apple policies for its app store... Do we really
want to keep that level of control ? Is it really fair ?.
I don't understand the comparison, we are not discussing what
extension is going to be installable trough Extension Manager, they
all will. You don't even need to be at sandbox level to deploy your
extension.
On 4 Dec 2014 at 10:28:43, Guillaume Louis-Marie Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
There’s just 2 problems with “incubator”:
1) we’re going to not have any place to put our extensions/modules that
are no longer supported… And I’d rather not create another org just for
that…
2) incubator means that it’s a transient location and that the goal is
always to go in xwiki-contrib-extensions while “sandbox” is more neutral.
I agree with Guillaume, the Sandbox is not motivating, and create for those
who do not catch with the rules a nice place to stay. I agree that it will
push for moving to a better repository, but if it slow down the initial
contribution, there will be nothing to move. Why not keeping the first
naming, even if the rules will differ: xwiki-extensions and xwiki-contrib
(or xwiki-contrib-extensions if you prefer) ?
Hi
2014-12-03 15:57 GMT+01:00 vincent(a)massol.net :
> Hi committers (and devs in general),
>
> I’m submitting to you this idea, to try to improve the xwiki open
source
> project and to give it a new dynamism. I
believe the topics discussed
below
> are made even more important since we’re
soon going to develop the
notion
> of flavors in XWiki.
>
> Note that this proposal obsoletes the
> http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move
of
> some extensions in the xwiki github
organization), which itself was
> obsoleting http://markmail.org/message/ppw2slpgqou2ihai
>
> Issues to solve
> ===============
>
> * The scope of the code maintained by the XWiki Dev Team (== the xwiki
> github organization) is increasing but the team stays relatively small
> * The more stuff we move into the repos of the xwiki github
organization,
> the less easy it is for non-“XWiki Dev Team”
committers to participate
and
> we want more contributions
>
> Proposed solution
> =================
>
> Executive summary:
> * Reduce the scope of all the code located in the xwiki github
> organization by only keeping “core” modules
> * A “core" module is defined by being a generic transversal module
(i.e.
> that can be used in lots of XWiki flavors,
if not all). This is
opposed to
> “vertical” modules which are modules
specific of a usage of XWiki.
> ** Examples of “core" modules: logging module, configuration module,
> distribution wizard, statistics application, annotations, active
installs,
> one base flavor (the “XWiki” flavor), etc
> ** Example of “vertical” modules: meeting manager application, blog
> application, FAQ application, flavors (except the base flavor), etc
>
> Some consequences:
> * We need a new location for several modules that would go out of the
> xwiki github organization repos
> * It would be good to separate sandbox extensions from 1st class
> extensions that are maintained and developed following best practices.
We
> need some way to maintain the quality of
important extensions
>
> Detailed Implementation:
> * The “xwiki” github organization’s description becomes “XWiki Core”
(it’s
> too complex to rename the org to
“xwiki-core” IMO)
> * “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in
there
are
called “XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github organizations (technically we
rename it to “xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed
extensions or abandoned extensions are located
I prefer xwiki-contrib-incubator because the "sandbox" name gives me the
impression of projects that are not serious. I would not like to create a
project in a "sandbox", but I would be OK to put it in an "incubator”.
Thanks
-Vincent
Well, there are several kind of extension, and their level of risk are very
different. For example, a mostly Javascript base extension, with a bit of
XWiki Macro, could really be stable since its version 1.0, not having much
compatibility issue over time, and therefore, works on the latest versions,
being a nice helper, all this without any maintenance work. Let take the
ShowHide Macro or the LiveValidation Macros, both are now generally
following the best practice, works on latest versions, but I doubt I will
have to make any new release of them in the near future.
I do not think we can really measure the maintenance quality of an
extension with the frequency of its release.
I also think that simple extension could be really well done while being
only release as simple XAR, putting the contribution to the level of the
advance user, not necessarily programmers.
So, I am afraid that the separation between first class extension and other
ones is more subtil than you would like it to be.
What you describe is well adapted to large extension, like meeting
applications, filemanager, etc...
> ** “xwiki-contrib-extensions”, where
maintained extensions are located.
> * These 2 organizations are commonly referred to as “XWiki Contrib"
> * Same as now, anyone requesting a repo in xwiki-contrib-sandbox would
be
> granted one and he/she’d be given write
access to all repos in the
> xwiki-contrib-sandbox organization.
> * We define some rules for graduating from xwiki-contrib-sandbox to
> xwiki-contrib-extensions. For example:
> ** The extension should have been in xwiki-contrib-sandbox at least 6
> months (this gives time to see if the extension is maintained during
that
> time and will survive the test of time -
most extensions will die in
the
> first months)
> ** The extension should have had more than 2 releases and be published
on
>
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
> ** The extension should work with the latest LTS version of XWiki + the
> latest stable version of XWiki (right now that would be 5.4.5 + 6.3).
Note
> that if the extension has to use new API
it’s ok that it doesn’t work
on
> the latest LTS.
> ** Generally follow the practices defined at http://dev.xwiki.org
> *
Each extension in xwiki-extensions has a leader/maintainer. He/she’s
the
> one proposing to move the extension from
xwiki-sandbox to
xwiki-extensions.
> He/she’s responsible for ensuring that the
extension gets regular
releases
> and is maintained in general. He/she defines
initially the list of
> committers in his email proposal for moving the extension.
> * We create a PMC (Project Management Committee) for XWiki Contrib,
> generally in charge of both xwiki-contrib-sandbox and
> xwiki-contrib-extensions (voting new extensions in
> xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it,
I
> would send a mail on devs@ asking who’s
interested to be part of this
> committee. I expect some core committers + some contrib committers to
stand
> up.
If you look at other software that provide extensions,
most of them as not
follow that way, but they have left the users vote and put their most
useful and preferred extensions at the top of the results. I am not sure we
are making the good choice by creating that committee. I understand that
you want a way to keep the quality of good extensions. Wouldn't this be
naturally done if the extension has a maintainer (that self design himself)
and a way for user to express their happiness about extensions ?
I am just afraid by more policies (which is opposite to the issues you try
to solve), and I am pleading for more natural selection.
Also, aren't we mixing two different aspects of the problem:
1) repositories, and developper tools for extensions
2) publishing extension in the XWiki "central" repository
For 1), we can provide helps, keeping our actual very open policies
For 2), we can have some more strict rules, since it does not prevent
anyone to provide their extension from any external repository.
Maybe we could make something in the line of Ubuntu packages, and their
Personal Package Repositories. I mean:
- provide tools for developers (and simple users) to create good
extensions without annoying them with policies
- provide way to publish those extension into our maven repository, and
require for this purpose that the project follow some rules. We may even
provide two different maven repos, one for first grade and one for others.
I do not think separating first grade and other extensions are useful for
the sources repositories. The sources could be anywhere, in our github
contrib, or anywhere else. Of course, only well managed project, which
imply well managed sources has a chance to be accepted in the first grade
extension maven repository. This repository will be only recommandation,
but we will never imply that an extension should be in that repository to
be good.
This would allow IMO a better and more acceptable control. Moreover, again
like what debian/ubuntu, the users of XWiki will be able to decide from
which repositories they accept to pull extension from.
IMO, in that context, the rules and voting for releasing an extension into
the first grade repository could be managed as a committers vote. Providing
ratings on extension will help committers make good proposals and
decisions. Moreover, anyone as the right to make a non binding vote, and
therefore help in the decision process. So, with this approach, we do not
have to add more complexity to the management of the project.
WDYT ?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
* Contrib
extensions keep using the org.xwiki.contrib package name and
> groupid as currently defined at http://contrib.xwiki.org
>
> Note: The idea is that xwiki core is developed as a team maintaining
all
> code in there, xwiki contrib is developed
extension by extension (each
> extension is an island). This allows anyone to propose extensions in
XWiki
Contrib
without the need for everyone to support them.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
+1 for the proposal.
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
5 Dec
5 Dec
4:19 p.m.
+1
Thanks,
Marius
On Wed, Dec 3, 2014 at 4:57 PM, vincent(a)massol.net <vincent(a)massol.net> wrote:
Hi committers (and devs in general),
I’m submitting to you this idea, to try to improve the xwiki open source project and to
give it a new dynamism. I believe the topics discussed below are made even more important
since we’re soon going to develop the notion of flavors in XWiki.
Note that this proposal obsoletes the http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of some extensions in the xwiki github organization), which itself
was obsoleting http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the xwiki github organization, the less easy
it is for non-“XWiki Dev Team” committers to participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github organization by only
keeping “core” modules
* A “core" module is defined by being a generic transversal module (i.e. that can be
used in lots of XWiki flavors, if not all). This is opposed to “vertical” modules which
are modules specific of a usage of XWiki.
** Examples of “core" modules: logging module, configuration module, distribution
wizard, statistics application, annotations, active installs, one base flavor (the “XWiki”
flavor), etc
** Example of “vertical” modules: meeting manager application, blog application, FAQ
application, flavors (except the base flavor), etc
Some consequences:
* We need a new location for several modules that would go out of the xwiki github
organization repos
* It would be good to separate sandbox extensions from 1st class extensions that are
maintained and developed following best practices. We need some way to maintain the
quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core” (it’s too complex to
rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in there are called
“XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github organizations (technically we rename it to
“xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed extensions or
abandoned extensions are located
** “xwiki-contrib-extensions”, where maintained extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would be granted one and
he/she’d be given write access to all repos in the xwiki-contrib-sandbox organization.
* We define some rules for graduating from xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in xwiki-contrib-sandbox at least 6 months (this gives
time to see if the extension is maintained during that time and will survive the test of
time - most extensions will die in the first months)
** The extension should have had more than 2 releases and be published on
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
** The extension should work with the latest LTS version of XWiki + the latest stable
version of XWiki (right now that would be 5.4.5 + 6.3). Note that if the extension has to
use new API it’s ok that it doesn’t work on the latest LTS.
** Generally follow the practices defined at http://dev.xwiki.org
* Each extension in xwiki-extensions has a leader/maintainer. He/she’s the one proposing
to move the extension from xwiki-sandbox to xwiki-extensions. He/she’s responsible for
ensuring that the extension gets regular releases and is maintained in general. He/she
defines initially the list of committers in his email proposal for moving the extension.
* We create a PMC (Project Management Committee) for XWiki Contrib, generally in charge
of both xwiki-contrib-sandbox and xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I would send a mail
on devs@ asking who’s interested to be part of this committee. I expect some core
committers + some contrib committers to stand up.
* Contrib extensions keep using the org.xwiki.contrib package name and groupid as
currently defined at http://contrib.xwiki.org
Note: The idea is that xwiki core is developed as a team maintaining all code in there,
xwiki contrib is developed extension by extension (each extension is an island). This
allows anyone to propose extensions in XWiki Contrib without the need for everyone to
support them.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2 Aug
2 Aug
7:43 p.m.
New subject: [xwiki-devs] [Proposal] XWiki Core - Second take
Hi,
I’d like to progress with this idea so let me summarize this thread’s discussion so far:
* +1 from Thomas, Guillaume, Caty and Marius
* No answer from Edy on whether he’s ok with the proposal or not. Edy? :)
* Denis seems negative about it but I agree with Thomas’s reply in that the points raised
by Denis do not concern this discussion. Denis commented about publishing and installing
Extensions, whereas this proposal was only about a location for storing some extensions.
Extensions can be developed anywhere and don’t have to go into this new proposed location.
Denis, could you please review this new proposal with this in mind?
* There were discussions about the name and devs express doubts about using
xwiki-contrib-sandbox.
I’d like to progress so here’s my second proposal. It differs from the first proposal on
the following points:
* All our code is contributed so I don’t think we need to emphasize this point and I don’t
think we need to have “contrib” in the name of the github repos. This will lead to shorter
names which is better.
* I propose to have 3 github org:
** xwiki-core (currently “xwiki” but we should probably rename it - Github will create
redirects and the only downside is that we need to check it out for making repo changes)
** xwiki-extensions (new). For maintained and good quality level extensions, following the
charter defined in the first proposal (we’ll tune it). Committers are added extension by
extension and will be voted on the devs list for now, by the xwiki core devs (we’ll tune
that later on)
** xwiki-incubator (currently “xwiki-contrib” but we should rename it). Extensions in
xwiki-extensions that are no longer working with the latest LTS and that nobody is fixing
will move back to xwiki-incubator too.
* I propose to change the goal of the contrib.xwiki.org wiki and to expand its goal. Right
now it’s focused about the xwiki-contrib organization on GitHub. I propose to make it the
wiki that explains how to make contributions to the XWiki ecosystem in general. We would
move http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages for explaining
how to contribute to xwiki-core, xwiki-extensions and xwiki-incubator.
* ATM we should continue to use the “org.xwiki.contrib" groupid for code in the
xwiki-incubator and xwiki-extensions organizations. Ideally we should use
org.xwiki.extension but it’s already used by the Extension module in xwiki-core. An option
would have been to use org.xwiki.core for the core but that would break too much code so
the only option is to keep having a special prefix for non-core code. Other ideas:
“org.xwiki.module”, “org.xwiki.ext”, “org.xwiki.external”, “org.xwiki.addon”. The simplest
is to keep “org.xwiki.contrib” I think, WDYT?
Once (and if) we agree on this, I’d like to quickly move some existing extensions from the
xwiki-core organization into xwiki-extensions, starting with the FAQ Application, in order
to start testing this new organization.
WDYT?
Thanks
-Vincent
On 3 Dec 2014 at 15:58:36, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
Hi committers (and devs in general),
I’m submitting to you this idea, to try to improve the xwiki open source project and to
give it a new dynamism. I believe the topics discussed below are made even more important
since we’re soon going to develop the notion of flavors in XWiki.
Note that this proposal obsoletes the http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of some extensions in the xwiki github organization), which itself
was obsoleting http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the xwiki github organization, the less easy
it is for non-“XWiki Dev Team” committers to participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github organization by only
keeping “core” modules
* A “core" module is defined by being a generic transversal module (i.e. that can be
used in lots of XWiki flavors, if not all). This is opposed to “vertical” modules which
are modules specific of a usage of XWiki.
** Examples of “core" modules: logging module, configuration module, distribution
wizard, statistics application, annotations, active installs, one base flavor (the “XWiki”
flavor), etc
** Example of “vertical” modules: meeting manager application, blog application, FAQ
application, flavors (except the base flavor), etc
Some consequences:
* We need a new location for several modules that would go out of the xwiki github
organization repos
* It would be good to separate sandbox extensions from 1st class extensions that are
maintained and developed following best practices. We need some way to maintain the
quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core” (it’s too complex to
rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in there are called
“XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github organizations (technically we rename it to
“xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed extensions or
abandoned extensions are located
** “xwiki-contrib-extensions”, where maintained extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would be granted one and
he/she’d be given write access to all repos in the xwiki-contrib-sandbox organization.
* We define some rules for graduating from xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in xwiki-contrib-sandbox at least 6 months (this gives
time to see if the extension is maintained during that time and will survive the test of
time - most extensions will die in the first months)
** The extension should have had more than 2 releases and be published on
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
** The extension should work with the latest LTS version of XWiki + the latest stable
version of XWiki (right now that would be 5.4.5 + 6.3). Note that if the extension has to
use new API it’s ok that it doesn’t work on the latest LTS.
** Generally follow the practices defined at http://dev.xwiki.org
* Each extension in xwiki-extensions has a leader/maintainer. He/she’s the one proposing
to move the extension from xwiki-sandbox to xwiki-extensions. He/she’s responsible for
ensuring that the extension gets regular releases and is maintained in general. He/she
defines initially the list of committers in his email proposal for moving the extension.
* We create a PMC (Project Management Committee) for XWiki Contrib, generally in charge
of both xwiki-contrib-sandbox and xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I would send a mail
on devs@ asking who’s interested to be part of this committee. I expect some core
committers + some contrib committers to stand up.
* Contrib extensions keep using the org.xwiki.contrib package name and groupid as
currently defined at http://contrib.xwiki.org
Note: The idea is that xwiki core is developed as a team maintaining all code in there,
xwiki contrib is developed extension by extension (each extension is an island). This
allows anyone to propose extensions in XWiki Contrib without the need for everyone to
support them.
WDYT?
Thanks
-Vincent
7 Aug
7 Aug
11:46 a.m.
New subject: [xwiki-devs] [Proposal] XWiki Core - Second take
Hello Vincent,
Here's my +1 for this proposal.
I strongly agree with one change, because I also had it in mind for a while
now. And that is: moving the "vertical" modules out of the xwiki github
organization repos, since it would be easier for contributors to
participate in improving and/or adding extensions and also, IMO, it will
decrease the build time.
Thanks,
Gabriela
*Gabriela Smeria*
*Web Developer*
gabriela.smeria(a)xwiki.com
skype: smeria.gabriela
On Sun, Aug 2, 2015 at 8:43 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi,
I’d like to progress with this idea so let me summarize this thread’s
discussion so far:
* +1 from Thomas, Guillaume, Caty and Marius
* No answer from Edy on whether he’s ok with the proposal or not. Edy? :)
* Denis seems negative about it but I agree with Thomas’s reply in that
the points raised by Denis do not concern this discussion. Denis commented
about publishing and installing Extensions, whereas this proposal was only
about a location for storing some extensions. Extensions can be developed
anywhere and don’t have to go into this new proposed location. Denis, could
you please review this new proposal with this in mind?
* There were discussions about the name and devs express doubts about
using xwiki-contrib-sandbox.
I’d like to progress so here’s my second proposal. It differs from the
first proposal on the following points:
* All our code is contributed so I don’t think we need to emphasize this
point and I don’t think we need to have “contrib” in the name of the github
repos. This will lead to shorter names which is better.
* I propose to have 3 github org:
** xwiki-core (currently “xwiki” but we should probably rename it - Github
will create redirects and the only downside is that we need to check it out
for making repo changes)
** xwiki-extensions (new). For maintained and good quality level
extensions, following the charter defined in the first proposal (we’ll tune
it). Committers are added extension by extension and will be voted on the
devs list for now, by the xwiki core devs (we’ll tune that later on)
** xwiki-incubator (currently “xwiki-contrib” but we should rename it).
Extensions in xwiki-extensions that are no longer working with the latest
LTS and that nobody is fixing will move back to xwiki-incubator too.
* I propose to change the goal of the contrib.xwiki.org wiki and to
expand its goal. Right now it’s focused about the xwiki-contrib
organization on GitHub. I propose to make it the wiki that explains how to
make contributions to the XWiki ecosystem in general. We would move
http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages
for explaining how to contribute to xwiki-core, xwiki-extensions and
xwiki-incubator.
* ATM we should continue to use the “org.xwiki.contrib" groupid for code
in the xwiki-incubator and xwiki-extensions organizations. Ideally we
should use org.xwiki.extension but it’s already used by the Extension
module in xwiki-core. An option would have been to use org.xwiki.core for
the core but that would break too much code so the only option is to keep
having a special prefix for non-core code. Other ideas:
“org.xwiki.module”, “org.xwiki.ext”, “org.xwiki.external”, “org.xwiki.addon”.
The simplest is to keep “org.xwiki.contrib” I think, WDYT?
Once (and if) we agree on this, I’d like to quickly move some existing
extensions from the xwiki-core organization into xwiki-extensions, starting
with the FAQ Application, in order to start testing this new organization.
WDYT?
Thanks
-Vincent
On 3 Dec 2014 at 15:58:36, vincent(a)massol.net (vincent(a)massol.net(mailto:
vincent(a)massol.net)) wrote:
Hi committers (and devs in general),
I’m submitting to you this idea, to try to improve the xwiki open source
project
and to give it a new dynamism. I believe the topics discussed below
are made even more important since we’re soon going to develop the notion
of flavors in XWiki.
Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the
xwiki github
organization, the less easy it is for non-“XWiki Dev Team” committers
to
participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by
only keeping “core” modules
* A “core" module is defined by being a
generic transversal module (i.e.
that can be used in lots of XWiki flavors, if not
all). This is opposed to
“vertical” modules which are modules specific of a usage of XWiki.
** Examples of “core" modules: logging
module, configuration module,
distribution wizard, statistics application,
annotations, active installs,
one base flavor (the “XWiki” flavor), etc
** Example of “vertical” modules: meeting manager
application, blog
application, FAQ application, flavors (except the base flavor),
etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github
organization repos
* It would be good to separate sandbox extensions
from 1st class
extensions that are maintained and developed following best
practices. We
need some way to maintain the quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core”
(it’s too
complex to rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team”
(and committers in
there are called “XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github
organizations (technically we
rename it to “xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly proposed
extensions or abandoned extensions are
located
** “xwiki-contrib-extensions”, where maintained
extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would
be granted
one and he/she’d be given write access to all repos in the
xwiki-contrib-sandbox organization.
* We define some rules for graduating from
xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in
xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is
maintained during that
time and will survive the test of time - most extensions will die in the
first months)
** The extension should have had more than 2
releases and be published
on extensions.xwiki.org(http://extensions.xwiki.org) with
documentation
** The extension should work with the latest LTS
version of XWiki + the
latest stable version of XWiki (right now that would be
5.4.5 + 6.3). Note
that if the extension has to use new API it’s ok that it doesn’t work on
the latest LTS.
** Generally follow the practices defined at
http://dev.xwiki.org
* Each extension in xwiki-extensions has a leader/maintainer. He/she’s
the one
proposing to move the extension from xwiki-sandbox to
xwiki-extensions. He/she’s responsible for ensuring that the extension gets
regular releases and is maintained in general. He/she defines initially the
list of committers in his email proposal for moving the extension.
* We create a PMC (Project Management Committee)
for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to stand
up.
* Contrib extensions keep using the
org.xwiki.contrib package name and
groupid as currently defined at
http://contrib.xwiki.org
Note: The idea is that xwiki core is developed as a team maintaining all
code in
there, xwiki contrib is developed extension by extension (each
extension is an island). This allows anyone to propose extensions in XWiki
Contrib without the need for everyone to support them.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:52 p.m.
New subject: [xwiki-devs] [Proposal] XWiki Core - Second take
Hi,
I have re-read the original thread and scanned the remarks done by Denis
and I have to say that I kind of agree with him on some aspects (or at
least with what I understood from his message since I scanned it quite
quickly).
Basically, I also don`t see much point/value in splitting the code into
multiple repositories. IMO, we should only have the xwiki and the contrib
organisations and move as much as possible from xwiki to contrib, i.e. move
what you call "vertical" extensions to contrib, where everybody can easily
contribute like they would to any other extension.
In terms or differentiating between quality, it should just be a matter of
community feedback and what the community values to be of quality or not.
In other words: ratings, votes, likes, whatever.
The community does not hit the code repositories first to look at where the
code is located, but the other way around. A user first hits the XWiki
Extensions repository (extensions.xwiki.org) or the Extension Manager UI
where he is interested on searching for his needs and deciding based on
ratings, community feedback, featured extensions, etc. which result is best
for him.
IMO, raising the administrative complexity of the community will not help
us work faster/better and will not simplify the contribution process for
outsiders, but rather the opposite.
Additionally, there is nothing stopping us, or anybody else for the matter,
from setting up additional extension repositories where only hand-picked
extensions are published and where users can get certain levels of
guarantees on quality, support, etc. But, like Denis say saying, this is
about the artefacts, not about the sources.
If we are worried about people from contrib making bad commits on
high-profile contrib extensions, we can easily revert and warn the
misbehaving user. On 3 strikes he's out. Personally, I find this much
simpler and in line with our wishes to simplify administrative tasks (and a
bit in line with what we have done for jira where we are giving users more
power in handling issues).
Thanks,
Eduard
P.S.: A reminder to whoever will be doing the moving of code from one repo
to another: please! reference the source repository and the source commit
ID so that when we use blaim we don`t reach a dead end. Specially if there
is no jira issue to track the move, the history is lost to oblivion. (I
know it is technically still there, but it's almost impossible to find)
On Fri, Aug 7, 2015 at 12:46 PM, Gabriela Smeria <gabriela.smeria(a)xwiki.com>
wrote:
Hello Vincent,
Here's my +1 for this proposal.
I strongly agree with one change, because I also had it in mind for a while
now. And that is: moving the "vertical" modules out of the xwiki github
organization repos, since it would be easier for contributors to
participate in improving and/or adding extensions and also, IMO, it will
decrease the build time.
Thanks,
Gabriela
*Gabriela Smeria*
*Web Developer*
gabriela.smeria(a)xwiki.com
skype: smeria.gabriela
On Sun, Aug 2, 2015 at 8:43 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi,
I’d like to progress with this idea so let me summarize this thread’s
discussion so far:
* +1 from Thomas, Guillaume, Caty and Marius
* No answer from Edy on whether he’s ok with the proposal or not. Edy? :)
* Denis seems negative about it but I agree with Thomas’s reply in that
the points raised by Denis do not concern this discussion. Denis
commented
about publishing and installing Extensions,
whereas this proposal was
only
about a location for storing some extensions.
Extensions can be developed
anywhere and don’t have to go into this new proposed location. Denis,
could
you please review this new proposal with this in
mind?
* There were discussions about the name and devs express doubts about
using xwiki-contrib-sandbox.
I’d like to progress so here’s my second proposal. It differs from the
first proposal on the following points:
* All our code is contributed so I don’t think we need to emphasize this
point and I don’t think we need to have “contrib” in the name of the
github
repos. This will lead to shorter names which is
better.
* I propose to have 3 github org:
** xwiki-core (currently “xwiki” but we should probably rename it -
Github
will create redirects and the only downside is
that we need to check it
out
for making repo changes)
** xwiki-extensions (new). For maintained and good quality level
extensions, following the charter defined in the first proposal (we’ll
tune
it). Committers are added extension by extension
and will be voted on the
devs list for now, by the xwiki core devs (we’ll tune that later on)
** xwiki-incubator (currently “xwiki-contrib” but we should rename it).
Extensions in xwiki-extensions that are no longer working with the latest
LTS and that nobody is fixing will move back to xwiki-incubator too.
* I propose to change the goal of the contrib.xwiki.org wiki and to
expand its goal. Right now it’s focused about the xwiki-contrib
organization on GitHub. I propose to make it the wiki that explains how
to
make contributions to the XWiki ecosystem in
general. We would move
http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages
for explaining how to contribute to xwiki-core, xwiki-extensions and
xwiki-incubator.
* ATM we should continue to use the “org.xwiki.contrib" groupid for code
in the xwiki-incubator and xwiki-extensions organizations. Ideally we
should use org.xwiki.extension but it’s already used by the Extension
module in xwiki-core. An option would have been to use org.xwiki.core for
the core but that would break too much code so the only option is to keep
having a special prefix for non-core code. Other ideas:
“org.xwiki.module”, “org.xwiki.ext”, “org.xwiki.external”,
“org.xwiki.addon”.
The simplest is to keep “org.xwiki.contrib” I
think, WDYT?
Once (and if) we agree on this, I’d like to quickly move some existing
extensions from the xwiki-core organization into xwiki-extensions,
starting
with the FAQ Application, in order to start
testing this new
organization.
WDYT?
Thanks
-Vincent
On 3 Dec 2014 at 15:58:36, vincent(a)massol.net (vincent(a)massol.net
(mailto:
vincent(a)massol.net)) wrote:
> Hi committers (and devs in general),
>
> I’m submitting to you this idea, to try to improve the xwiki open
source
project and to give it a new dynamism. I believe
the topics discussed
below
are made even more important since we’re soon
going to develop the notion
of flavors in XWiki.
(i.e.
Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the
xwiki github
organization, the less easy it is for non-“XWiki Dev Team” committers
to
participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by
only keeping “core” modules
> * A “core" module is defined by being a generic transversal module that can be used in lots of XWiki flavors, if not
all). This is opposed
to
“vertical” modules which are modules specific of
a usage of XWiki.
installs,
** Examples of “core" modules: logging
module, configuration module,
distribution wizard, statistics application,
annotations, active one base flavor (the “XWiki” flavor), etc
Note
** Example of “vertical” modules: meeting manager
application, blog
application, FAQ application, flavors (except the base flavor),
etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github
organization repos
* It would be good to separate sandbox extensions
from 1st class
extensions that are maintained and developed following best
practices. We
need some way to maintain the quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core”
(it’s too
complex to rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team”
(and committers in
there are called “XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github
organizations (technically we
rename it to “xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly proposed
extensions or abandoned extensions are
located
** “xwiki-contrib-extensions”, where maintained
extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would
be granted
one and he/she’d be given write access to all repos in the
xwiki-contrib-sandbox organization.
* We define some rules for graduating from
xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in
xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is
maintained during that
time and will survive the test of time - most extensions will die in the
first months)
** The extension should have had more than 2
releases and be published
on extensions.xwiki.org(http://extensions.xwiki.org) with
documentation
** The extension should work with the latest LTS
version of XWiki + the
latest stable version of XWiki (right now that would be
5.4.5 + 6.3). that if the extension has to use new API it’s ok
that it doesn’t work on
the latest LTS.
gets
** Generally follow the practices defined at
http://dev.xwiki.org
* Each extension in xwiki-extensions has a leader/maintainer. He/she’s
the one
proposing to move the extension from xwiki-sandbox to
xwiki-extensions. He/she’s responsible for ensuring that the extension regular releases and is maintained in general.
He/she defines initially
the
list of committers in his email proposal for
moving the extension.
stand
* We create a PMC (Project Management Committee)
for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to up.
all
* Contrib extensions keep using the
org.xwiki.contrib package name and
groupid as currently defined at
http://contrib.xwiki.org
>
> Note: The idea is that xwiki core is developed as a team maintaining code in there, xwiki contrib is developed
extension by extension (each
extension is an island). This allows anyone to propose extensions in
XWiki
Contrib without the need for everyone to support
them.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:07 p.m.
New subject: [xwiki-devs] [Proposal] XWiki Core - Second take
On Fri, Aug 7, 2015 at 4:52 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
Hi,
I have re-read the original thread and scanned the remarks done by Denis
and I have to say that I kind of agree with him on some aspects (or at
least with what I understood from his message since I scanned it quite
quickly).
Basically, I also don`t see much point/value in splitting the code into
multiple repositories. IMO, we should only have the xwiki and the contrib
organisations and move as much as possible from xwiki to contrib, i.e. move
what you call "vertical" extensions to contrib, where everybody can easily
contribute like they would to any other extension.
In terms or differentiating between quality, it should just be a matter of
community feedback and what the community values to be of quality or not.
In other words: ratings, votes, likes, whatever.
The community does not hit the code repositories first to look at where the
code is located, but the other way around. A user first hits the XWiki
Extensions repository (extensions.xwiki.org) or the Extension Manager UI
where he is interested on searching for his needs and deciding based on
ratings, community feedback, featured extensions, etc. which result is best
for him.
IMO, raising the administrative complexity of the community will not help
us work faster/better and will not simplify the contribution process for
outsiders, but rather the opposite.
Additionally, there is nothing stopping us, or anybody else for the matter,
from setting up additional extension repositories where only hand-picked
extensions are published and where users can get certain levels of
guarantees on quality, support, etc. But, like Denis say saying, this is
about the artefacts, not about the sources.
If we are worried about people from contrib making bad commits on
high-profile contrib extensions, we can easily revert and warn the
misbehaving user. On 3 strikes he's out. Personally, I find this much
simpler and in line with our wishes to simplify administrative tasks (and a
bit in line with what we have done for jira where we are giving users more
power in handling issues).
Thanks,
Eduard
P.S.: A reminder to whoever will be doing the moving
of code from one repo
to another: please! reference the source repository and the source commit
ID so that when we use blaim we don`t reach a dead end. Specially if there
is no jira issue to track the move, the history is lost to oblivion. (I
know it is technically still there, but it's almost impossible to find)
Actually on that subject what I do is copying the history (using the
great "git subtree" extension). See
https://github.com/xwiki-contrib/xwiki-platform-cache-oscache that I
moved recently for example.
On Fri, Aug 7, 2015 at 12:46 PM, Gabriela Smeria <gabriela.smeria(a)xwiki.com>
wrote:
--
Thomas Mortagne
Hello Vincent,
Here's my +1 for this proposal.
I strongly agree with one change, because I also had it in mind for a while
now. And that is: moving the "vertical" modules out of the xwiki github
organization repos, since it would be easier for contributors to
participate in improving and/or adding extensions and also, IMO, it will
decrease the build time.
Thanks,
Gabriela
*Gabriela Smeria*
*Web Developer*
gabriela.smeria(a)xwiki.com
skype: smeria.gabriela
On Sun, Aug 2, 2015 at 8:43 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi,
I’d like to progress with this idea so let me summarize this thread’s
discussion so far:
* +1 from Thomas, Guillaume, Caty and Marius
* No answer from Edy on whether he’s ok with the proposal or not. Edy? :)
* Denis seems negative about it but I agree with Thomas’s reply in that
the points raised by Denis do not concern this discussion. Denis
commented
about publishing and installing Extensions,
whereas this proposal was
only
about a location for storing some extensions.
Extensions can be developed
anywhere and don’t have to go into this new proposed location. Denis,
could
you please review this new proposal with this in
mind?
* There were discussions about the name and devs express doubts about
using xwiki-contrib-sandbox.
I’d like to progress so here’s my second proposal. It differs from the
first proposal on the following points:
* All our code is contributed so I don’t think we need to emphasize this
point and I don’t think we need to have “contrib” in the name of the
github
repos. This will lead to shorter names which is
better.
* I propose to have 3 github org:
** xwiki-core (currently “xwiki” but we should probably rename it -
Github
will create redirects and the only downside is
that we need to check it
out
for making repo changes)
** xwiki-extensions (new). For maintained and good quality level
extensions, following the charter defined in the first proposal (we’ll
tune
it). Committers are added extension by extension
and will be voted on the
devs list for now, by the xwiki core devs (we’ll tune that later on)
** xwiki-incubator (currently “xwiki-contrib” but we should rename it).
Extensions in xwiki-extensions that are no longer working with the latest
LTS and that nobody is fixing will move back to xwiki-incubator too.
* I propose to change the goal of the contrib.xwiki.org wiki and to
expand its goal. Right now it’s focused about the xwiki-contrib
organization on GitHub. I propose to make it the wiki that explains how
to
make contributions to the XWiki ecosystem in
general. We would move
http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages
for explaining how to contribute to xwiki-core, xwiki-extensions and
xwiki-incubator.
* ATM we should continue to use the “org.xwiki.contrib" groupid for code
in the xwiki-incubator and xwiki-extensions organizations. Ideally we
should use org.xwiki.extension but it’s already used by the Extension
module in xwiki-core. An option would have been to use org.xwiki.core for
the core but that would break too much code so the only option is to keep
having a special prefix for non-core code. Other ideas:
“org.xwiki.module”, “org.xwiki.ext”, “org.xwiki.external”,
“org.xwiki.addon”.
The simplest is to keep “org.xwiki.contrib” I
think, WDYT?
Once (and if) we agree on this, I’d like to quickly move some existing
extensions from the xwiki-core organization into xwiki-extensions,
starting
with the FAQ Application, in order to start
testing this new
organization.
WDYT?
Thanks
-Vincent
On 3 Dec 2014 at 15:58:36, vincent(a)massol.net (vincent(a)massol.net
(mailto:
vincent(a)massol.net)) wrote:
> Hi committers (and devs in general),
>
> I’m submitting to you this idea, to try to improve the xwiki open
source
project and to give it a new dynamism. I believe
the topics discussed
below
are made even more important since we’re soon
going to develop the notion
of flavors in XWiki.
(i.e.
Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the
xwiki github
organization, the less easy it is for non-“XWiki Dev Team” committers
to
participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by
only keeping “core” modules
> * A “core" module is defined by being a generic transversal module that can be used in lots of XWiki flavors, if not
all). This is opposed
to
“vertical” modules which are modules specific of
a usage of XWiki.
installs,
** Examples of “core" modules: logging
module, configuration module,
distribution wizard, statistics application,
annotations, active one base flavor (the “XWiki” flavor), etc
Note
** Example of “vertical” modules: meeting manager
application, blog
application, FAQ application, flavors (except the base flavor),
etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github
organization repos
* It would be good to separate sandbox extensions
from 1st class
extensions that are maintained and developed following best
practices. We
need some way to maintain the quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core”
(it’s too
complex to rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team”
(and committers in
there are called “XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github
organizations (technically we
rename it to “xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly proposed
extensions or abandoned extensions are
located
** “xwiki-contrib-extensions”, where maintained
extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would
be granted
one and he/she’d be given write access to all repos in the
xwiki-contrib-sandbox organization.
* We define some rules for graduating from
xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in
xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is
maintained during that
time and will survive the test of time - most extensions will die in the
first months)
** The extension should have had more than 2
releases and be published
on extensions.xwiki.org(http://extensions.xwiki.org) with
documentation
** The extension should work with the latest LTS
version of XWiki + the
latest stable version of XWiki (right now that would be
5.4.5 + 6.3). that if the extension has to use new API it’s ok
that it doesn’t work on
the latest LTS.
gets
** Generally follow the practices defined at
http://dev.xwiki.org
* Each extension in xwiki-extensions has a leader/maintainer. He/she’s
the one
proposing to move the extension from xwiki-sandbox to
xwiki-extensions. He/she’s responsible for ensuring that the extension regular releases and is maintained in general.
He/she defines initially
the
list of committers in his email proposal for
moving the extension.
stand
* We create a PMC (Project Management Committee)
for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to up.
all
* Contrib extensions keep using the
org.xwiki.contrib package name and
groupid as currently defined at
http://contrib.xwiki.org
>
> Note: The idea is that xwiki core is developed as a team maintaining code in there, xwiki contrib is developed
extension by extension (each
extension is an island). This allows anyone to propose extensions in
XWiki
Contrib without the need for everyone to support
them.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8 Aug
8 Aug
11:58 p.m.
New subject: [xwiki-devs] [Proposal] XWiki Core - Second take
Hi Vincent,
I am still not convince by your proposal of splitting in two organizations
xwiki-extension and xwiki-incubator. What is really the benefit ?
IMO, this does not provide any, but will have an annoying disadvantage, the
need to move source code from one organization to the other. Moving source
code repositories is always the source of annoyance, just see how fast the
history aspect has been raised in the thread. Moreover, as I said earlier,
some extension may be good quality at its first release.
Again, I am under the impression that two different aspects are mixed here:
source code location, and binary artefact publication.
So my proposal is to only have 2 organizations, like today (maybe renamed
xwiki-core and xwiki-extensions for more clarity), and to move extension
out of the core to the contrib (extension) organization in individual
repository (using git subtree as suggested by Thomas).
This is simpler and I do not see any drawbacks for the purpose you pursue.
The rest will be, as Thomas mentioned, a matter of artefact publications,
something really unrelated with the location of sources, and as you
mentioned, that may be discussed in a separate thread.
WDYT ?
On Sun, Aug 2, 2015 at 8:43 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi,
I’d like to progress with this idea so let me summarize this thread’s
discussion so far:
* +1 from Thomas, Guillaume, Caty and Marius
* No answer from Edy on whether he’s ok with the proposal or not. Edy? :)
* Denis seems negative about it but I agree with Thomas’s reply in that
the points raised by Denis do not concern this discussion. Denis commented
about publishing and installing Extensions, whereas this proposal was only
about a location for storing some extensions. Extensions can be developed
anywhere and don’t have to go into this new proposed location. Denis, could
you please review this new proposal with this in mind?
* There were discussions about the name and devs express doubts about
using xwiki-contrib-sandbox.
I’d like to progress so here’s my second proposal. It differs from the
first proposal on the following points:
* All our code is contributed so I don’t think we need to emphasize this
point and I don’t think we need to have “contrib” in the name of the github
repos. This will lead to shorter names which is better.
* I propose to have 3 github org:
** xwiki-core (currently “xwiki” but we should probably rename it - Github
will create redirects and the only downside is that we need to check it out
for making repo changes)
** xwiki-extensions (new). For maintained and good quality level
extensions, following the charter defined in the first proposal (we’ll tune
it). Committers are added extension by extension and will be voted on the
devs list for now, by the xwiki core devs (we’ll tune that later on)
** xwiki-incubator (currently “xwiki-contrib” but we should rename it).
Extensions in xwiki-extensions that are no longer working with the latest
LTS and that nobody is fixing will move back to xwiki-incubator too.
* I propose to change the goal of the contrib.xwiki.org wiki and to
expand its goal. Right now it’s focused about the xwiki-contrib
organization on GitHub. I propose to make it the wiki that explains how to
make contributions to the XWiki ecosystem in general. We would move
http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages
for explaining how to contribute to xwiki-core, xwiki-extensions and
xwiki-incubator.
* ATM we should continue to use the “org.xwiki.contrib" groupid for code
in the xwiki-incubator and xwiki-extensions organizations. Ideally we
should use org.xwiki.extension but it’s already used by the Extension
module in xwiki-core. An option would have been to use org.xwiki.core for
the core but that would break too much code so the only option is to keep
having a special prefix for non-core code. Other ideas:
“org.xwiki.module”, “org.xwiki.ext”, “org.xwiki.external”, “org.xwiki.addon”.
The simplest is to keep “org.xwiki.contrib” I think, WDYT?
Once (and if) we agree on this, I’d like to quickly move some existing
extensions from the xwiki-core organization into xwiki-extensions, starting
with the FAQ Application, in order to start testing this new organization.
WDYT?
Thanks
-Vincent
On 3 Dec 2014 at 15:58:36, vincent(a)massol.net (vincent(a)massol.net(mailto:
vincent(a)massol.net)) wrote:
--
Denis Gervalle
SOFTEC sa - CEO
Hi committers (and devs in general),
I’m submitting to you this idea, to try to improve the xwiki open source
project
and to give it a new dynamism. I believe the topics discussed below
are made even more important since we’re soon going to develop the notion
of flavors in XWiki.
Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the
xwiki github
organization, the less easy it is for non-“XWiki Dev Team” committers
to
participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by
only keeping “core” modules
* A “core" module is defined by being a
generic transversal module (i.e.
that can be used in lots of XWiki flavors, if not
all). This is opposed to
“vertical” modules which are modules specific of a usage of XWiki.
** Examples of “core" modules: logging
module, configuration module,
distribution wizard, statistics application,
annotations, active installs,
one base flavor (the “XWiki” flavor), etc
** Example of “vertical” modules: meeting manager
application, blog
application, FAQ application, flavors (except the base flavor),
etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github
organization repos
* It would be good to separate sandbox extensions
from 1st class
extensions that are maintained and developed following best
practices. We
need some way to maintain the quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core”
(it’s too
complex to rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team”
(and committers in
there are called “XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github
organizations (technically we
rename it to “xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly proposed
extensions or abandoned extensions are
located
** “xwiki-contrib-extensions”, where maintained
extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would
be granted
one and he/she’d be given write access to all repos in the
xwiki-contrib-sandbox organization.
* We define some rules for graduating from
xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in
xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is
maintained during that
time and will survive the test of time - most extensions will die in the
first months)
** The extension should have had more than 2
releases and be published
on extensions.xwiki.org(http://extensions.xwiki.org) with
documentation
** The extension should work with the latest LTS
version of XWiki + the
latest stable version of XWiki (right now that would be
5.4.5 + 6.3). Note
that if the extension has to use new API it’s ok that it doesn’t work on
the latest LTS.
** Generally follow the practices defined at
http://dev.xwiki.org
* Each extension in xwiki-extensions has a leader/maintainer. He/she’s
the one
proposing to move the extension from xwiki-sandbox to
xwiki-extensions. He/she’s responsible for ensuring that the extension gets
regular releases and is maintained in general. He/she defines initially the
list of committers in his email proposal for moving the extension.
* We create a PMC (Project Management Committee)
for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to stand
up.
* Contrib extensions keep using the
org.xwiki.contrib package name and
groupid as currently defined at
http://contrib.xwiki.org
Note: The idea is that xwiki core is developed as a team maintaining all
code in
there, xwiki contrib is developed extension by extension (each
extension is an island). This allows anyone to propose extensions in XWiki
Contrib without the need for everyone to support them.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
19 Aug
19 Aug
11:07 a.m.
New subject: [xwiki-devs] [Proposal] XWiki Core - Second take
On Sun, Aug 9, 2015 at 12:58 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
Hi Vincent,
I am still not convince by your proposal of splitting in two organizations
xwiki-extension and xwiki-incubator. What is really the benefit ?
IMO, this does not provide any, but will have an
annoying disadvantage, the
need to move source code from one organization to the other. Moving source
code repositories is always the source of annoyance, just see how fast the
history aspect has been raised in the thread. Moreover, as I said earlier,
some extension may be good quality at its first release.
I agree that moving repos (i.e. the source code) back and forth
between xwiki-extensions and xwiki-incubator is an overhead we should
try to avoid. Ideally the source code should remain in the same place
and we should just "tag" (mark) the repo based on our needs. We can
distinguish high quality extensions at maven level (by publising the
artifacts in a separte maven repo), as Denis suggested. This has the
advantage that we can promote high quality extensions independent of
the place where their source code is (xwiki-contrib or personal repo).
Afterall, when we configure the Extension Manager we specify artifact
repos not source repos.
Again, I am under the impression that two different aspects are mixed here:
source code location, and binary artefact publication.
So my proposal is to only have 2 organizations, like today (maybe renamed
xwiki-core and xwiki-extensions for more clarity), and to move extension
out of the core to the contrib (extension) organization in individual
repository (using git subtree as suggested by Thomas).
This is simpler and I do not see any drawbacks for the purpose you pursue.
The rest will be, as Thomas mentioned, a matter of artefact publications,
something really unrelated with the location of sources, and as you
mentioned, that may be discussed in a separate thread.
WDYT ?
On Sun, Aug 2, 2015 at 8:43 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi,
I’d like to progress with this idea so let me summarize this thread’s
discussion so far:
* +1 from Thomas, Guillaume, Caty and Marius
* No answer from Edy on whether he’s ok with the proposal or not. Edy? :)
* Denis seems negative about it but I agree with Thomas’s reply in that
the points raised by Denis do not concern this discussion. Denis commented
about publishing and installing Extensions, whereas this proposal was only
about a location for storing some extensions. Extensions can be developed
anywhere and don’t have to go into this new proposed location. Denis, could
you please review this new proposal with this in mind?
* There were discussions about the name and devs express doubts about
using xwiki-contrib-sandbox.
I’d like to progress so here’s my second proposal. It differs from the
first proposal on the following points:
* All our code is contributed so I don’t think we need to emphasize this
point and I don’t think we need to have “contrib” in the name of the github
repos. This will lead to shorter names which is better.
* I propose to have 3 github org:
** xwiki-core (currently “xwiki” but we should probably rename it - Github
will create redirects and the only downside is that we need to check it out
for making repo changes)
** xwiki-extensions (new). For maintained and good quality level
extensions, following the charter defined in the first proposal (we’ll tune
it). Committers are added extension by extension and will be voted on the
devs list for now, by the xwiki core devs (we’ll tune that later on)
** xwiki-incubator (currently “xwiki-contrib” but we should rename it).
Extensions in xwiki-extensions that are no longer working with the latest
LTS and that nobody is fixing will move back to xwiki-incubator too.
* I propose to change the goal of the contrib.xwiki.org wiki and to
expand its goal. Right now it’s focused about the xwiki-contrib
organization on GitHub. I propose to make it the wiki that explains how to
make contributions to the XWiki ecosystem in general. We would move
http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages
for explaining how to contribute to xwiki-core, xwiki-extensions and
xwiki-incubator.
* ATM we should continue to use the “org.xwiki.contrib" groupid for code
in the xwiki-incubator and xwiki-extensions organizations. Ideally we
should use org.xwiki.extension but it’s already used by the Extension
module in xwiki-core. An option would have been to use org.xwiki.core for
the core but that would break too much code so the only option is to keep
having a special prefix for non-core code. Other ideas:
“org.xwiki.module”, “org.xwiki.ext”, “org.xwiki.external”, “org.xwiki.addon”.
The simplest is to keep “org.xwiki.contrib” I think, WDYT?
Once (and if) we agree on this, I’d like to quickly move some existing
extensions from the xwiki-core organization into xwiki-extensions, starting
with the FAQ Application, in order to start testing this new organization.
WDYT?
Thanks
-Vincent
On 3 Dec 2014 at 15:58:36, vincent(a)massol.net (vincent(a)massol.net(mailto:
vincent(a)massol.net)) wrote:
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi committers (and devs in general),
I’m submitting to you this idea, to try to improve the xwiki open source
project
and to give it a new dynamism. I believe the topics discussed below
are made even more important since we’re soon going to develop the notion
of flavors in XWiki.
Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the
xwiki github
organization, the less easy it is for non-“XWiki Dev Team” committers
to
participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by
only keeping “core” modules
* A “core" module is defined by being a
generic transversal module (i.e.
that can be used in lots of XWiki flavors, if not
all). This is opposed to
“vertical” modules which are modules specific of a usage of XWiki.
** Examples of “core" modules: logging
module, configuration module,
distribution wizard, statistics application,
annotations, active installs,
one base flavor (the “XWiki” flavor), etc
** Example of “vertical” modules: meeting manager
application, blog
application, FAQ application, flavors (except the base flavor),
etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github
organization repos
* It would be good to separate sandbox extensions
from 1st class
extensions that are maintained and developed following best
practices. We
need some way to maintain the quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core”
(it’s too
complex to rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team”
(and committers in
there are called “XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github
organizations (technically we
rename it to “xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly proposed
extensions or abandoned extensions are
located
** “xwiki-contrib-extensions”, where maintained
extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would
be granted
one and he/she’d be given write access to all repos in the
xwiki-contrib-sandbox organization.
* We define some rules for graduating from
xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in
xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is
maintained during that
time and will survive the test of time - most extensions will die in the
first months)
** The extension should have had more than 2
releases and be published
on extensions.xwiki.org(http://extensions.xwiki.org) with
documentation
** The extension should work with the latest LTS
version of XWiki + the
latest stable version of XWiki (right now that would be
5.4.5 + 6.3). Note
that if the extension has to use new API it’s ok that it doesn’t work on
the latest LTS.
** Generally follow the practices defined at
http://dev.xwiki.org
* Each extension in xwiki-extensions has a leader/maintainer. He/she’s
the one
proposing to move the extension from xwiki-sandbox to
xwiki-extensions. He/she’s responsible for ensuring that the extension gets
regular releases and is maintained in general. He/she defines initially the
list of committers in his email proposal for moving the extension.
* We create a PMC (Project Management Committee)
for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to stand
up.
* Contrib extensions keep using the
org.xwiki.contrib package name and
groupid as currently defined at
http://contrib.xwiki.org
Note: The idea is that xwiki core is developed as a team maintaining all
code in
there, xwiki contrib is developed extension by extension (each
extension is an island). This allows anyone to propose extensions in XWiki
Contrib without the need for everyone to support them.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
18 Jan
18 Jan
5:05 p.m.
New subject: [xwiki-devs] [VOTE] XWiki Core - Take 3
Hi devs,
Since the first 2 takes did not pas, I’m making a new proposal taking into account the
latest comments and making the minimal changes from the current situation to get a
consensus.
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the xwiki github organization, the less easy it
is for non-“XWiki Dev Team” committers to participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github organization by only
keeping “core” modules
* A “core" module is defined by being a generic transversal module (i.e. that can be
used in lots of XWiki flavors, if not all). This is opposed to “vertical” modules which
are modules specific of a usage of XWiki.
** Examples of “core" modules: logging module, configuration module, distribution
wizard, annotations, active installs, one base flavor (the “XWiki” flavor), etc
** Example of “vertical” modules: meeting manager application, blog application, FAQ
application, flavors (except the base flavor), etc
Some consequences:
* We need a new location for several modules that would go out of the xwiki github
organization repos
* It would be good that extensions that were developed inside the xwiki github
organization continue to follow the dev practices of http://dev.xwiki.org
Details:
* We keep the current github organization names for now, i.e. “xwiki” and
“xwiki-contrib”.
* Each extension in xwiki-contrib continues to be an island with a leader (defined in
jira) and continues to be able to decide what dev practices it should follow. The leader
continues to be the one to contact when needing to perform a release. When the leader goes
MIA the next person interested in working on the extension can become its new leader.
* Since extensions moved from the xwiki github organization should continue to follow all
the practices from http://dev.xwiki.org we need a way to indicate this so that code
committed against those and PR can be reviewed in light of these practices. Thus we should
encourage extensions to have a README file in each repo in xwiki-contrib that defines what
practices the extension is following. We’ll also update contrib.xwiki.org with
explanations about this (both for extension creators and for contributors to them).
* Note that on contrib.xwiki.org we will propose a generic template for README files that
should exist for all repos in xwiki-contrib. This template will include (but not be
limited to): Dev practices to follow, Link to e.x.o, Status of the extension (useful to
indicate non-working/abandoned extensions for example), link to its jira.
* When moving an extension from the xwiki github org to xwiki-contrib, depending on the
moved extension, the extension can keep its id (this allows the EM upgrade job to propose
upgrading it). Whenever possible the extension id should be updated to follow the rules of
contrib.xwiki.org (group id of org.xwiki.contrib, artifact id matching the rules). In
addition, since we don’t want to cause API breakages, the java packages can be kept as
org.xwiki.* till the next large refactoring of the extension, at which time it should move
to org.xwiki.contrib.*. Similarly the version of the moved extension should be kept and
not be reset to 1.0-SNAPSHOT. We can probably develop some EM tooling in the future to
handle relocation of extension id transparently.
Please cast your vote.
Here’s my +1
Thanks
-Vincent
PS: The previous 2 takes were proposal but I’m making it a VOTE now because I believe the
“XWiki Core” strategy is important enough so that we need to be sure that committers agree
(based on our voting rules).
On 2 Aug 2015 at 19:43:18, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
Hi,
I’d like to progress with this idea so let me summarize this thread’s discussion so far:
* +1 from Thomas, Guillaume, Caty and Marius
* No answer from Edy on whether he’s ok with the proposal or not. Edy? :)
* Denis seems negative about it but I agree with Thomas’s reply in that the points raised
by Denis do not concern this discussion. Denis commented about publishing and installing
Extensions, whereas this proposal was only about a location for storing some extensions.
Extensions can be developed anywhere and don’t have to go into this new proposed location.
Denis, could you please review this new proposal with this in mind?
* There were discussions about the name and devs express doubts about using
xwiki-contrib-sandbox.
I’d like to progress so here’s my second proposal. It differs from the first proposal on
the following points:
* All our code is contributed so I don’t think we need to emphasize this point and I
don’t think we need to have “contrib” in the name of the github repos. This will lead to
shorter names which is better.
* I propose to have 3 github org:
** xwiki-core (currently “xwiki” but we should probably rename it - Github will create
redirects and the only downside is that we need to check it out for making repo changes)
** xwiki-extensions (new). For maintained and good quality level extensions, following
the charter defined in the first proposal (we’ll tune it). Committers are added extension
by extension and will be voted on the devs list for now, by the xwiki core devs (we’ll
tune that later on)
** xwiki-incubator (currently “xwiki-contrib” but we should rename it). Extensions in
xwiki-extensions that are no longer working with the latest LTS and that nobody is fixing
will move back to xwiki-incubator too.
* I propose to change the goal of the contrib.xwiki.org wiki and to expand its goal.
Right now it’s focused about the xwiki-contrib organization on GitHub. I propose to make
it the wiki that explains how to make contributions to the XWiki ecosystem in general. We
would move http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages for
explaining how to contribute to xwiki-core, xwiki-extensions and xwiki-incubator.
* ATM we should continue to use the “org.xwiki.contrib" groupid for code in the
xwiki-incubator and xwiki-extensions organizations. Ideally we should use
org.xwiki.extension but it’s already used by the Extension module in xwiki-core. An option
would have been to use org.xwiki.core for the core but that would break too much code so
the only option is to keep having a special prefix for non-core code. Other ideas:
“org.xwiki.module”, “org.xwiki.ext”, “org.xwiki.external”, “org.xwiki.addon”. The simplest
is to keep “org.xwiki.contrib” I think, WDYT?
Once (and if) we agree on this, I’d like to quickly move some existing extensions from
the xwiki-core organization into xwiki-extensions, starting with the FAQ Application, in
order to start testing this new organization.
WDYT?
Thanks
-Vincent
On 3 Dec 2014 at 15:58:36, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
> Hi committers (and devs in general),
>
> I’m submitting to you this idea, to try to improve the xwiki open source project and
to give it a new dynamism. I believe the topics discussed below are made even more
important since we’re soon going to develop the notion of flavors in XWiki.
>
> Note that this proposal obsoletes the http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of some extensions in the xwiki github organization), which itself
was obsoleting http://markmail.org/message/ppw2slpgqou2ihai
>
> Issues to solve
> ===============
>
> * The scope of the code maintained by the XWiki Dev Team (== the xwiki github
organization) is increasing but the team stays relatively small
> * The more stuff we move into the repos of the xwiki github organization, the less
easy it is for non-“XWiki Dev Team” committers to participate and we want more
contributions
>
> Proposed solution
> =================
>
> Executive summary:
> * Reduce the scope of all the code located in the xwiki github organization by only
keeping “core” modules
> * A “core" module is defined by being a generic transversal module (i.e. that
can be used in lots of XWiki flavors, if not all). This is opposed to “vertical” modules
which are modules specific of a usage of XWiki.
> ** Examples of “core" modules: logging module, configuration module,
distribution wizard, statistics application, annotations, active installs, one base flavor
(the “XWiki” flavor), etc
> ** Example of “vertical” modules: meeting manager application, blog application, FAQ
application, flavors (except the base flavor), etc
>
> Some consequences:
> * We need a new location for several modules that would go out of the xwiki github
organization repos
> * It would be good to separate sandbox extensions from 1st class extensions that are
maintained and developed following best practices. We need some way to maintain the
quality of important extensions
>
> Detailed Implementation:
> * The “xwiki” github organization’s description becomes “XWiki Core” (it’s too
complex to rename the org to “xwiki-core” IMO)
> * “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in there are called
“XWiki Core Committers”).
> * “xwiki-contrib” is split into 2 github organizations (technically we rename it to
“xwiki-contrib-sandbox”):
> ** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed extensions
or abandoned extensions are located
> ** “xwiki-contrib-extensions”, where maintained extensions are located.
> * These 2 organizations are commonly referred to as “XWiki Contrib"
> * Same as now, anyone requesting a repo in xwiki-contrib-sandbox would be granted
one and he/she’d be given write access to all repos in the xwiki-contrib-sandbox
organization.
> * We define some rules for graduating from xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
> ** The extension should have been in xwiki-contrib-sandbox at least 6 months (this
gives time to see if the extension is maintained during that time and will survive the
test of time - most extensions will die in the first months)
> ** The extension should have had more than 2 releases and be published on
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
> ** The extension should work with the latest LTS version of XWiki + the latest
stable version of XWiki (right now that would be 5.4.5 + 6.3). Note that if the extension
has to use new API it’s ok that it doesn’t work on the latest LTS.
> ** Generally follow the practices defined at http://dev.xwiki.org
> * Each extension in xwiki-extensions has a leader/maintainer. He/she’s the one
proposing to move the extension from xwiki-sandbox to xwiki-extensions. He/she’s
responsible for ensuring that the extension gets regular releases and is maintained in
general. He/she defines initially the list of committers in his email proposal for moving
the extension.
> * We create a PMC (Project Management Committee) for XWiki Contrib, generally in
charge of both xwiki-contrib-sandbox and xwiki-contrib-extensions (voting new extensions
in xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I would send a
mail on devs@ asking who’s interested to be part of this committee. I expect some core
committers + some contrib committers to stand up.
> * Contrib extensions keep using the org.xwiki.contrib package name and groupid as
currently defined at http://contrib.xwiki.org
>
> Note: The idea is that xwiki core is developed as a team maintaining all code in
there, xwiki contrib is developed extension by extension (each extension is an island).
This allows anyone to propose extensions in XWiki Contrib without the need for everyone to
support them.
>
> WDYT?
>
> Thanks
> -Vincent
5:22 p.m.
New subject: [xwiki-devs] [VOTE] XWiki Core - Take 3
Looks good, +1.
On Mon, Jan 18, 2016 at 5:05 PM, vincent(a)massol.net <vincent(a)massol.net> wrote:
Hi devs,
Since the first 2 takes did not pas, I’m making a new proposal taking into account the
latest comments and making the minimal changes from the current situation to get a
consensus.
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the xwiki github organization, the less easy
it is for non-“XWiki Dev Team” committers to participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github organization by only
keeping “core” modules
* A “core" module is defined by being a generic transversal module (i.e. that can be
used in lots of XWiki flavors, if not all). This is opposed to “vertical” modules which
are modules specific of a usage of XWiki.
** Examples of “core" modules: logging module, configuration module, distribution
wizard, annotations, active installs, one base flavor (the “XWiki” flavor), etc
** Example of “vertical” modules: meeting manager application, blog application, FAQ
application, flavors (except the base flavor), etc
Some consequences:
* We need a new location for several modules that would go out of the xwiki github
organization repos
* It would be good that extensions that were developed inside the xwiki github
organization continue to follow the dev practices of http://dev.xwiki.org
Details:
* We keep the current github organization names for now, i.e. “xwiki” and
“xwiki-contrib”.
* Each extension in xwiki-contrib continues to be an island with a leader (defined in
jira) and continues to be able to decide what dev practices it should follow. The leader
continues to be the one to contact when needing to perform a release. When the leader goes
MIA the next person interested in working on the extension can become its new leader.
* Since extensions moved from the xwiki github organization should continue to follow all
the practices from http://dev.xwiki.org we need a way to indicate this so that code
committed against those and PR can be reviewed in light of these practices. Thus we should
encourage extensions to have a README file in each repo in xwiki-contrib that defines what
practices the extension is following. We’ll also update contrib.xwiki.org with
explanations about this (both for extension creators and for contributors to them).
* Note that on contrib.xwiki.org we will propose a generic template for README files that
should exist for all repos in xwiki-contrib. This template will include (but not be
limited to): Dev practices to follow, Link to e.x.o, Status of the extension (useful to
indicate non-working/abandoned extensions for example), link to its jira.
* When moving an extension from the xwiki github org
to xwiki-contrib, depending on the moved extension, the extension can keep its id (this
allows the EM upgrade job to propose upgrading it). Whenever possible the extension id
should be updated to follow the rules of contrib.xwiki.org (group id of org.xwiki.contrib,
artifact id matching the rules). In addition, since we don’t want to cause API breakages,
the java packages can be kept as org.xwiki.* till the next large refactoring of the
extension, at which time it should move to org.xwiki.contrib.*. Similarly the version of
the moved extension should be kept and not be reset to 1.0-SNAPSHOT. We can probably
develop some EM tooling in the future to handle relocation of extension id transparently.
For now it's safer to allow keeping the same id but here are some
reading about extensions upgrades and ids modifications:
* Maven provide some relocation system (basically you release a new
version of the old id which will be used as redirect to the new one)
but need to test how well EM supports it
* Right now we deal with previous id by listing them as features but
feature can also be used for other things like indicating embedded
extensions or actual features/API implemented by several
implementations that can't be installed at the same time. We would
probably need to make it more explicit what was a previous id of the
extension in a different property so that we can safely search for it
in extensions.xwiki.org
* By default upgrade manager only search for extensions explicitly
installed by user (so not installed as dependency) so extensions
installed as XE dependencies for example are not checked anyway
Please cast your vote.
Here’s my +1
Thanks
-Vincent
PS: The previous 2 takes were proposal but I’m making it a VOTE now because I believe the
“XWiki Core” strategy is important enough so that we need to be sure that committers agree
(based on our voting rules).
On 2 Aug 2015 at 19:43:18, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
--
Thomas Mortagne
Hi,
I’d like to progress with this idea so let me summarize this thread’s discussion so far:
* +1 from Thomas, Guillaume, Caty and Marius
* No answer from Edy on whether he’s ok with the proposal or not. Edy? :)
* Denis seems negative about it but I agree with Thomas’s reply in that the points raised
by Denis do not concern this discussion. Denis commented about publishing and installing
Extensions, whereas this proposal was only about a location for storing some extensions.
Extensions can be developed anywhere and don’t have to go into this new proposed location.
Denis, could you please review this new proposal with this in mind?
* There were discussions about the name and devs express doubts about using
xwiki-contrib-sandbox.
I’d like to progress so here’s my second proposal. It differs from the first proposal on
the following points:
* All our code is contributed so I don’t think we need to emphasize this point and I
don’t think we need to have “contrib” in the name of the github repos. This will lead to
shorter names which is better.
* I propose to have 3 github org:
** xwiki-core (currently “xwiki” but we should probably rename it - Github will create
redirects and the only downside is that we need to check it out for making repo changes)
** xwiki-extensions (new). For maintained and good quality level extensions, following
the charter defined in the first proposal (we’ll tune it). Committers are added extension
by extension and will be voted on the devs list for now, by the xwiki core devs (we’ll
tune that later on)
** xwiki-incubator (currently “xwiki-contrib” but we should rename it). Extensions in
xwiki-extensions that are no longer working with the latest LTS and that nobody is fixing
will move back to xwiki-incubator too.
* I propose to change the goal of the contrib.xwiki.org wiki and to expand its goal.
Right now it’s focused about the xwiki-contrib organization on GitHub. I propose to make
it the wiki that explains how to make contributions to the XWiki ecosystem in general. We
would move http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages for
explaining how to contribute to xwiki-core, xwiki-extensions and xwiki-incubator.
* ATM we should continue to use the “org.xwiki.contrib" groupid for code in the
xwiki-incubator and xwiki-extensions organizations. Ideally we should use
org.xwiki.extension but it’s already used by the Extension module in xwiki-core. An option
would have been to use org.xwiki.core for the core but that would break too much code so
the only option is to keep having a special prefix for non-core code. Other ideas:
“org.xwiki.module”, “org.xwiki.ext”, “org.xwiki.external”, “org.xwiki.addon”. The simplest
is to keep “org.xwiki.contrib” I think, WDYT?
Once (and if) we agree on this, I’d like to quickly move some existing extensions from
the xwiki-core organization into xwiki-extensions, starting with the FAQ Application, in
order to start testing this new organization.
WDYT?
Thanks
-Vincent
On 3 Dec 2014 at 15:58:36, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
> Hi committers (and devs in general),
>
> I’m submitting to you this idea, to try to improve the xwiki open source project and
to give it a new dynamism. I believe the topics discussed below are made even more
important since we’re soon going to develop the notion of flavors in XWiki.
>
> Note that this proposal obsoletes the http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of some extensions in the xwiki github organization), which itself
was obsoleting http://markmail.org/message/ppw2slpgqou2ihai
>
> Issues to solve
> ===============
>
> * The scope of the code maintained by the XWiki Dev Team (== the xwiki github
organization) is increasing but the team stays relatively small
> * The more stuff we move into the repos of the xwiki github organization, the less
easy it is for non-“XWiki Dev Team” committers to participate and we want more
contributions
>
> Proposed solution
> =================
>
> Executive summary:
> * Reduce the scope of all the code located in the xwiki github organization by only
keeping “core” modules
> * A “core" module is defined by being a generic transversal module (i.e. that
can be used in lots of XWiki flavors, if not all). This is opposed to “vertical” modules
which are modules specific of a usage of XWiki.
> ** Examples of “core" modules: logging module, configuration module,
distribution wizard, statistics application, annotations, active installs, one base flavor
(the “XWiki” flavor), etc
> ** Example of “vertical” modules: meeting manager application, blog application, FAQ
application, flavors (except the base flavor), etc
>
> Some consequences:
> * We need a new location for several modules that would go out of the xwiki github
organization repos
> * It would be good to separate sandbox extensions from 1st class extensions that are
maintained and developed following best practices. We need some way to maintain the
quality of important extensions
>
> Detailed Implementation:
> * The “xwiki” github organization’s description becomes “XWiki Core” (it’s too
complex to rename the org to “xwiki-core” IMO)
> * “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in there are called
“XWiki Core Committers”).
> * “xwiki-contrib” is split into 2 github organizations (technically we rename it to
“xwiki-contrib-sandbox”):
> ** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed extensions
or abandoned extensions are located
> ** “xwiki-contrib-extensions”, where maintained extensions are located.
> * These 2 organizations are commonly referred to as “XWiki Contrib"
> * Same as now, anyone requesting a repo in xwiki-contrib-sandbox would be granted
one and he/she’d be given write access to all repos in the xwiki-contrib-sandbox
organization.
> * We define some rules for graduating from xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
> ** The extension should have been in xwiki-contrib-sandbox at least 6 months (this
gives time to see if the extension is maintained during that time and will survive the
test of time - most extensions will die in the first months)
> ** The extension should have had more than 2 releases and be published on
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
> ** The extension should work with the latest LTS version of XWiki + the latest
stable version of XWiki (right now that would be 5.4.5 + 6.3). Note that if the extension
has to use new API it’s ok that it doesn’t work on the latest LTS.
> ** Generally follow the practices defined at http://dev.xwiki.org
> * Each extension in xwiki-extensions has a leader/maintainer. He/she’s the one
proposing to move the extension from xwiki-sandbox to xwiki-extensions. He/she’s
responsible for ensuring that the extension gets regular releases and is maintained in
general. He/she defines initially the list of committers in his email proposal for moving
the extension.
> * We create a PMC (Project Management Committee) for XWiki Contrib, generally in
charge of both xwiki-contrib-sandbox and xwiki-contrib-extensions (voting new extensions
in xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I would send a
mail on devs@ asking who’s interested to be part of this committee. I expect some core
committers + some contrib committers to stand up.
> * Contrib extensions keep using the org.xwiki.contrib package name and groupid as
currently defined at http://contrib.xwiki.org
>
> Note: The idea is that xwiki core is developed as a team maintaining all code in
there, xwiki contrib is developed extension by extension (each extension is an island).
This allows anyone to propose extensions in XWiki Contrib without the need for everyone to
support them.
>
> WDYT?
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:37 p.m.
New subject: [xwiki-devs] [VOTE] XWiki Core - Take 3
+1, sounds good to me too :)
On Mon, Jan 18, 2016 at 5:05 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi devs,
Since the first 2 takes did not pas, I’m making a new proposal taking into
account the latest comments and making the minimal changes from the current
situation to get a consensus.
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the xwiki github organization,
the less easy it is for non-“XWiki Dev Team” committers to participate and
we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by only keeping “core” modules
* A “core" module is defined by being a generic transversal module (i.e.
that can be used in lots of XWiki flavors, if not all). This is opposed to
“vertical” modules which are modules specific of a usage of XWiki.
** Examples of “core" modules: logging module, configuration module,
distribution wizard, annotations, active installs, one base flavor (the
“XWiki” flavor), etc
** Example of “vertical” modules: meeting manager application, blog
application, FAQ application, flavors (except the base flavor), etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github organization repos
* It would be good that extensions that were developed inside the xwiki
github organization continue to follow the dev practices of
http://dev.xwiki.org
Details:
* We keep the current github organization names for now, i.e. “xwiki” and
“xwiki-contrib”.
* Each extension in xwiki-contrib continues to be an island with a leader
(defined in jira) and continues to be able to decide what dev practices it
should follow. The leader continues to be the one to contact when needing
to perform a release. When the leader goes MIA the next person interested
in working on the extension can become its new leader.
* Since extensions moved from the xwiki github organization should
continue to follow all the practices from http://dev.xwiki.org we need a
way to indicate this so that code committed against those and PR can be
reviewed in light of these practices. Thus we should encourage extensions
to have a README file in each repo in xwiki-contrib that defines what
practices the extension is following. We’ll also update contrib.xwiki.org with
explanations about this (both for extension creators and for contributors
to them).
Do not forget that you can enforce a lot of practice by defining
constraints in the extension pom for extension in Java, like checkstyles,
etc… which also enforce the quality of coding. Of course this does not
cover everything, but the owner of the repository will surely also check
and review committed code to keep the quality of the extension to a good
level. I am not really afraid by this point, I have already some contrib
extension that follow platform rules, and I have never seen any degradation
yet.
* Note that on contrib.xwiki.org we will propose a
generic template for
README files that should exist for all repos in xwiki-contrib. This
template will include (but not be limited to): Dev practices to follow,
Link to e.x.o, Status of the extension (useful to indicate
non-working/abandoned extensions for example), link to its jira.
* When moving an extension from the xwiki github org to xwiki-contrib,
depending on the moved extension, the extension can keep its id (this
allows the EM upgrade job to propose upgrading it). Whenever possible the
extension id should be updated to follow the rules of contrib.xwiki.org (group
id of org.xwiki.contrib, artifact id matching the rules). In addition,
since we don’t want to cause API breakages, the java packages can be kept
as org.xwiki.* till the next large refactoring of the extension, at which
time it should move to org.xwiki.contrib.*. Similarly the version of the
moved extension should be kept and not be reset to 1.0-SNAPSHOT. We can
probably develop some EM tooling in the future to handle relocation of
extension id transparently.
Please cast your vote.
Here’s my +1
Thanks
-Vincent
PS: The previous 2 takes were proposal but I’m making it a VOTE now
because I believe the “XWiki Core” strategy is important enough so that we
need to be sure that committers agree (based on our voting rules).
On 2 Aug 2015 at 19:43:18, vincent(a)massol.net (vincent(a)massol.net(mailto:
vincent(a)massol.net)) wrote:
--
Denis Gervalle
SOFTEC sa - CEO
Hi,
I’d like to progress with this idea so let me summarize this thread’s
discussion
so far:
* +1 from Thomas, Guillaume, Caty and Marius
* No answer from Edy on whether he’s ok with the proposal or not. Edy? :)
* Denis seems negative about it but I agree with Thomas’s reply in that
the points
raised by Denis do not concern this discussion. Denis commented
about publishing and installing Extensions, whereas this proposal was only
about a location for storing some extensions. Extensions can be developed
anywhere and don’t have to go into this new proposed location. Denis, could
you please review this new proposal with this in mind?
* There were discussions about the name and devs
express doubts about
using xwiki-contrib-sandbox.
I’d like to progress so here’s my second proposal. It differs from the
first
proposal on the following points:
* All our code is contributed so I don’t think we need to emphasize this
point and
I don’t think we need to have “contrib” in the name of the github
repos. This will lead to shorter names which is better.
* I propose to have 3 github org:
** xwiki-core (currently “xwiki” but we should probably rename it -
Github will
create redirects and the only downside is that we need to check
it out for making repo changes)
** xwiki-extensions (new). For maintained and
good quality level
extensions, following the charter defined in the first proposal
(we’ll tune
it). Committers are added extension by extension and will be voted on the
devs list for now, by the xwiki core devs (we’ll tune that later on)
** xwiki-incubator (currently “xwiki-contrib” but
we should rename it).
Extensions in xwiki-extensions that are no longer working
with the latest
LTS and that nobody is fixing will move back to xwiki-incubator too.
* I propose to change the goal of the
contrib.xwiki.org wiki and to
expand its goal. Right now it’s focused about the
xwiki-contrib
organization on GitHub. I propose to make it the wiki that explains how to
make contributions to the XWiki ecosystem in general. We would move
http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages
for explaining how to contribute to xwiki-core, xwiki-extensions and
xwiki-incubator.
* ATM we should continue to use the
“org.xwiki.contrib" groupid for code
in the xwiki-incubator and
xwiki-extensions organizations. Ideally we
should use org.xwiki.extension but it’s already used by the Extension
module in xwiki-core. An option would have been to use org.xwiki.core for
the core but that would break too much code so the only option is to keep
having a special prefix for non-core code. Other ideas: “org.xwiki.module”,
“org.xwiki.ext”, “org.xwiki.external”, “org.xwiki.addon”. The simplest is
to keep “org.xwiki.contrib” I think, WDYT?
Once (and if) we agree on this, I’d like to quickly move some existing
extensions
from the xwiki-core organization into xwiki-extensions, starting
with the FAQ Application, in order to start testing this new organization.
WDYT?
Thanks
-Vincent
On 3 Dec 2014 at 15:58:36, vincent(a)massol.net (vincent(a)massol.net
(mailto:vincent@massol.net)) wrote:
> Hi committers (and devs in general),
>
> I’m submitting to you this idea, to try to improve the xwiki open
source
project and to give it a new dynamism. I believe the topics
discussed below are made even more important since we’re soon going to
develop the notion of flavors in XWiki.
>
> Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
>
> Issues to solve
> ===============
>
> * The scope of the code maintained by the XWiki Dev Team (== the xwiki
github
organization) is increasing but the team stays relatively small
> * The more stuff we move into the repos of
the xwiki github
organization, the less easy it is for non-“XWiki Dev Team”
committers to
participate and we want more contributions
>
> Proposed solution
> =================
>
> Executive summary:
> * Reduce the scope of all the code located in the xwiki github
organization
by only keeping “core” modules
> * A “core" module is defined by being a
generic transversal module
(i.e. that can be used in lots of XWiki flavors, if not
all). This is
opposed to “vertical” modules which are modules specific of a usage of
XWiki.
> ** Examples of “core" modules: logging
module, configuration module,
distribution wizard, statistics application,
annotations, active installs,
one base flavor (the “XWiki” flavor), etc
> ** Example of “vertical” modules: meeting
manager application, blog
application, FAQ application, flavors (except the base
flavor), etc
>
> Some consequences:
> * We need a new location for several modules that would go out of the
xwiki
github organization repos
> * It would be good to separate sandbox
extensions from 1st class
extensions that are maintained and developed following
best practices. We
need some way to maintain the quality of important extensions
>
> Detailed Implementation:
> * The “xwiki” github organization’s description becomes “XWiki Core”
(it’s
too complex to rename the org to “xwiki-core” IMO)
> * “XWiki Dev Team” becomes the “XWiki Core
Team” (and committers in
there are called “XWiki Core Committers”).
> * “xwiki-contrib” is split into 2 github
organizations (technically we
rename it to “xwiki-contrib-sandbox”):
> ** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly
proposed extensions or abandoned extensions are
located
> ** “xwiki-contrib-extensions”, where
maintained extensions are located.
> * These 2 organizations are commonly referred to as “XWiki Contrib"
> * Same as now, anyone requesting a repo in xwiki-contrib-sandbox would
be
granted one and he/she’d be given write access to all repos in the
xwiki-contrib-sandbox organization.
> * We define some rules for graduating from
xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
> ** The extension should have been in
xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is
maintained during that
time and will survive the test of time - most extensions will die in the
first months)
> ** The extension should have had more than 2
releases and be published
on extensions.xwiki.org(http://extensions.xwiki.org) with
documentation
> ** The extension should work with the latest
LTS version of XWiki +
the latest stable version of XWiki (right now that would be
5.4.5 + 6.3).
Note that if the extension has to use new API it’s ok that it doesn’t work
on the latest LTS.
> ** Generally follow the practices defined at
http://dev.xwiki.org
> * Each extension in xwiki-extensions has a leader/maintainer. He/she’s
the
one proposing to move the extension from xwiki-sandbox to
xwiki-extensions. He/she’s responsible for ensuring that the extension gets
regular releases and is maintained in general. He/she defines initially the
list of committers in his email proposal for moving the extension.
> * We create a PMC (Project Management
Committee) for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox
and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to stand
up.
> * Contrib extensions keep using the
org.xwiki.contrib package name and
groupid as currently defined at
http://contrib.xwiki.org
>
> Note: The idea is that xwiki core is developed as a team maintaining
all code
in there, xwiki contrib is developed extension by extension (each
extension is an island). This allows anyone to propose extensions in XWiki
Contrib without the need for everyone to support them.
>
> WDYT?
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:27 p.m.
New subject: [xwiki-devs] [VOTE] XWiki Core - Take 3
+1
Thanks,
Eduard
On Mon, Jan 18, 2016 at 9:37 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
+1, sounds good to me too :)
On Mon, Jan 18, 2016 at 5:05 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
commented
xwiki
Hi devs,
Since the first 2 takes did not pas, I’m making a new proposal taking
into
account the latest comments and making the
minimal changes from the
current
situation to get a consensus.
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the xwiki github organization,
the less easy it is for non-“XWiki Dev Team” committers to participate
and
we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by only keeping “core” modules
* A “core" module is defined by being a generic transversal module (i.e.
that can be used in lots of XWiki flavors, if not all). This is opposed
to
“vertical” modules which are modules specific of
a usage of XWiki.
** Examples of “core" modules: logging module, configuration module,
distribution wizard, annotations, active installs, one base flavor (the
“XWiki” flavor), etc
** Example of “vertical” modules: meeting manager application, blog
application, FAQ application, flavors (except the base flavor), etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github organization repos
* It would be good that extensions that were developed inside the xwiki
github organization continue to follow the dev practices of
http://dev.xwiki.org
Details:
* We keep the current github organization names for now, i.e. “xwiki” and
“xwiki-contrib”.
* Each extension in xwiki-contrib continues to be an island with a leader
(defined in jira) and continues to be able to decide what dev practices
it
should follow. The leader continues to be the one
to contact when needing
to perform a release. When the leader goes MIA the next person interested
in working on the extension can become its new leader.
* Since extensions moved from the xwiki github organization should
continue to follow all the practices from http://dev.xwiki.org we need a
way to indicate this so that code committed against those and PR can be
reviewed in light of these practices. Thus we should encourage extensions
to have a README file in each repo in xwiki-contrib that defines what
practices the extension is following. We’ll also update
contrib.xwiki.org with
explanations about this (both for extension
creators and for contributors
to them).
Do not forget that you can enforce a lot of practice by defining
constraints in the extension pom for extension in Java, like checkstyles,
etc… which also enforce the quality of coding. Of course this does not
cover everything, but the owner of the repository will surely also check
and review committed code to keep the quality of the extension to a good
level. I am not really afraid by this point, I have already some contrib
extension that follow platform rules, and I have never seen any degradation
yet.
* Note that on contrib.xwiki.org we will propose
a generic template for
README files that should exist for all repos in xwiki-contrib. This
template will include (but not be limited to): Dev practices to follow,
Link to e.x.o, Status of the extension (useful to indicate
non-working/abandoned extensions for example), link to its jira.
* When moving an extension from the xwiki github org to xwiki-contrib,
depending on the moved extension, the extension can keep its id (this
allows the EM upgrade job to propose upgrading it). Whenever possible the
extension id should be updated to follow the rules of contrib.xwiki.org
(group
id of org.xwiki.contrib, artifact id matching the
rules). In addition,
since we don’t want to cause API breakages, the java packages can be kept
as org.xwiki.* till the next large refactoring of the extension, at which
time it should move to org.xwiki.contrib.*. Similarly the version of the
moved extension should be kept and not be reset to 1.0-SNAPSHOT. We can
probably develop some EM tooling in the future to handle relocation of
extension id transparently.
Please cast your vote.
Here’s my +1
Thanks
-Vincent
PS: The previous 2 takes were proposal but I’m making it a VOTE now
because I believe the “XWiki Core” strategy is important enough so that
we
need to be sure that committers agree (based on
our voting rules).
On 2 Aug 2015 at 19:43:18, vincent(a)massol.net (vincent(a)massol.net
(mailto:
vincent(a)massol.net)) wrote:
:)
Hi,
I’d like to progress with this idea so let me summarize this thread’s
discussion
so far:
>
> * +1 from Thomas, Guillaume, Caty and Marius
> * No answer from Edy on whether he’s ok with the proposal or not. Edy? * Denis
seems negative about it but I agree with Thomas’s reply in that
the points raised
by Denis do not concern this discussion. Denis about publishing and installing Extensions,
whereas this proposal was
only
about a location for storing some extensions.
Extensions can be developed
anywhere and don’t have to go into this new proposed location. Denis,
could
you please review this new proposal with this in
mind?
this
* There were discussions about the name and devs
express doubts about
using xwiki-contrib-sandbox.
I’d like to progress so here’s my second proposal. It differs from the
first
proposal on the following points:
>
> * All our code is contributed so I don’t think we need to emphasize point and I don’t think we need to have “contrib”
in the name of the
github
repos. This will lead to shorter names which is
better.
check
* I propose to have 3 github org:
** xwiki-core (currently “xwiki” but we should probably rename it -
Github will
create redirects and the only downside is that we need to it out for making repo changes)
tune
** xwiki-extensions (new). For maintained and
good quality level
extensions, following the charter defined in the first proposal
(we’ll it). Committers are added extension by extension
and will be voted on the
devs list for now, by the xwiki core devs (we’ll tune that later on)
to
** xwiki-incubator (currently “xwiki-contrib” but
we should rename it).
Extensions in xwiki-extensions that are no longer working
with the latest
LTS and that nobody is fixing will move back to xwiki-incubator too.
* I propose to change the goal of the
contrib.xwiki.org wiki and to
expand its goal. Right now it’s focused about the
xwiki-contrib
organization on GitHub. I propose to make it the wiki that explains how make contributions to the XWiki ecosystem in
general. We would move
http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages
for explaining how to contribute to xwiki-core, xwiki-extensions and
xwiki-incubator.
> * ATM we should continue to use the “org.xwiki.contrib" groupid for
code
in the xwiki-incubator and xwiki-extensions
organizations. Ideally we
should use org.xwiki.extension but it’s already used by the Extension
module in xwiki-core. An option would have been to use org.xwiki.core for
the core but that would break too much code so the only option is to keep
having a special prefix for non-core code. Other ideas:
“org.xwiki.module”,
“org.xwiki.ext”, “org.xwiki.external”,
“org.xwiki.addon”. The simplest is
to keep “org.xwiki.contrib” I think, WDYT?
starting
Once (and if) we agree on this, I’d like to quickly move some existing
extensions
from the xwiki-core organization into xwiki-extensions, with the FAQ Application, in order to start
testing this new
organization.
WDYT?
Thanks
-Vincent
On 3 Dec 2014 at 15:58:36, vincent(a)massol.net (vincent(a)massol.net
(mailto:vincent@massol.net)) wrote:
> Hi committers (and devs in general),
>
> I’m submitting to you this idea, to try to improve the xwiki open
source
project and to give it a new dynamism. I believe the topics
discussed below are made even more important since we’re soon going to
develop the notion of flavors in XWiki.
>
> Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
> >
> > Issues to solve
> > ===============
> >
> > * The scope of the code maintained by the XWiki Dev Team (== the github organization) is increasing but the team
stays relatively small
installs,
> * The more stuff we move into the repos of
the xwiki github
organization, the less easy it is for non-“XWiki Dev Team”
committers to
participate and we want more contributions
>
> Proposed solution
> =================
>
> Executive summary:
> * Reduce the scope of all the code located in the xwiki github
organization
by only keeping “core” modules
> * A “core" module is defined by being a
generic transversal module
(i.e. that can be used in lots of XWiki flavors, if not
all). This is
opposed to “vertical” modules which are modules specific of a usage of
XWiki.
> ** Examples of “core" modules: logging
module, configuration module,
distribution wizard, statistics application,
annotations, active one base flavor (the “XWiki” flavor), etc
we
> ** Example of “vertical” modules: meeting
manager application, blog
application, FAQ application, flavors (except the base
flavor), etc
>
> Some consequences:
> * We need a new location for several modules that would go out of the
xwiki
github organization repos
> * It would be good to separate sandbox
extensions from 1st class
extensions that are maintained and developed following
best practices. We
need some way to maintain the quality of important extensions
>
> Detailed Implementation:
> * The “xwiki” github organization’s description becomes “XWiki Core”
(it’s
too complex to rename the org to “xwiki-core” IMO)
> * “XWiki Dev Team” becomes the “XWiki Core
Team” (and committers in
there are called “XWiki Core Committers”).
> > * “xwiki-contrib” is split into 2 github organizations (technically rename it to “xwiki-contrib-sandbox”):
located.
> ** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly
proposed extensions or abandoned extensions are
located
> > ** “xwiki-contrib-extensions”, where maintained extensions are > > * These 2 organizations are commonly
referred to as “XWiki Contrib"
> > * Same as now, anyone requesting a repo in xwiki-contrib-sandbox
would
be granted one and he/she’d be given write access
to all repos in the
xwiki-contrib-sandbox organization.
published
> * We define some rules for graduating from
xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
> ** The extension should have been in
xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is
maintained during that
time and will survive the test of time - most extensions will die in the
first months)
> > ** The extension should have had more than 2 releases and be on
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
work
> ** The extension should work with the latest
LTS version of XWiki +
the latest stable version of XWiki (right now that would be
5.4.5 + 6.3).
Note that if the extension has to use new API it’s ok that it doesn’t on the latest LTS.
> > ** Generally follow the practices defined at http://dev.xwiki.org
> > * Each extension in xwiki-extensions has a leader/maintainer.
He/she’s
the one proposing to move the extension from
xwiki-sandbox to
xwiki-extensions. He/she’s responsible for ensuring that the extension
gets
regular releases and is maintained in general.
He/she defines initially
the
list of committers in his email proposal for
moving the extension.
stand
> * We create a PMC (Project Management
Committee) for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox
and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to up.
> > * Contrib extensions keep using the org.xwiki.contrib package name
and
groupid as currently defined at
http://contrib.xwiki.org
(each
>
> Note: The idea is that xwiki core is developed as a team maintaining
all code
in there, xwiki contrib is developed extension by extension extension is an island). This allows anyone to
propose extensions in
XWiki
Contrib without the need for everyone to support
them.
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
>
> WDYT?
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
19 Jan
19 Jan
7:06 a.m.
New subject: [xwiki-devs] [VOTE] XWiki Core - Take 3
+1
Thanks,
Marius
On Mon, Jan 18, 2016 at 6:05 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi devs,
Since the first 2 takes did not pas, I’m making a new proposal taking into
account the latest comments and making the minimal changes from the current
situation to get a consensus.
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the xwiki github organization,
the less easy it is for non-“XWiki Dev Team” committers to participate and
we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by only keeping “core” modules
* A “core" module is defined by being a generic transversal module (i.e.
that can be used in lots of XWiki flavors, if not all). This is opposed to
“vertical” modules which are modules specific of a usage of XWiki.
** Examples of “core" modules: logging module, configuration module,
distribution wizard, annotations, active installs, one base flavor (the
“XWiki” flavor), etc
** Example of “vertical” modules: meeting manager application, blog
application, FAQ application, flavors (except the base flavor), etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github organization repos
* It would be good that extensions that were developed inside the xwiki
github organization continue to follow the dev practices of
http://dev.xwiki.org
Details:
* We keep the current github organization names for now, i.e. “xwiki” and
“xwiki-contrib”.
* Each extension in xwiki-contrib continues to be an island with a leader
(defined in jira) and continues to be able to decide what dev practices it
should follow. The leader continues to be the one to contact when needing
to perform a release. When the leader goes MIA the next person interested
in working on the extension can become its new leader.
* Since extensions moved from the xwiki github organization should
continue to follow all the practices from http://dev.xwiki.org we need a
way to indicate this so that code committed against those and PR can be
reviewed in light of these practices. Thus we should encourage extensions
to have a README file in each repo in xwiki-contrib that defines what
practices the extension is following. We’ll also update contrib.xwiki.org with
explanations about this (both for extension creators and for contributors
to them).
* Note that on contrib.xwiki.org we will propose a generic template for
README files that should exist for all repos in xwiki-contrib. This
template will include (but not be limited to): Dev practices to follow,
Link to e.x.o, Status of the extension (useful to indicate
non-working/abandoned extensions for example), link to its jira.
* When moving an extension from the xwiki github org to xwiki-contrib,
depending on the moved extension, the extension can keep its id (this
allows the EM upgrade job to propose upgrading it). Whenever possible the
extension id should be updated to follow the rules of contrib.xwiki.org (group
id of org.xwiki.contrib, artifact id matching the rules). In addition,
since we don’t want to cause API breakages, the java packages can be kept
as org.xwiki.* till the next large refactoring of the extension, at which
time it should move to org.xwiki.contrib.*. Similarly the version of the
moved extension should be kept and not be reset to 1.0-SNAPSHOT. We can
probably develop some EM tooling in the future to handle relocation of
extension id transparently.
Please cast your vote.
Here’s my +1
Thanks
-Vincent
PS: The previous 2 takes were proposal but I’m making it a VOTE now
because I believe the “XWiki Core” strategy is important enough so that we
need to be sure that committers agree (based on our voting rules).
On 2 Aug 2015 at 19:43:18, vincent(a)massol.net (vincent(a)massol.net(mailto:
vincent(a)massol.net)) wrote:
Hi,
I’d like to progress with this idea so let me summarize this thread’s
discussion
so far:
* +1 from Thomas, Guillaume, Caty and Marius
* No answer from Edy on whether he’s ok with the proposal or not. Edy? :)
* Denis seems negative about it but I agree with Thomas’s reply in that
the points
raised by Denis do not concern this discussion. Denis commented
about publishing and installing Extensions, whereas this proposal was only
about a location for storing some extensions. Extensions can be developed
anywhere and don’t have to go into this new proposed location. Denis, could
you please review this new proposal with this in mind?
* There were discussions about the name and devs
express doubts about
using xwiki-contrib-sandbox.
I’d like to progress so here’s my second proposal. It differs from the
first
proposal on the following points:
* All our code is contributed so I don’t think we need to emphasize this
point and
I don’t think we need to have “contrib” in the name of the github
repos. This will lead to shorter names which is better.
* I propose to have 3 github org:
** xwiki-core (currently “xwiki” but we should probably rename it -
Github will
create redirects and the only downside is that we need to check
it out for making repo changes)
** xwiki-extensions (new). For maintained and
good quality level
extensions, following the charter defined in the first proposal
(we’ll tune
it). Committers are added extension by extension and will be voted on the
devs list for now, by the xwiki core devs (we’ll tune that later on)
** xwiki-incubator (currently “xwiki-contrib” but
we should rename it).
Extensions in xwiki-extensions that are no longer working
with the latest
LTS and that nobody is fixing will move back to xwiki-incubator too.
* I propose to change the goal of the
contrib.xwiki.org wiki and to
expand its goal. Right now it’s focused about the
xwiki-contrib
organization on GitHub. I propose to make it the wiki that explains how to
make contributions to the XWiki ecosystem in general. We would move
http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages
for explaining how to contribute to xwiki-core, xwiki-extensions and
xwiki-incubator.
* ATM we should continue to use the
“org.xwiki.contrib" groupid for code
in the xwiki-incubator and
xwiki-extensions organizations. Ideally we
should use org.xwiki.extension but it’s already used by the Extension
module in xwiki-core. An option would have been to use org.xwiki.core for
the core but that would break too much code so the only option is to keep
having a special prefix for non-core code. Other ideas: “org.xwiki.module”,
“org.xwiki.ext”, “org.xwiki.external”, “org.xwiki.addon”. The simplest is
to keep “org.xwiki.contrib” I think, WDYT?
Once (and if) we agree on this, I’d like to quickly move some existing
extensions
from the xwiki-core organization into xwiki-extensions, starting
with the FAQ Application, in order to start testing this new organization.
WDYT?
Thanks
-Vincent
On 3 Dec 2014 at 15:58:36, vincent(a)massol.net (vincent(a)massol.net
(mailto:vincent@massol.net)) wrote:
> Hi committers (and devs in general),
>
> I’m submitting to you this idea, to try to improve the xwiki open
source
project and to give it a new dynamism. I believe the topics
discussed below are made even more important since we’re soon going to
develop the notion of flavors in XWiki.
>
> Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
>
> Issues to solve
> ===============
>
> * The scope of the code maintained by the XWiki Dev Team (== the xwiki
github
organization) is increasing but the team stays relatively small
> * The more stuff we move into the repos of
the xwiki github
organization, the less easy it is for non-“XWiki Dev Team”
committers to
participate and we want more contributions
>
> Proposed solution
> =================
>
> Executive summary:
> * Reduce the scope of all the code located in the xwiki github
organization
by only keeping “core” modules
> * A “core" module is defined by being a
generic transversal module
(i.e. that can be used in lots of XWiki flavors, if not
all). This is
opposed to “vertical” modules which are modules specific of a usage of
XWiki.
> ** Examples of “core" modules: logging
module, configuration module,
distribution wizard, statistics application,
annotations, active installs,
one base flavor (the “XWiki” flavor), etc
> ** Example of “vertical” modules: meeting
manager application, blog
application, FAQ application, flavors (except the base
flavor), etc
>
> Some consequences:
> * We need a new location for several modules that would go out of the
xwiki
github organization repos
> * It would be good to separate sandbox
extensions from 1st class
extensions that are maintained and developed following
best practices. We
need some way to maintain the quality of important extensions
>
> Detailed Implementation:
> * The “xwiki” github organization’s description becomes “XWiki Core”
(it’s
too complex to rename the org to “xwiki-core” IMO)
> * “XWiki Dev Team” becomes the “XWiki Core
Team” (and committers in
there are called “XWiki Core Committers”).
> * “xwiki-contrib” is split into 2 github
organizations (technically we
rename it to “xwiki-contrib-sandbox”):
> ** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly
proposed extensions or abandoned extensions are
located
> ** “xwiki-contrib-extensions”, where
maintained extensions are located.
> * These 2 organizations are commonly referred to as “XWiki Contrib"
> * Same as now, anyone requesting a repo in xwiki-contrib-sandbox would
be
granted one and he/she’d be given write access to all repos in the
xwiki-contrib-sandbox organization.
> * We define some rules for graduating from
xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
> ** The extension should have been in
xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is
maintained during that
time and will survive the test of time - most extensions will die in the
first months)
> ** The extension should have had more than 2
releases and be published
on extensions.xwiki.org(http://extensions.xwiki.org) with
documentation
> ** The extension should work with the latest
LTS version of XWiki +
the latest stable version of XWiki (right now that would be
5.4.5 + 6.3).
Note that if the extension has to use new API it’s ok that it doesn’t work
on the latest LTS.
> ** Generally follow the practices defined at
http://dev.xwiki.org
> * Each extension in xwiki-extensions has a leader/maintainer. He/she’s
the
one proposing to move the extension from xwiki-sandbox to
xwiki-extensions. He/she’s responsible for ensuring that the extension gets
regular releases and is maintained in general. He/she defines initially the
list of committers in his email proposal for moving the extension.
> * We create a PMC (Project Management
Committee) for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox
and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to stand
up.
> * Contrib extensions keep using the
org.xwiki.contrib package name and
groupid as currently defined at
http://contrib.xwiki.org
>
> Note: The idea is that xwiki core is developed as a team maintaining
all code
in there, xwiki contrib is developed extension by extension (each
extension is an island). This allows anyone to propose extensions in XWiki
Contrib without the need for everyone to support them.
>
> WDYT?
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:24 a.m.
New subject: [xwiki-devs] [VOTE] XWiki Core - Take 3
+1
Thanks,
2016-01-19 7:06 GMT+01:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
+1
Thanks,
Marius
On Mon, Jan 18, 2016 at 6:05 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
commented
xwiki
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hi devs,
Since the first 2 takes did not pas, I’m making a new proposal taking
into
account the latest comments and making the
minimal changes from the
current
situation to get a consensus.
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the xwiki github organization,
the less easy it is for non-“XWiki Dev Team” committers to participate
and
we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by only keeping “core” modules
* A “core" module is defined by being a generic transversal module (i.e.
that can be used in lots of XWiki flavors, if not all). This is opposed
to
“vertical” modules which are modules specific of
a usage of XWiki.
** Examples of “core" modules: logging module, configuration module,
distribution wizard, annotations, active installs, one base flavor (the
“XWiki” flavor), etc
** Example of “vertical” modules: meeting manager application, blog
application, FAQ application, flavors (except the base flavor), etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github organization repos
* It would be good that extensions that were developed inside the xwiki
github organization continue to follow the dev practices of
http://dev.xwiki.org
Details:
* We keep the current github organization names for now, i.e. “xwiki” and
“xwiki-contrib”.
* Each extension in xwiki-contrib continues to be an island with a leader
(defined in jira) and continues to be able to decide what dev practices
it
should follow. The leader continues to be the one
to contact when needing
to perform a release. When the leader goes MIA the next person interested
in working on the extension can become its new leader.
* Since extensions moved from the xwiki github organization should
continue to follow all the practices from http://dev.xwiki.org we need a
way to indicate this so that code committed against those and PR can be
reviewed in light of these practices. Thus we should encourage extensions
to have a README file in each repo in xwiki-contrib that defines what
practices the extension is following. We’ll also update
contrib.xwiki.org with
explanations about this (both for extension
creators and for contributors
to them).
* Note that on contrib.xwiki.org we will propose a generic template for
README files that should exist for all repos in xwiki-contrib. This
template will include (but not be limited to): Dev practices to follow,
Link to e.x.o, Status of the extension (useful to indicate
non-working/abandoned extensions for example), link to its jira.
* When moving an extension from the xwiki github org to xwiki-contrib,
depending on the moved extension, the extension can keep its id (this
allows the EM upgrade job to propose upgrading it). Whenever possible the
extension id should be updated to follow the rules of contrib.xwiki.org
(group
id of org.xwiki.contrib, artifact id matching the
rules). In addition,
since we don’t want to cause API breakages, the java packages can be kept
as org.xwiki.* till the next large refactoring of the extension, at which
time it should move to org.xwiki.contrib.*. Similarly the version of the
moved extension should be kept and not be reset to 1.0-SNAPSHOT. We can
probably develop some EM tooling in the future to handle relocation of
extension id transparently.
Please cast your vote.
Here’s my +1
Thanks
-Vincent
PS: The previous 2 takes were proposal but I’m making it a VOTE now
because I believe the “XWiki Core” strategy is important enough so that
we
need to be sure that committers agree (based on
our voting rules).
On 2 Aug 2015 at 19:43:18, vincent(a)massol.net (vincent(a)massol.net
(mailto:
vincent(a)massol.net)) wrote:
:)
Hi,
I’d like to progress with this idea so let me summarize this thread’s
discussion
so far:
>
> * +1 from Thomas, Guillaume, Caty and Marius
> * No answer from Edy on whether he’s ok with the proposal or not. Edy? * Denis
seems negative about it but I agree with Thomas’s reply in that
the points raised
by Denis do not concern this discussion. Denis about publishing and installing Extensions,
whereas this proposal was
only
about a location for storing some extensions.
Extensions can be developed
anywhere and don’t have to go into this new proposed location. Denis,
could
you please review this new proposal with this in
mind?
this
* There were discussions about the name and devs
express doubts about
using xwiki-contrib-sandbox.
I’d like to progress so here’s my second proposal. It differs from the
first
proposal on the following points:
>
> * All our code is contributed so I don’t think we need to emphasize point and I don’t think we need to have “contrib”
in the name of the
github
repos. This will lead to shorter names which is
better.
check
* I propose to have 3 github org:
** xwiki-core (currently “xwiki” but we should probably rename it -
Github will
create redirects and the only downside is that we need to it out for making repo changes)
tune
** xwiki-extensions (new). For maintained and
good quality level
extensions, following the charter defined in the first proposal
(we’ll it). Committers are added extension by extension
and will be voted on the
devs list for now, by the xwiki core devs (we’ll tune that later on)
to
** xwiki-incubator (currently “xwiki-contrib” but
we should rename it).
Extensions in xwiki-extensions that are no longer working
with the latest
LTS and that nobody is fixing will move back to xwiki-incubator too.
* I propose to change the goal of the
contrib.xwiki.org wiki and to
expand its goal. Right now it’s focused about the
xwiki-contrib
organization on GitHub. I propose to make it the wiki that explains how make contributions to the XWiki ecosystem in
general. We would move
http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages
for explaining how to contribute to xwiki-core, xwiki-extensions and
xwiki-incubator.
> * ATM we should continue to use the “org.xwiki.contrib" groupid for
code
in the xwiki-incubator and xwiki-extensions
organizations. Ideally we
should use org.xwiki.extension but it’s already used by the Extension
module in xwiki-core. An option would have been to use org.xwiki.core for
the core but that would break too much code so the only option is to keep
having a special prefix for non-core code. Other ideas:
“org.xwiki.module”,
“org.xwiki.ext”, “org.xwiki.external”,
“org.xwiki.addon”. The simplest is
to keep “org.xwiki.contrib” I think, WDYT?
starting
Once (and if) we agree on this, I’d like to quickly move some existing
extensions
from the xwiki-core organization into xwiki-extensions, with the FAQ Application, in order to start
testing this new
organization.
WDYT?
Thanks
-Vincent
On 3 Dec 2014 at 15:58:36, vincent(a)massol.net (vincent(a)massol.net
(mailto:vincent@massol.net)) wrote:
> Hi committers (and devs in general),
>
> I’m submitting to you this idea, to try to improve the xwiki open
source
project and to give it a new dynamism. I believe the topics
discussed below are made even more important since we’re soon going to
develop the notion of flavors in XWiki.
>
> Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
> >
> > Issues to solve
> > ===============
> >
> > * The scope of the code maintained by the XWiki Dev Team (== the github organization) is increasing but the team
stays relatively small
installs,
> * The more stuff we move into the repos of
the xwiki github
organization, the less easy it is for non-“XWiki Dev Team”
committers to
participate and we want more contributions
>
> Proposed solution
> =================
>
> Executive summary:
> * Reduce the scope of all the code located in the xwiki github
organization
by only keeping “core” modules
> * A “core" module is defined by being a
generic transversal module
(i.e. that can be used in lots of XWiki flavors, if not
all). This is
opposed to “vertical” modules which are modules specific of a usage of
XWiki.
> ** Examples of “core" modules: logging
module, configuration module,
distribution wizard, statistics application,
annotations, active one base flavor (the “XWiki” flavor), etc
we
> ** Example of “vertical” modules: meeting
manager application, blog
application, FAQ application, flavors (except the base
flavor), etc
>
> Some consequences:
> * We need a new location for several modules that would go out of the
xwiki
github organization repos
> * It would be good to separate sandbox
extensions from 1st class
extensions that are maintained and developed following
best practices. We
need some way to maintain the quality of important extensions
>
> Detailed Implementation:
> * The “xwiki” github organization’s description becomes “XWiki Core”
(it’s
too complex to rename the org to “xwiki-core” IMO)
> * “XWiki Dev Team” becomes the “XWiki Core
Team” (and committers in
there are called “XWiki Core Committers”).
> > * “xwiki-contrib” is split into 2 github organizations (technically rename it to “xwiki-contrib-sandbox”):
located.
> ** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly
proposed extensions or abandoned extensions are
located
> > ** “xwiki-contrib-extensions”, where maintained extensions are > > * These 2 organizations are commonly
referred to as “XWiki Contrib"
> > * Same as now, anyone requesting a repo in xwiki-contrib-sandbox
would
be granted one and he/she’d be given write access
to all repos in the
xwiki-contrib-sandbox organization.
published
> * We define some rules for graduating from
xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
> ** The extension should have been in
xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is
maintained during that
time and will survive the test of time - most extensions will die in the
first months)
> > ** The extension should have had more than 2 releases and be on
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
work
> ** The extension should work with the latest
LTS version of XWiki +
the latest stable version of XWiki (right now that would be
5.4.5 + 6.3).
Note that if the extension has to use new API it’s ok that it doesn’t on the latest LTS.
> > ** Generally follow the practices defined at http://dev.xwiki.org
> > * Each extension in xwiki-extensions has a leader/maintainer.
He/she’s
the one proposing to move the extension from
xwiki-sandbox to
xwiki-extensions. He/she’s responsible for ensuring that the extension
gets
regular releases and is maintained in general.
He/she defines initially
the
list of committers in his email proposal for
moving the extension.
stand
> * We create a PMC (Project Management
Committee) for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox
and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to up.
> > * Contrib extensions keep using the org.xwiki.contrib package name
and
groupid as currently defined at
http://contrib.xwiki.org
(each
>
> Note: The idea is that xwiki core is developed as a team maintaining
all code
in there, xwiki contrib is developed extension by extension extension is an island). This allows anyone to
propose extensions in
XWiki
Contrib without the need for everyone to support
them.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
>
> WDYT?
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
noon
New subject: [xwiki-devs] [VOTE] XWiki Core - Take 3
+1
My only comment is that we will start again to have discrepancies between
applications versions. That's going to be fun :)
Thanks,
Caty
On Tue, Jan 19, 2016 at 11:24 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
+1
Thanks,
2016-01-19 7:06 GMT+01:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
(i.e.
and
needing
contributors
Edy?
developed
the
the
for
is
of
to
the
least
6
documentation
I
maintaining
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
+1
Thanks,
Marius
On Mon, Jan 18, 2016 at 6:05 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
organization,
Hi devs,
Since the first 2 takes did not pas, I’m making a new proposal taking
into
account the latest comments and making the
minimal changes from the
current
> situation to get a consensus.
>
> Issues to solve
> ===============
>
> * The scope of the code maintained by the XWiki Dev Team (== the xwiki
> github organization) is increasing but the team stays relatively small
> * The more stuff we move into the repos of the xwiki github the less
easy it is for non-“XWiki Dev Team” committers to participate
and
> we want more contributions
>
> Proposed solution
> =================
>
> Executive summary:
> * Reduce the scope of all the code located in the xwiki github
> organization by only keeping “core” modules
> * A “core" module is defined by being a generic transversal module that can
be used in lots of XWiki flavors, if not all). This is opposed
to
> “vertical” modules which are modules specific of a usage of XWiki.
> ** Examples of “core" modules: logging module, configuration module,
> distribution wizard, annotations, active installs, one base flavor (the
> “XWiki” flavor), etc
> ** Example of “vertical” modules: meeting manager application, blog
> application, FAQ application, flavors (except the base flavor), etc
>
> Some consequences:
> * We need a new location for several modules that would go out of the
> xwiki github organization repos
> * It would be good that extensions that were developed inside the xwiki
> github organization continue to follow the dev practices of
> http://dev.xwiki.org
>
> Details:
> * We keep the current github organization names for now, i.e. “xwiki” > “xwiki-contrib”.
> * Each extension in xwiki-contrib continues to be an island with a
leader
(defined
in jira) and continues to be able to decide what dev practices
it
> should follow. The leader continues to be the one to contact when > to perform a release. When the leader goes
MIA the next person
interested
> in working on the extension can become its
new leader.
> * Since extensions moved from the xwiki github organization should
> continue to follow all the practices from http://dev.xwiki.org we
need a
> way to indicate this so that code committed
against those and PR can be
> reviewed in light of these practices. Thus we should encourage
extensions
to have a
README file in each repo in xwiki-contrib that defines what
practices the extension is following. We’ll also update
contrib.xwiki.org with
> explanations about this (both for extension creators and for > to them).
> * Note that on contrib.xwiki.org we will propose a generic template
for
> README files that should exist for all repos
in xwiki-contrib. This
> template will include (but not be limited to): Dev practices to follow,
> Link to e.x.o, Status of the extension (useful to indicate
> non-working/abandoned extensions for example), link to its jira.
> * When moving an extension from the xwiki github org to xwiki-contrib,
> depending on the moved extension, the extension can keep its id (this
> allows the EM upgrade job to propose upgrading it). Whenever possible
the
> extension id should be updated to follow the
rules of
contrib.xwiki.org
(group
> id of org.xwiki.contrib, artifact id matching the rules). In addition,
> since we don’t want to cause API breakages, the java packages can be
kept
> as org.xwiki.* till the next large
refactoring of the extension, at
which
> time it should move to org.xwiki.contrib.*.
Similarly the version of
the
moved
extension should be kept and not be reset to 1.0-SNAPSHOT. We can
probably develop some EM tooling in the future to handle relocation of
extension id transparently.
Please cast your vote.
Here’s my +1
Thanks
-Vincent
PS: The previous 2 takes were proposal but I’m making it a VOTE now
because I believe the “XWiki Core” strategy is important enough so that
we
need to be sure that committers agree (based on
our voting rules).
On 2 Aug 2015 at 19:43:18, vincent(a)massol.net (vincent(a)massol.net
(mailto:
> vincent(a)massol.net)) wrote:
>
> > Hi,
> >
> > I’d like to progress with this idea so let me summarize this thread’s
> discussion so far:
> >
> > * +1 from Thomas, Guillaume, Caty and Marius
> > * No answer from Edy on whether he’s ok with the proposal or not. :)
> > * Denis seems negative about it but I agree with Thomas’s reply in
that
the
points raised by Denis do not concern this discussion. Denis
commented
about publishing and installing Extensions,
whereas this proposal was
only
> about a location for storing some extensions. Extensions can be anywhere
and don’t have to go into this new proposed location. Denis,
could
> you please review this new proposal with this in mind?
> > * There were discussions about the name and devs express doubts about
> using xwiki-contrib-sandbox.
> >
> > I’d like to progress so here’s my second proposal. It differs from first
proposal on the following points:
>
> * All our code is contributed so I don’t think we need to emphasize
this
point and I don’t think we need to have “contrib”
in the name of the
github
repos. This will lead to shorter names which is
better.
check
* I propose to have 3 github org:
** xwiki-core (currently “xwiki” but we should probably rename it -
Github will
create redirects and the only downside is that we need to it out for making repo changes)
tune
> it). Committers are added extension by extension and will be voted on ** xwiki-extensions (new). For maintained and
good quality level
extensions, following the charter defined in the first proposal
(we’ll > devs list for now, by the xwiki core devs
(we’ll tune that later on)
> > ** xwiki-incubator (currently “xwiki-contrib” but we should rename
it).
> Extensions in xwiki-extensions that are no
longer working with the
latest
LTS and
that nobody is fixing will move back to xwiki-incubator too.
to
* I propose to change the goal of the
contrib.xwiki.org wiki and to
expand its goal. Right now it’s focused about the
xwiki-contrib
organization on GitHub. I propose to make it the wiki that explains how make contributions to the XWiki ecosystem in
general. We would move
http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages
for explaining how to contribute to xwiki-core, xwiki-extensions and
xwiki-incubator.
> * ATM we should continue to use the “org.xwiki.contrib" groupid for
code
> in the xwiki-incubator and xwiki-extensions organizations. Ideally we
> should use org.xwiki.extension but it’s already used by the Extension
> module in xwiki-core. An option would have been to use org.xwiki.core > the core but that would break too much code
so the only option is to
keep
having a
special prefix for non-core code. Other ideas:
“org.xwiki.module”,
> “org.xwiki.ext”, “org.xwiki.external”, “org.xwiki.addon”. The simplest > to keep “org.xwiki.contrib” I think, WDYT?
> >
> > Once (and if) we agree on this, I’d like to quickly move some
existing
extensions from the xwiki-core organization into xwiki-extensions,
starting
with the FAQ Application, in order to start
testing this new
organization.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> > On 3 Dec 2014 at 15:58:36, vincent(a)massol.net (vincent(a)massol.net
> (mailto:vincent@massol.net)) wrote:
> >
> > > Hi committers (and devs in general),
> > >
> > > I’m submitting to you this idea, to try to improve the xwiki open
> source project and to give it a new dynamism. I believe the topics
> discussed below are made even more important since we’re soon going to
> develop the notion of flavors in XWiki.
> > >
> > > Note that this proposal obsoletes the
> http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move some
extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
> >
> > Issues to solve
> > ===============
> >
> > * The scope of the code maintained by the XWiki Dev Team (== the
xwiki
> github organization) is increasing but the team stays relatively small
> > > * The more stuff we move into the repos of the xwiki github
> organization, the less easy it is for non-“XWiki Dev Team” committers > participate and we want more contributions
> > >
> > > Proposed solution
> > > =================
> > >
> > > Executive summary:
> > > * Reduce the scope of all the code located in the xwiki github
> organization by only keeping “core” modules
> > > * A “core" module is defined by being a generic transversal module
> (i.e. that can be used in lots of XWiki flavors, if not all). This is
> opposed to “vertical” modules which are modules specific of a usage of
> XWiki.
> > > ** Examples of “core" modules: logging module, configuration
module,
distribution wizard, statistics application, annotations, active
installs,
> one base flavor (the “XWiki” flavor), etc
> > > ** Example of “vertical” modules: meeting manager application, blog
> application, FAQ application, flavors (except the base flavor), etc
> > >
> > > Some consequences:
> > > * We need a new location for several modules that would go out of > xwiki github organization repos
> > > * It would be good to separate sandbox extensions from 1st class
> extensions that are maintained and developed following best practices.
We
> need some way to maintain the quality of
important extensions
> > >
> > > Detailed Implementation:
> > > * The “xwiki” github organization’s description becomes “XWiki
Core”
(it’s too
complex to rename the org to “xwiki-core” IMO)
we
> * “XWiki Dev Team” becomes the “XWiki Core
Team” (and committers in
there are called “XWiki Core Committers”).
> > * “xwiki-contrib” is split into 2 github organizations (technically rename it to “xwiki-contrib-sandbox”):
located.
> ** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly
proposed extensions or abandoned extensions are
located
> > ** “xwiki-contrib-extensions”, where maintained extensions are > > * These 2 organizations are commonly
referred to as “XWiki Contrib"
> > * Same as now, anyone requesting a repo in xwiki-contrib-sandbox
would
> be granted one and he/she’d be given write access to all repos in the
> xwiki-contrib-sandbox organization.
> > > * We define some rules for graduating from xwiki-contrib-sandbox to
> xwiki-contrib-extensions. For example:
> > > ** The extension should have been in xwiki-contrib-sandbox at > months (this gives time to see if the
extension is maintained during
that
> time and will survive the test of time -
most extensions will die in
the
first
months)
> > ** The extension should have had more than 2 releases and be
published
> on extensions.xwiki.org(http://extensions.xwiki.org) with > > > ** The extension should work with
the latest LTS version of XWiki +
> the latest stable version of XWiki (right now that would be 5.4.5 +
6.3).
Note that
if the extension has to use new API it’s ok that it doesn’t
work
on the latest LTS.
> > ** Generally follow the practices defined at http://dev.xwiki.org
> > * Each extension in xwiki-extensions has a leader/maintainer.
He/she’s
the one proposing to move the extension from
xwiki-sandbox to
xwiki-extensions. He/she’s responsible for ensuring that the extension
gets
regular releases and is maintained in general.
He/she defines initially
the
> list of committers in his email proposal for moving the extension.
> > > * We create a PMC (Project Management Committee) for XWiki Contrib,
> generally in charge of both xwiki-contrib-sandbox and
> xwiki-contrib-extensions (voting new extensions in
> xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, would
send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to
stand
up.
> > * Contrib extensions keep using the org.xwiki.contrib package name
and
> groupid as currently defined at http://contrib.xwiki.org
> > >
> > > Note: The idea is that xwiki core is developed as a team all code
in there, xwiki contrib is developed extension by extension
(each
extension is an island). This allows anyone to
propose extensions in
XWiki
Contrib without the need for everyone to support
them.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
>
> WDYT?
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:17 p.m.
New subject: [xwiki-devs] [VOTE] XWiki Core - Take 3
On 19 Jan 2016 at 12:01:01, Ecaterina Moraru (Valica)
(valicac@gmail.com(mailto:valicac@gmail.com)) wrote:
+1
My only comment is that we will start again to have discrepancies between
applications versions. That's going to be fun :)
Yes this is my worry too: the compatibilty matrix. The more contrib extensions we have,
the more complex testing and compatibility is. We need to work on improving user
contributions in this domain, directly from inside XE for example.
Thanks
-Vincent
Thanks,
Caty
On Tue, Jan 19, 2016 at 11:24 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
+1
Thanks,
2016-01-19 7:06 GMT+01:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
(i.e.
and
needing
contributors
Edy?
developed
the
the
for
is
of
to
the
least
6
documentation
I
maintaining
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs +1
Thanks,
Marius
On Mon, Jan 18, 2016 at 6:05 PM, vincent(a)massol.net
wrote:
organization,
Hi devs,
Since the first 2 takes did not pas, I’m making a new proposal taking
into
account the latest comments and making the
minimal changes from the
current
> situation to get a consensus.
>
> Issues to solve
> ===============
>
> * The scope of the code maintained by the XWiki Dev Team (== the xwiki
> github organization) is increasing but the team stays relatively small
> * The more stuff we move into the repos of the xwiki github the less
easy it is for non-“XWiki Dev Team” committers to participate
and
> we want more contributions
>
> Proposed solution
> =================
>
> Executive summary:
> * Reduce the scope of all the code located in the xwiki github
> organization by only keeping “core” modules
> * A “core" module is defined by being a generic transversal module that can
be used in lots of XWiki flavors, if not all). This is opposed
to
> “vertical” modules which are modules specific of a usage of XWiki.
> ** Examples of “core" modules: logging module, configuration module,
> distribution wizard, annotations, active installs, one base flavor (the
> “XWiki” flavor), etc
> ** Example of “vertical” modules: meeting manager application, blog
> application, FAQ application, flavors (except the base flavor), etc
>
> Some consequences:
> * We need a new location for several modules that would go out of the
> xwiki github organization repos
> * It would be good that extensions that were developed inside the xwiki
> github organization continue to follow the dev practices of
> http://dev.xwiki.org
>
> Details:
> * We keep the current github organization names for now, i.e. “xwiki” > “xwiki-contrib”.
> * Each extension in xwiki-contrib continues to be an island with a
leader
(defined
in jira) and continues to be able to decide what dev practices
it
> should follow. The leader continues to be the one to contact when > to perform a release. When the leader goes
MIA the next person
interested
> in working on the extension can become its
new leader.
> * Since extensions moved from the xwiki github organization should
> continue to follow all the practices from http://dev.xwiki.org we
need a
> way to indicate this so that code committed
against those and PR can be
> reviewed in light of these practices. Thus we should encourage
extensions
to have a
README file in each repo in xwiki-contrib that defines what
practices the extension is following. We’ll also update
contrib.xwiki.org with
> explanations about this (both for extension creators and for > to them).
> * Note that on contrib.xwiki.org we will propose a generic template
for
> README files that should exist for all repos
in xwiki-contrib. This
> template will include (but not be limited to): Dev practices to follow,
> Link to e.x.o, Status of the extension (useful to indicate
> non-working/abandoned extensions for example), link to its jira.
> * When moving an extension from the xwiki github org to xwiki-contrib,
> depending on the moved extension, the extension can keep its id (this
> allows the EM upgrade job to propose upgrading it). Whenever possible
the
> extension id should be updated to follow the
rules of
contrib.xwiki.org
(group
> id of org.xwiki.contrib, artifact id matching the rules). In addition,
> since we don’t want to cause API breakages, the java packages can be
kept
> as org.xwiki.* till the next large
refactoring of the extension, at
which
> time it should move to org.xwiki.contrib.*.
Similarly the version of
the
moved
extension should be kept and not be reset to 1.0-SNAPSHOT. We can
probably develop some EM tooling in the future to handle relocation of
extension id transparently.
Please cast your vote.
Here’s my +1
Thanks
-Vincent
PS: The previous 2 takes were proposal but I’m making it a VOTE now
because I believe the “XWiki Core” strategy is important enough so that
we
need to be sure that committers agree (based on
our voting rules).
On 2 Aug 2015 at 19:43:18, vincent(a)massol.net (vincent(a)massol.net
(mailto:
> vincent(a)massol.net)) wrote:
>
> > Hi,
> >
> > I’d like to progress with this idea so let me summarize this thread’s
> discussion so far:
> >
> > * +1 from Thomas, Guillaume, Caty and Marius
> > * No answer from Edy on whether he’s ok with the proposal or not. :)
> > * Denis seems negative about it but I agree with Thomas’s reply in
that
the
points raised by Denis do not concern this discussion. Denis
commented
about publishing and installing Extensions,
whereas this proposal was
only
> about a location for storing some extensions. Extensions can be anywhere
and don’t have to go into this new proposed location. Denis,
could
> you please review this new proposal with this in mind?
> > * There were discussions about the name and devs express doubts about
> using xwiki-contrib-sandbox.
> >
> > I’d like to progress so here’s my second proposal. It differs from first
proposal on the following points:
>
> * All our code is contributed so I don’t think we need to emphasize
this
point and I don’t think we need to have “contrib”
in the name of the
github
repos. This will lead to shorter names which is
better.
> * I propose to have 3 github org:
> ** xwiki-core (currently “xwiki” but we should probably rename it -
Github will create redirects and the only downside is that we need to
check
it out for making repo changes)
> ** xwiki-extensions (new). For maintained and good quality level
extensions, following the charter defined in the first proposal (we’ll
tune
> it). Committers are added extension by extension and will be voted on > devs list for now, by the xwiki core devs
(we’ll tune that later on)
> > ** xwiki-incubator (currently “xwiki-contrib” but we should rename
it).
> Extensions in xwiki-extensions that are no
longer working with the
latest
LTS and
that nobody is fixing will move back to xwiki-incubator too.
> * I propose to change the goal of the contrib.xwiki.org wiki and to
expand its goal. Right now it’s focused about the xwiki-contrib
organization on GitHub. I propose to make it the wiki that explains how
to
make contributions to the XWiki ecosystem in
general. We would move
http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages
for explaining how to contribute to xwiki-core, xwiki-extensions and
xwiki-incubator.
> * ATM we should continue to use the “org.xwiki.contrib" groupid for
code
> in the xwiki-incubator and xwiki-extensions organizations. Ideally we
> should use org.xwiki.extension but it’s already used by the Extension
> module in xwiki-core. An option would have been to use org.xwiki.core > the core but that would break too much code
so the only option is to
keep
having a
special prefix for non-core code. Other ideas:
“org.xwiki.module”,
> “org.xwiki.ext”, “org.xwiki.external”, “org.xwiki.addon”. The simplest > to keep “org.xwiki.contrib” I think, WDYT?
> >
> > Once (and if) we agree on this, I’d like to quickly move some
existing
extensions from the xwiki-core organization into xwiki-extensions,
starting
with the FAQ Application, in order to start
testing this new
organization.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> > On 3 Dec 2014 at 15:58:36, vincent(a)massol.net (vincent(a)massol.net
> (mailto:vincent@massol.net)) wrote:
> >
> > > Hi committers (and devs in general),
> > >
> > > I’m submitting to you this idea, to try to improve the xwiki open
> source project and to give it a new dynamism. I believe the topics
> discussed below are made even more important since we’re soon going to
> develop the notion of flavors in XWiki.
> > >
> > > Note that this proposal obsoletes the
> http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move some
extensions in the xwiki github organization), which itself was
obsoleting http://markmail.org/message/ppw2slpgqou2ihai
> >
> > Issues to solve
> > ===============
> >
> > * The scope of the code maintained by the XWiki Dev Team (== the
xwiki
> github organization) is increasing but the team stays relatively small
> > > * The more stuff we move into the repos of the xwiki github
> organization, the less easy it is for non-“XWiki Dev Team” committers > participate and we want more contributions
> > >
> > > Proposed solution
> > > =================
> > >
> > > Executive summary:
> > > * Reduce the scope of all the code located in the xwiki github
> organization by only keeping “core” modules
> > > * A “core" module is defined by being a generic transversal module
> (i.e. that can be used in lots of XWiki flavors, if not all). This is
> opposed to “vertical” modules which are modules specific of a usage of
> XWiki.
> > > ** Examples of “core" modules: logging module, configuration
module,
distribution wizard, statistics application, annotations, active
installs,
> one base flavor (the “XWiki” flavor), etc
> > > ** Example of “vertical” modules: meeting manager application, blog
> application, FAQ application, flavors (except the base flavor), etc
> > >
> > > Some consequences:
> > > * We need a new location for several modules that would go out of > xwiki github organization repos
> > > * It would be good to separate sandbox extensions from 1st class
> extensions that are maintained and developed following best practices.
We
> need some way to maintain the quality of
important extensions
> > >
> > > Detailed Implementation:
> > > * The “xwiki” github organization’s description becomes “XWiki
Core”
(it’s too
complex to rename the org to “xwiki-core” IMO)
> > * “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in
there are called “XWiki Core Committers”).
> > * “xwiki-contrib” is split into 2 github organizations (technically
we
rename it to “xwiki-contrib-sandbox”):
> > ** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly
proposed extensions or abandoned extensions are located
> > ** “xwiki-contrib-extensions”, where maintained extensions are
located.
> > * These 2 organizations are commonly
referred to as “XWiki Contrib"
> > * Same as now, anyone requesting a repo in xwiki-contrib-sandbox
would
> be granted one and he/she’d be given write access to all repos in the
> xwiki-contrib-sandbox organization.
> > > * We define some rules for graduating from xwiki-contrib-sandbox to
> xwiki-contrib-extensions. For example:
> > > ** The extension should have been in xwiki-contrib-sandbox at > months (this gives time to see if the
extension is maintained during
that
> time and will survive the test of time -
most extensions will die in
the
first
months)
> > ** The extension should have had more than 2 releases and be
published
> on extensions.xwiki.org(http://extensions.xwiki.org) with > > > ** The extension should work with
the latest LTS version of XWiki +
> the latest stable version of XWiki (right now that would be 5.4.5 +
6.3).
Note that
if the extension has to use new API it’s ok that it doesn’t
work
on the latest LTS.
> > ** Generally follow the practices defined at http://dev.xwiki.org
> > * Each extension in xwiki-extensions has a leader/maintainer.
He/she’s
the one proposing to move the extension from
xwiki-sandbox to
xwiki-extensions. He/she’s responsible for ensuring that the extension
gets
regular releases and is maintained in general.
He/she defines initially
the
> list of committers in his email proposal for moving the extension.
> > > * We create a PMC (Project Management Committee) for XWiki Contrib,
> generally in charge of both xwiki-contrib-sandbox and
> xwiki-contrib-extensions (voting new extensions in
> xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, would
send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to
stand
up.
> > * Contrib extensions keep using the org.xwiki.contrib package name
and
> groupid as currently defined at http://contrib.xwiki.org
> > >
> > > Note: The idea is that xwiki core is developed as a team all code
in there, xwiki contrib is developed extension by extension
(each
extension is an island). This allows anyone to
propose extensions in
XWiki
Contrib without the need for everyone to support
them.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
21 Jan
21 Jan
12:28 p.m.
New subject: [xwiki-devs] [VOTE] XWiki Core - Take 3 (RESULT)
Ok, so more than 72 hours have now elapsed and the VOTE is passed!
Results: 7 +1, no 0 and no -1
I’ll update dev.xwiki.org to reflect the fact that the xwiki github organization is now
focused on core extensions only and that vertical extensions are to be located in
xwiki-contrib. Note that the delimitation is a bit fuzzy and the move requires a VOTE
every time so I’ll send another VOTE mail to propose some extensions to move out of
platform.
Thanks
-Vincent
On 19 Jan 2016 at 17:17:42, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
On 19 Jan 2016 at 12:01:01, Ecaterina Moraru (Valica)
(valicac@gmail.com(mailto:valicac@gmail.com)) wrote:
+1
My only comment is that we will start again to have discrepancies between
applications versions. That's going to be fun :)
Yes this is my worry too: the compatibilty matrix. The more contrib extensions we have,
the more complex testing and compatibility is. We need to work on improving user
contributions in this domain, directly from inside XE for example.
Thanks
-Vincent
> Thanks,
> Caty
>
> On Tue, Jan 19, 2016 at 11:24 AM, Guillaume "Louis-Marie" Delhumeau <
> gdelhumeau(a)xwiki.com> wrote:
>
> > +1
> >
> > Thanks,
> >
> > 2016-01-19 7:06 GMT+01:00 Marius Dumitru Florea <
> > mariusdumitru.florea(a)xwiki.com>gt;:
> >
> > > +1
> > >
> > > Thanks,
> > > Marius
> > >
> > > On Mon, Jan 18, 2016 at 6:05 PM, vincent(a)massol.net
> > > wrote:
> > >
> > > > Hi devs,
> > > >
> > > > Since the first 2 takes did not pas, I’m making a new proposal
taking
> > > into
> > > > account the latest comments and making the minimal changes from the
> > > current
> > > > situation to get a consensus.
> > > >
> > > > Issues to solve
> > > > ===============
> > > >
> > > > * The scope of the code maintained by the XWiki Dev Team (== the
xwiki
> > > > github organization) is increasing but the team stays relatively
small
> > > > * The more stuff we move into the repos of the xwiki github
> > organization,
> > > > the less easy it is for non-“XWiki Dev Team” committers to
participate
> > > and
> > > > we want more contributions
> > > >
> > > > Proposed solution
> > > > =================
> > > >
> > > > Executive summary:
> > > > * Reduce the scope of all the code located in the xwiki github
> > > > organization by only keeping “core” modules
> > > > * A “core" module is defined by being a generic transversal
module
> > (i.e.
> > > > that can be used in lots of XWiki flavors, if not all). This is
opposed
> > > to
> > > > “vertical” modules which are modules specific of a usage of XWiki.
> > > > ** Examples of “core" modules: logging module, configuration
module,
> > > > distribution wizard, annotations, active installs, one base flavor
(the
> > > > “XWiki” flavor), etc
> > > > ** Example of “vertical” modules: meeting manager application, blog
> > > > application, FAQ application, flavors (except the base flavor), etc
> > > >
> > > > Some consequences:
> > > > * We need a new location for several modules that would go out of
the
> > > > xwiki github organization repos
> > > > * It would be good that extensions that were developed inside the
xwiki
> > > > github organization continue to follow the dev practices of
> > > > http://dev.xwiki.org
> > > >
> > > > Details:
> > > > * We keep the current github organization names for now, i.e.
“xwiki”
> > and
> > > > “xwiki-contrib”.
> > > > * Each extension in xwiki-contrib continues to be an island with a
> > leader
> > > > (defined in jira) and continues to be able to decide what dev
practices
> > > it
> > > > should follow. The leader continues to be the one to contact when
> > needing
> > > > to perform a release. When the leader goes MIA the next person
> > interested
> > > > in working on the extension can become its new leader.
> > > > * Since extensions moved from the xwiki github organization should
> > > > continue to follow all the practices from http://dev.xwiki.org we
> > need a
> > > > way to indicate this so that code committed against those and PR can
be
> > > > reviewed in light of these practices. Thus we should encourage
> > extensions
> > > > to have a README file in each repo in xwiki-contrib that defines
what
> > > > practices the extension is following. We’ll also update
> > > contrib.xwiki.org with
> > > > explanations about this (both for extension creators and for
> > contributors
> > > > to them).
> > > > * Note that on contrib.xwiki.org we will propose a generic template
> > for
> > > > README files that should exist for all repos in xwiki-contrib. This
> > > > template will include (but not be limited to): Dev practices to
follow,
> > > > Link to e.x.o, Status of the extension (useful to indicate
> > > > non-working/abandoned extensions for example), link to its jira.
> > > > * When moving an extension from the xwiki github org to
xwiki-contrib,
> > > > depending on the moved extension, the extension can keep its id
(this
> > > > allows the EM upgrade job to propose upgrading it). Whenever
possible
> > the
> > > > extension id should be updated to follow the rules of
> > contrib.xwiki.org
> > > (group
> > > > id of org.xwiki.contrib, artifact id matching the rules). In
addition,
> > > > since we don’t want to cause API breakages, the java packages can be
> > kept
> > > > as org.xwiki.* till the next large refactoring of the extension, at
> > which
> > > > time it should move to org.xwiki.contrib.*. Similarly the version of
> > the
> > > > moved extension should be kept and not be reset to 1.0-SNAPSHOT. We
can
> > > > probably develop some EM tooling in the future to handle relocation
of
> > > > extension id transparently.
> > > >
> > > > Please cast your vote.
> > > >
> > > > Here’s my +1
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > > PS: The previous 2 takes were proposal but I’m making it a VOTE now
> > > > because I believe the “XWiki Core” strategy is important enough so
that
> > > we
> > > > need to be sure that committers agree (based on our voting rules).
> > > >
> > > > On 2 Aug 2015 at 19:43:18, vincent(a)massol.net (vincent(a)massol.net
> > > (mailto:
> > > > vincent(a)massol.net)) wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I’d like to progress with this idea so let me summarize this
thread’s
> > > > discussion so far:
> > > > >
> > > > > * +1 from Thomas, Guillaume, Caty and Marius
> > > > > * No answer from Edy on whether he’s ok with the proposal or
not.
> > Edy?
> > > :)
> > > > > * Denis seems negative about it but I agree with Thomas’s reply
in
> > that
> > > > the points raised by Denis do not concern this discussion. Denis
> > > commented
> > > > about publishing and installing Extensions, whereas this proposal
was
> > > only
> > > > about a location for storing some extensions. Extensions can be
> > developed
> > > > anywhere and don’t have to go into this new proposed location.
Denis,
> > > could
> > > > you please review this new proposal with this in mind?
> > > > > * There were discussions about the name and devs express doubts
about
> > > > using xwiki-contrib-sandbox.
> > > > >
> > > > > I’d like to progress so here’s my second proposal. It differs
from
> > the
> > > > first proposal on the following points:
> > > > >
> > > > > * All our code is contributed so I don’t think we need to
emphasize
> > > this
> > > > point and I don’t think we need to have “contrib” in the name of the
> > > github
> > > > repos. This will lead to shorter names which is better.
> > > > > * I propose to have 3 github org:
> > > > > ** xwiki-core (currently “xwiki” but we should probably rename
it -
> > > > Github will create redirects and the only downside is that we need
to
> > > check
> > > > it out for making repo changes)
> > > > > ** xwiki-extensions (new). For maintained and good quality
level
> > > > extensions, following the charter defined in the first proposal
(we’ll
> > > tune
> > > > it). Committers are added extension by extension and will be voted
on
> > the
> > > > devs list for now, by the xwiki core devs (we’ll tune that later on)
> > > > > ** xwiki-incubator (currently “xwiki-contrib” but we should
rename
> > it).
> > > > Extensions in xwiki-extensions that are no longer working with the
> > latest
> > > > LTS and that nobody is fixing will move back to xwiki-incubator too.
> > > > > * I propose to change the goal of the contrib.xwiki.org wiki and
to
> > > > expand its goal. Right now it’s focused about the xwiki-contrib
> > > > organization on GitHub. I propose to make it the wiki that explains
how
> > > to
> > > > make contributions to the XWiki ecosystem in general. We would move
> > > > http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add
pages
> > > > for explaining how to contribute to xwiki-core, xwiki-extensions and
> > > > xwiki-incubator.
> > > > > * ATM we should continue to use the “org.xwiki.contrib"
groupid for
> > > code
> > > > in the xwiki-incubator and xwiki-extensions organizations. Ideally
we
> > > > should use org.xwiki.extension but it’s already used by the
Extension
> > > > module in xwiki-core. An option would have been to use
org.xwiki.core
> > for
> > > > the core but that would break too much code so the only option is to
> > keep
> > > > having a special prefix for non-core code. Other ideas:
> > > “org.xwiki.module”,
> > > > “org.xwiki.ext”, “org.xwiki.external”, “org.xwiki.addon”. The
simplest
> > is
> > > > to keep “org.xwiki.contrib” I think, WDYT?
> > > > >
> > > > > Once (and if) we agree on this, I’d like to quickly move some
> > existing
> > > > extensions from the xwiki-core organization into xwiki-extensions,
> > > starting
> > > > with the FAQ Application, in order to start testing this new
> > > organization.
> > > > >
> > > > > WDYT?
> > > > >
> > > > > Thanks
> > > > > -Vincent
> > > > >
> > > > > On 3 Dec 2014 at 15:58:36, vincent(a)massol.net
(vincent(a)massol.net
> > > > (mailto:vincent@massol.net)) wrote:
> > > > >
> > > > > > Hi committers (and devs in general),
> > > > > >
> > > > > > I’m submitting to you this idea, to try to improve the
xwiki open
> > > > source project and to give it a new dynamism. I believe the topics
> > > > discussed below are made even more important since we’re soon going
to
> > > > develop the notion of flavors in XWiki.
> > > > > >
> > > > > > Note that this proposal obsoletes the
> > > > http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move
> > of
> > > > some extensions in the xwiki github organization), which itself was
> > > > obsoleting http://markmail.org/message/ppw2slpgqou2ihai
> > > > > >
> > > > > > Issues to solve
> > > > > > ===============
> > > > > >
> > > > > > * The scope of the code maintained by the XWiki Dev Team
(== the
> > > xwiki
> > > > github organization) is increasing but the team stays relatively
small
> > > > > > * The more stuff we move into the repos of the xwiki
github
> > > > organization, the less easy it is for non-“XWiki Dev Team”
committers
> > to
> > > > participate and we want more contributions
> > > > > >
> > > > > > Proposed solution
> > > > > > =================
> > > > > >
> > > > > > Executive summary:
> > > > > > * Reduce the scope of all the code located in the xwiki
github
> > > > organization by only keeping “core” modules
> > > > > > * A “core" module is defined by being a generic
transversal module
> > > > (i.e. that can be used in lots of XWiki flavors, if not all). This
is
> > > > opposed to “vertical” modules which are modules specific of a usage
of
> > > > XWiki.
> > > > > > ** Examples of “core" modules: logging module,
configuration
> > module,
> > > > distribution wizard, statistics application, annotations, active
> > > installs,
> > > > one base flavor (the “XWiki” flavor), etc
> > > > > > ** Example of “vertical” modules: meeting manager
application, blog
> > > > application, FAQ application, flavors (except the base flavor), etc
> > > > > >
> > > > > > Some consequences:
> > > > > > * We need a new location for several modules that would go
out of
> > the
> > > > xwiki github organization repos
> > > > > > * It would be good to separate sandbox extensions from 1st
class
> > > > extensions that are maintained and developed following best
practices.
> > We
> > > > need some way to maintain the quality of important extensions
> > > > > >
> > > > > > Detailed Implementation:
> > > > > > * The “xwiki” github organization’s description becomes
“XWiki
> > Core”
> > > > (it’s too complex to rename the org to “xwiki-core” IMO)
> > > > > > * “XWiki Dev Team” becomes the “XWiki Core Team” (and
committers in
> > > > there are called “XWiki Core Committers”).
> > > > > > * “xwiki-contrib” is split into 2 github organizations
(technically
> > > we
> > > > rename it to “xwiki-contrib-sandbox”):
> > > > > > ** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where
newly
> > > > proposed extensions or abandoned extensions are located
> > > > > > ** “xwiki-contrib-extensions”, where maintained extensions
are
> > > located.
> > > > > > * These 2 organizations are commonly referred to as “XWiki
Contrib"
> > > > > > * Same as now, anyone requesting a repo in
xwiki-contrib-sandbox
> > > would
> > > > be granted one and he/she’d be given write access to all repos in
the
> > > > xwiki-contrib-sandbox organization.
> > > > > > * We define some rules for graduating from
xwiki-contrib-sandbox to
> > > > xwiki-contrib-extensions. For example:
> > > > > > ** The extension should have been in xwiki-contrib-sandbox
at
> > least 6
> > > > months (this gives time to see if the extension is maintained during
> > that
> > > > time and will survive the test of time - most extensions will die in
> > the
> > > > first months)
> > > > > > ** The extension should have had more than 2 releases and
be
> > > published
> > > > on extensions.xwiki.org(http://extensions.xwiki.org) with
> > documentation
> > > > > > ** The extension should work with the latest LTS version of
XWiki +
> > > > the latest stable version of XWiki (right now that would be 5.4.5 +
> > 6.3).
> > > > Note that if the extension has to use new API it’s ok that it
doesn’t
> > > work
> > > > on the latest LTS.
> > > > > > ** Generally follow the practices defined at
http://dev.xwiki.org
> > > > > > * Each extension in xwiki-extensions has a
leader/maintainer.
> > > He/she’s
> > > > the one proposing to move the extension from xwiki-sandbox to
> > > > xwiki-extensions. He/she’s responsible for ensuring that the
extension
> > > gets
> > > > regular releases and is maintained in general. He/she defines
initially
> > > the
> > > > list of committers in his email proposal for moving the extension.
> > > > > > * We create a PMC (Project Management Committee) for XWiki
Contrib,
> > > > generally in charge of both xwiki-contrib-sandbox and
> > > > xwiki-contrib-extensions (voting new extensions in
> > > > xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap
it,
> > I
> > > > would send a mail on devs@ asking who’s interested to be part of
this
> > > > committee. I expect some core committers + some contrib committers
to
> > > stand
> > > > up.
> > > > > > * Contrib extensions keep using the org.xwiki.contrib
package name
> > > and
> > > > groupid as currently defined at http://contrib.xwiki.org
> > > > > >
> > > > > > Note: The idea is that xwiki core is developed as a team
> > maintaining
> > > > all code in there, xwiki contrib is developed extension by extension
> > > (each
> > > > extension is an island). This allows anyone to propose extensions in
> > > XWiki
> > > > Contrib without the need for everyone to support them.
> > > > > >
> > > > > > WDYT?
> > > > > >
> > > > > > Thanks
> > > > > > -Vincent
> > > >
> > > > _______________________________________________
> > > > devs mailing list
> > > > devs(a)xwiki.org
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > > _______________________________________________
> > > devs mailing list
> > > devs(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> >
> >
> >
> > --
> > Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
3180
days inactive
3594
days old
24 comments
8 participants
participants (8)
-
Denis Gervalle -
Ecaterina Moraru (Valica) -
Eduard Moraru -
Gabriela Smeria -
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne -
vincent＠massol.net