[xwiki-devs] [Proposal] XWiki Core
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
Sounds good. +1 On Wed, Dec 3, 2014 at 3:57 PM, vincent@massol.net <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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi, On Wed, Dec 3, 2014 at 5:16 PM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
Sounds good. +1
On Wed, Dec 3, 2014 at 3:57 PM, vincent@massol.net <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.
So no plan at this point to address http://xwiki.markmail.org/thread/zohkn73srh7dwom4 and http://xwiki.markmail.org/thread/cuqpsqsxtvslmlkp , right?
** Generally follow the practices defined at http://dev.xwiki.org * Each extension in xwiki-extensions
xwiki-contrib-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.
* 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.
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.
* Contrib extensions keep using the org.xwiki.contrib package name and groupid as currently defined at http://contrib.xwiki.org
"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
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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi Edy, On 3 Dec 2014 at 22:36:34, Eduard Moraru (enygma2002@gmail.com(mailto:enygma2002@gmail.com)) wrote:
Hi,
On Wed, Dec 3, 2014 at 5:16 PM, Thomas Mortagne wrote:
Sounds good. +1
On Wed, Dec 3, 2014 at 3:57 PM, 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.
So no plan at this point to address http://xwiki.markmail.org/thread/zohkn73srh7dwom4 and
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.
** Generally follow the practices defined at http://dev.xwiki.org * Each extension in xwiki-extensions
xwiki-contrib-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.
* 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.
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.
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).
* Contrib extensions keep using the org.xwiki.contrib package name and groupid as currently defined at http://contrib.xwiki.org
"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...
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
Hi 2014-12-03 15:57 GMT+01:00 vincent@massol.net <vincent@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
+1 for the proposal. -- Guillaume Delhumeau (gdelhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
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@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”.
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
** “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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
+1 for the proposal.
-- Guillaume Delhumeau (gdelhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
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@massol.net <vincent@massol.net> wrote:
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@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”.
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
** “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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
+1 for the proposal.
-- Guillaume Delhumeau (gdelhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Dec 4, 2014 at 10:37 AM, vincent@massol.net <vincent@massol.net> wrote:
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@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”.
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) ?
Thanks -Vincent
** “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
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...
* 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.
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 ?
* 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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
+1 for the proposal.
-- Guillaume Delhumeau (gdelhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
On Sat, Dec 6, 2014 at 9:56 PM, Denis Gervalle <dgl@softec.lu> wrote:
On Thu, Dec 4, 2014 at 10:37 AM, vincent@massol.net <vincent@massol.net> wrote:
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@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”.
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) ?
Thanks -Vincent
** “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
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...
* 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.
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.
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 ?
* 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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
+1 for the proposal.
-- Guillaume Delhumeau (gdelhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 Thanks, Marius On Wed, Dec 3, 2014 at 4:57 PM, vincent@massol.net <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@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@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
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@xwiki.com skype: smeria.gabriela On Sun, Aug 2, 2015 at 8:43 PM, vincent@massol.net <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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
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@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@xwiki.com skype: smeria.gabriela
On Sun, Aug 2, 2015 at 8:43 PM, vincent@massol.net <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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Aug 7, 2015 at 4:52 PM, Eduard Moraru <enygma2002@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@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@xwiki.com skype: smeria.gabriela
On Sun, Aug 2, 2015 at 8:43 PM, vincent@massol.net <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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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@massol.net <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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
On Sun, Aug 9, 2015 at 12:58 AM, Denis Gervalle <dgl@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@massol.net <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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
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@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@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
Looks good, +1. On Mon, Jan 18, 2016 at 5:05 PM, vincent@massol.net <vincent@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@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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1, sounds good to me too :) On Mon, Jan 18, 2016 at 5:05 PM, vincent@massol.net <vincent@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@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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
+1 Thanks, Eduard On Mon, Jan 18, 2016 at 9:37 PM, Denis Gervalle <dgl@softec.lu> wrote:
+1, sounds good to me too :)
On Mon, Jan 18, 2016 at 5:05 PM, vincent@massol.net <vincent@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@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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
+1 Thanks, Marius On Mon, Jan 18, 2016 at 6:05 PM, vincent@massol.net <vincent@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@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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
+1 Thanks, 2016-01-19 7:06 GMT+01:00 Marius Dumitru Florea < mariusdumitru.florea@xwiki.com>:
+1
Thanks, Marius
On Mon, Jan 18, 2016 at 6:05 PM, vincent@massol.net <vincent@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@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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau (gdelhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
+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@xwiki.com> wrote:
+1
Thanks,
2016-01-19 7:06 GMT+01:00 Marius Dumitru Florea < mariusdumitru.florea@xwiki.com>:
+1
Thanks, Marius
On Mon, Jan 18, 2016 at 6:05 PM, vincent@massol.net <vincent@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@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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau (gdelhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
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@xwiki.com> wrote:
+1
Thanks,
2016-01-19 7:06 GMT+01:00 Marius Dumitru Florea < mariusdumitru.florea@xwiki.com>:
+1
Thanks, Marius
On Mon, Jan 18, 2016 at 6:05 PM, vincent@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@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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau (gdelhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
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@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@xwiki.com> wrote:
+1
Thanks,
2016-01-19 7:06 GMT+01:00 Marius Dumitru Florea < mariusdumitru.florea@xwiki.com>:
+1
Thanks, Marius
On Mon, Jan 18, 2016 at 6:05 PM, vincent@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@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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau (gdelhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
participants (8)
-
Denis Gervalle -
Ecaterina Moraru (Valica) -
Eduard Moraru -
Gabriela Smeria -
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne -
vincent＠massol.net