[xwiki-devs] [VOTE] Have extension repositories in the "xwiki" GitHub Organization
Hi devs, Following the proposal thread at http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on. Rationale/Need =============== The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc * Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features). Governance ========== Details: * Extensions are VOTEd in on a case by case basis. * Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other). * When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization. * FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise. * The Git repository name should be of the form xwiki-<short project name>. <short project name> should be part of the VOTE. * All rules from http://dev.xwiki.org apply * Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes. * Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved. * If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE * We would create one JIRA project per extension * We would create a new JIRA Category called “XWiki Extensions” * We would put the extensions in our CI at http://ci.xwiki.org * The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.<short project name>. Exceptions would need to be discussed. * The group id for extensions having their own repo should be org.xwiki.<short project name>. The <short project name> needs to be part of the VOTE when proposing a new extensions. Here’s my +1 Thanks -Vincent
+1. On 07/07/2014 12:39 PM, [email protected] wrote:
Hi devs,
Following the proposal thread at http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc * Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-<short project name>. <short project name> should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.<short project name>. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.<short project name>. The <short project name> needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu
+1 On Mon, Jul 7, 2014 at 7:24 PM, Sergiu Dumitriu <[email protected]> wrote:
+1.
On 07/07/2014 12:39 PM, [email protected] wrote:
Hi devs,
Following the proposal thread at
http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev
Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc
* Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-<short project name>. <short project name> should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.<short project name>. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.<short project name>. The <short project name> needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
+1 On Tue, Jul 8, 2014 at 1:28 AM, Denis Gervalle <[email protected]> wrote:
+1
On Mon, Jul 7, 2014 at 7:24 PM, Sergiu Dumitriu <[email protected]> wrote:
+1.
On 07/07/2014 12:39 PM, [email protected] wrote:
Hi devs,
Following the proposal thread at
http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev
Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc
* Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-<short project name>. <short project name> should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.<short project name>. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.<short project name>. The <short project name> needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 If the extensions have a different license header than the one used by XWiki, than after the 'donation' the license headers will be replaced. Question: beside the blame, should we have a standard way to mention contributors on that extensions? or initial sponsors? Thanks, caty On Tue, Jul 8, 2014 at 9:51 AM, Thomas Mortagne <[email protected]> wrote:
+1
On Tue, Jul 8, 2014 at 1:28 AM, Denis Gervalle <[email protected]> wrote:
+1
On Mon, Jul 7, 2014 at 7:24 PM, Sergiu Dumitriu <[email protected]> wrote:
+1.
On 07/07/2014 12:39 PM, [email protected] wrote:
Hi devs,
Following the proposal thread at
http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev
Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc
* Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-<short project name>. <short project name> should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see
http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...
** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.<short project name>. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.<short project name>. The <short project name> needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 Thanks, Eduard On Tue, Jul 8, 2014 at 10:17 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
+1
If the extensions have a different license header than the one used by XWiki, than after the 'donation' the license headers will be replaced.
Question: beside the blame, should we have a standard way to mention contributors on that extensions? or initial sponsors?
Thanks, caty
On Tue, Jul 8, 2014 at 9:51 AM, Thomas Mortagne <[email protected]
wrote:
+1
On Tue, Jul 8, 2014 at 1:28 AM, Denis Gervalle <[email protected]> wrote:
+1
On Mon, Jul 7, 2014 at 7:24 PM, Sergiu Dumitriu <[email protected]> wrote:
+1.
On 07/07/2014 12:39 PM, [email protected] wrote:
Hi devs,
Following the proposal thread at
http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev
Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc
* Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-<short project name>. <short project name> should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see
http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...
** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.<short project name>. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.<short project name>. The <short project name> needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Caty, On 8 Jul 2014 at 09:18:35, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote:
+1
If the extensions have a different license header than the one used by XWiki, than after the 'donation' the license headers will be replaced.
Indeed the license needs to be compatible or all who participated in the code need to agree to switch to the LGPL license.
Question: beside the blame, should we have a standard way to mention contributors on that extensions? or initial sponsors?
Yes, as I mentioned below, we would keep the history. Now for e.x.o (pom.xml) we need to decide if we just append “XWiki Dev Team” to the existing list or replace that list. If we decide to replace we can easily have a mention in the text of the extension. Thanks -Vincent
Thanks, caty
On Tue, Jul 8, 2014 at 9:51 AM, Thomas Mortagne wrote:
+1
On Tue, Jul 8, 2014 at 1:28 AM, Denis Gervalle wrote:
+1
On Mon, Jul 7, 2014 at 7:24 PM, Sergiu Dumitriu wrote:
+1.
On 07/07/2014 12:39 PM, [email protected] wrote:
Hi devs,
Following the proposal thread at
http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev
Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc
* Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-> > >> name>. should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see
http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...
** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.. The needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
+1 2014-07-08 9:57 GMT+02:00 [email protected] <[email protected]>:
Hi Caty,
On 8 Jul 2014 at 09:18:35, Ecaterina Moraru (Valica) ([email protected] (mailto:[email protected])) wrote:
+1
If the extensions have a different license header than the one used by XWiki, than after the 'donation' the license headers will be replaced.
Indeed the license needs to be compatible or all who participated in the code need to agree to switch to the LGPL license.
Question: beside the blame, should we have a standard way to mention contributors on that extensions? or initial sponsors?
Yes, as I mentioned below, we would keep the history.
Now for e.x.o (pom.xml) we need to decide if we just append “XWiki Dev Team” to the existing list or replace that list. If we decide to replace we can easily have a mention in the text of the extension.
Thanks -Vincent
Thanks, caty
On Tue, Jul 8, 2014 at 9:51 AM, Thomas Mortagne wrote:
+1
On Tue, Jul 8, 2014 at 1:28 AM, Denis Gervalle wrote:
+1
On Mon, Jul 7, 2014 at 7:24 PM, Sergiu Dumitriu wrote:
+1.
On 07/07/2014 12:39 PM, [email protected] wrote:
Hi devs,
Following the proposal thread at
http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki
Dev Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc
* Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-> > >> name>. should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see
http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...
** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.. The needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 On Jul 7, 2014 7:39 PM, "[email protected]" <[email protected]> wrote:
Hi devs,
Following the proposal thread at
http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev Team
would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc
* Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-<short project name>. <short project name> should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.<short project name>. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.<short project name>. The <short project name> needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Results: 8 +1, no 0, no -1 The vote is passed. I’ve documented it here: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLevel... Going to start implementing it by sending some votes to move some extensions. Note: let’s not forget to update http://dev.xwiki.org/xwiki/bin/view/Community/SourceRepository when new top level repos are added in the xwiki organization. Thanks -Vincent On 7 Jul 2014 at 18:39:19, [email protected] ([email protected](mailto:[email protected])) wrote:
Hi devs,
Following the proposal thread at http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc * Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-. should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.. The needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
Trying to progress on this… Some points: 1) As an exercice, I’ve started listing all extensions currently located in platform that we should move outside of xwiki-platform, if we follow the voted rule below: * Active Installs App * Blog (still bundled in XE ATM) * FAQ App * Git module * IRC Bot App * JIRA module (not the macro) * Link Checker * Menu App * Release App * PHP Macro * Gallery Macro * Python Macro * RSS Macro * Useravatar macro * Repository App * Selenium App (should be moved to contrib actually) * Zip Explorer plugin I’ve also reviewed some apps on xwiki-contrib that we may want to move inside the xwiki GitHub org and here are some candidates (each app would need a manager who volunteer to manage the app as defined by our rules below of course - I’m putting some ideas of names, they’re just ideas!). Note that most of these apps are not ready to be moved and would need some cleanup/some func tests first: * File Manager App - Marius * GitHub Stats App (used on xwiki.org) - Vincent * Forum App - ? * Mocca Calendar App - Clemens * Meeting Manager App - ? * Idea Application - ? * xwikorg flavor - Vincent * Ratings App - ? * Presentation App - Vincent * Wiki Editor Devtools (autocomplete + highlighting) - Edi/Vincent * Video Macro - ? * Diagram App - Marius * Admin Tools App (would need to be cleaned up) - ? * Task Manager App - ? WDYT about both lists? Any opinion? 2) We’ll need to decide the version number for extensions we move from platform. I propose to continue using their current version but detach them from platform once they’re moved. For example the FAQ app, if moved now, would have version 6.4-SNAPSHOT and its next release would be 6.4, then 6.4.1 or 6.5, etc. 3) We’d need to decide what version of XWiki is supported by each extension. Since we officially support 3 versions (last super stable, last stable and dev version), I propose that by default extensions would support the latest super stable version without the bugfixing part. For example right now last super stable is 5.4.5 which would mean that extensions would depend on XWiki 5.4 (ie can be installed in XWiki 5.4+). Of course if some extensions require a new feature that has only be added recently (for example webjars) then it could decide to only support more recent versions of XWiki but it would be on an exception basis. WDYT? Thanks -Vincent On 14 Jul 2014 at 14:11:14, [email protected] ([email protected](mailto:[email protected])) wrote:
Results: 8 +1, no 0, no -1
The vote is passed. I’ve documented it here: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLevel...
Going to start implementing it by sending some votes to move some extensions.
Note: let’s not forget to update http://dev.xwiki.org/xwiki/bin/view/Community/SourceRepository when new top level repos are added in the xwiki organization.
Thanks -Vincent
On 7 Jul 2014 at 18:39:19, [email protected] ([email protected](mailto:[email protected])) wrote:
Hi devs,
Following the proposal thread at http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc * Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-. should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.. The needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Nov 13, 2014 at 5:15 PM, [email protected] <[email protected]> wrote:
Trying to progress on this…
Some points:
1) As an exercice, I’ve started listing all extensions currently located in platform that we should move outside of xwiki-platform, if we follow the voted rule below:
* Active Installs App * Blog (still bundled in XE ATM) * FAQ App * Git module * IRC Bot App * JIRA module (not the macro) * Link Checker * Menu App * Release App * PHP Macro * Gallery Macro * Python Macro * RSS Macro * Useravatar macro * Repository App * Selenium App (should be moved to contrib actually) * Zip Explorer plugin
I’ve also reviewed some apps on xwiki-contrib that we may want to move inside the xwiki GitHub org and here are some candidates (each app would need a manager who volunteer to manage the app as defined by our rules below of course - I’m putting some ideas of names, they’re just ideas!). Note that most of these apps are not ready to be moved and would need some cleanup/some func tests first:
* File Manager App - Marius * GitHub Stats App (used on xwiki.org) - Vincent * Forum App - ? * Mocca Calendar App - Clemens * Meeting Manager App - ? * Idea Application - ? * xwikorg flavor - Vincent * Ratings App - ? * Presentation App - Vincent * Wiki Editor Devtools (autocomplete + highlighting) - Edi/Vincent * Video Macro - ? * Diagram App - Marius * Admin Tools App (would need to be cleaned up) - ? * Task Manager App - ?
WDYT about both lists? Any opinion?
I think those two lists should be in different mails. +1 of course for the first one list, the second one is a bit more complex decision which also involve the authors of theses extensions and it should probably be a case by case discussion.
2) We’ll need to decide the version number for extensions we move from platform. I propose to continue using their current version but detach them from platform once they’re moved. For example the FAQ app, if moved now, would have version 6.4-SNAPSHOT and its next release would be 6.4, then 6.4.1 or 6.5, etc.
What about Maven ids ? Should we keep org.xwiki.platform:xwiki-platform-* suffix which would not make much sense anymore from extension point of view ? Keeping the version would be the safest from EM point for view when upgrading those extensions.
3) We’d need to decide what version of XWiki is supported by each extension. Since we officially support 3 versions (last super stable, last stable and dev version), I propose that by default extensions would support the latest super stable version without the bugfixing part. For example right now last super stable is 5.4.5 which would mean that extensions would depend on XWiki 5.4 (ie can be installed in XWiki 5.4+). Of course if some extensions require a new feature that has only be added recently (for example webjars) then it could decide to only support more recent versions of XWiki but it would be on an exception basis.
Actually the last LTS is 5.4.6. I would say when moving en extension out of platform it's mandatory to put the lowest supported version in the supported branches and it's even better but not mandatory to put an even older version (I'm sure many users will be happy about that).
WDYT?
Thanks -Vincent
On 14 Jul 2014 at 14:11:14, [email protected] ([email protected](mailto:[email protected])) wrote:
Results: 8 +1, no 0, no -1
The vote is passed. I’ve documented it here: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLevel...
Going to start implementing it by sending some votes to move some extensions.
Note: let’s not forget to update http://dev.xwiki.org/xwiki/bin/view/Community/SourceRepository when new top level repos are added in the xwiki organization.
Thanks -Vincent
On 7 Jul 2014 at 18:39:19, [email protected] ([email protected](mailto:[email protected])) wrote:
Hi devs,
Following the proposal thread at http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc * Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-. should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.. The needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Thu, Nov 13, 2014 at 6:15 PM, [email protected] <[email protected]> wrote:
Trying to progress on this…
Some points:
1) As an exercice, I’ve started listing all extensions currently located in platform that we should move outside of xwiki-platform, if we follow the voted rule below:
* Active Installs App * Blog (still bundled in XE ATM) * FAQ App * Git module * IRC Bot App * JIRA module (not the macro) * Link Checker * Menu App * Release App * PHP Macro * Gallery Macro * Python Macro * RSS Macro * Useravatar macro * Repository App * Selenium App (should be moved to contrib actually) * Zip Explorer plugin
The list looks good. We should make some rules for what we move to contrib or not (Selenium, etc. - like the last date we did some commits on the app, if it's still working, etc.), and also a list for functionality that is not packaged as application/macro, like Indexes (Doc, Users), Share page by e-mail, Help, etc. We also have applications like Invitation, Statistics, Annotations, Watchlist, Dashboard that in the future we might want to move and make available just for certain flavors. Also maybe we would want to group somehow the macros?
I’ve also reviewed some apps on xwiki-contrib that we may want to move inside the xwiki GitHub org and here are some candidates (each app would need a manager who volunteer to manage the app as defined by our rules below of course - I’m putting some ideas of names, they’re just ideas!). Note that most of these apps are not ready to be moved and would need some cleanup/some func tests first:
* File Manager App - Marius * GitHub Stats App (used on xwiki.org) - Vincent * Forum App - ? * Mocca Calendar App - Clemens * Meeting Manager App - ? * Idea Application - ? * xwikorg flavor - Vincent * Ratings App - ? * Presentation App - Vincent * Wiki Editor Devtools (autocomplete + highlighting) - Edi/Vincent * Video Macro - ? * Diagram App - Marius * Admin Tools App (would need to be cleaned up) - ? * Task Manager App - ?
WDYT about both lists? Any opinion?
There are some other interesting applications on e.x.o, but I guess one of the rules would be to go over a reviewing process of the code. I don't think we should hurry with the apps and just move them one by one after the review. Some apps might be very useful, but they haven't been updated in a while (Ratings, Admin Tools, Exports, etc). Should Flavors be listed separate?
2) We’ll need to decide the version number for extensions we move from platform. I propose to continue using their current version but detach them from platform once they’re moved. For example the FAQ app, if moved now, would have version 6.4-SNAPSHOT and its next release would be 6.4, then 6.4.1 or 6.5, etc.
3) We’d need to decide what version of XWiki is supported by each extension. Since we officially support 3 versions (last super stable, last stable and dev version), I propose that by default extensions would support the latest super stable version without the bugfixing part. For example right now last super stable is 5.4.5 which would mean that extensions would depend on XWiki 5.4 (ie can be installed in XWiki 5.4+). Of course if some extensions require a new feature that has only be added recently (for example webjars) then it could decide to only support more recent versions of XWiki but it would be on an exception basis.
We are redesigning some apps to make them look good on Flamingo, but the skin is available starting with 6.2. We are making sure they work on Colibri, but was just a note. Thank, Caty
WDYT?
Thanks -Vincent
On 14 Jul 2014 at 14:11:14, [email protected] ([email protected](mailto: [email protected])) wrote:
Results: 8 +1, no 0, no -1
The vote is passed. I’ve documented it here:
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLevel...
Going to start implementing it by sending some votes to move some
extensions.
Note: let’s not forget to update
http://dev.xwiki.org/xwiki/bin/view/Community/SourceRepository when new top level repos are added in the xwiki organization.
Thanks -Vincent
On 7 Jul 2014 at 18:39:19, [email protected] ([email protected]
(mailto:[email protected])) wrote:
Hi devs,
Following the proposal thread at
http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev
Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc
* Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-. should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.. The needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I just added an application in the list. On Thu, Nov 13, 2014 at 05:15:35PM +0100, [email protected] wrote: > Trying to progress on this… > > Some points: > > 1) As an exercice, I’ve started listing all extensions currently located in platform that we should move outside of xwiki-platform, if we follow the voted rule below: > > * Active Installs App > * Blog (still bundled in XE ATM) > * FAQ App > * Git module > * IRC Bot App > * JIRA module (not the macro) > * Link Checker > * Menu App > * Release App > * PHP Macro > * Gallery Macro > * Python Macro > * RSS Macro > * Useravatar macro > * Repository App > * Selenium App (should be moved to contrib actually) > * Zip Explorer plugin > > I’ve also reviewed some apps on xwiki-contrib that we may want to move inside the xwiki GitHub org and here are some candidates (each app would need a manager who volunteer to manage the app as defined by our rules below of course - I’m putting some ideas of names, they’re just ideas!). Note that most of these apps are not ready to be moved and would need some cleanup/some func tests first: > > * File Manager App - Marius > * GitHub Stats App (used on xwiki.org) - Vincent > * Forum App - ? > * Mocca Calendar App - Clemens > * Meeting Manager App - ? > * Idea Application - ? > * xwikorg flavor - Vincent > * Ratings App - ? > * Presentation App - Vincent > * Wiki Editor Devtools (autocomplete + highlighting) - Edi/Vincent > * Video Macro - ? > * Diagram App - Marius > * Admin Tools App (would need to be cleaned up) - ? > * Task Manager App - ? * Project Management App - Ludovic/Yann > > WDYT about both lists? Any opinion? > > 2) We’ll need to decide the version number for extensions we move from platform. I propose to continue using their current version but detach them from platform once they’re moved. For example the FAQ app, if moved now, would have version 6.4-SNAPSHOT and its next release would be 6.4, then 6.4.1 or 6.5, etc. > > 3) We’d need to decide what version of XWiki is supported by each extension. Since we officially support 3 versions (last super stable, last stable and dev version), I propose that by default extensions would support the latest super stable version without the bugfixing part. For example right now last super stable is 5.4.5 which would mean that extensions would depend on XWiki 5.4 (ie can be installed in XWiki 5.4+). Of course if some extensions require a new feature that has only be added recently (for example webjars) then it could decide to only support more recent versions of XWiki but it would be on an exception basis. > > WDYT? > > Thanks > -Vincent > > On 14 Jul 2014 at 14:11:14, [email protected] ([email protected](mailto:[email protected])) wrote: > > > > > Results: 8 +1, no 0, no -1 > > > > The vote is passed. I’ve documented it here: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLevelExtensions > > > > Going to start implementing it by sending some votes to move some extensions. > > > > Note: let’s not forget to update http://dev.xwiki.org/xwiki/bin/view/Community/SourceRepository when new top level repos are added in the xwiki organization. > > > > Thanks > > -Vincent > > > > > > On 7 Jul 2014 at 18:39:19, [email protected] ([email protected](mailto:[email protected])) wrote: > > > > > > > > Hi devs, > > > > > > Following the proposal thread at http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on. > > > > > > Rationale/Need > > > =============== > > > > > > The needs: > > > * Be able to extract some apps from xwiki-contrib that the XWiki Dev Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc > > > * Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features). > > > > > > Governance > > > ========== > > > > > > Details: > > > > > > * Extensions are VOTEd in on a case by case basis. > > > > > > * Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other). > > > > > > * When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization. > > > > > > * FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise. > > > > > > * The Git repository name should be of the form xwiki-. should be part of the VOTE. > > > > > > * All rules from http://dev.xwiki.org apply > > > > > > * Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes. > > > > > > * Each extension must follow these criteria for being VOTEd: > > > ** A Release Manager needs to be defined in the proposal > > > ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) > > > ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPractices > > > ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses > > > ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved. > > > > > > * If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE > > > > > > * We would create one JIRA project per extension > > > > > > * We would create a new JIRA Category called “XWiki Extensions” > > > > > > * We would put the extensions in our CI at http://ci.xwiki.org > > > > > > * The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.. Exceptions would need to be discussed. > > > > > > * The group id for extensions having their own repo should be org.xwiki.. The needs to be part of the VOTE when proposing a new extensions. > > > > > > Here’s my +1 > > > > > > Thanks > > > -Vincent > > > > > > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org
Hi, On Thu, Nov 13, 2014 at 6:15 PM, [email protected] <[email protected]> wrote:
Trying to progress on this…
Some points:
1) As an exercice, I’ve started listing all extensions currently located in platform that we should move outside of xwiki-platform, if we follow the voted rule below:
* Active Installs App * Blog (still bundled in XE ATM) * FAQ App * Git module * IRC Bot App * JIRA module (not the macro) * Link Checker * Menu App * Release App * PHP Macro * Gallery Macro * Python Macro * RSS Macro * Useravatar macro * Repository App * Selenium App (should be moved to contrib actually) * Zip Explorer plugin
So the only (/main) criteria here is that these extensions are not bundled in XE, right? +1 from me Now, this would be just an awesome moment to do something we`ve been talking about for a while, which is to move all UI-related extensions outside of xwiki-platform so that we end up with xwiki-platform-web depending only on the extensions in xwiki-platform/commons/rendering that are vital for a barebone/minimal wiki instance to be up and running and to launch the DistributionWizard/ExtensionManager. Obviously, xwiki-enterprise-ui-* would be left in charge of depending on needed stuff and bringing the dependencies transitively when the UI is installed; one step closer towards flavors. I also understand that we can do this iteratively and not make that big of a jump right now, but anyway, my suggestion is that we should; or at least schedule it for 7.0.
I’ve also reviewed some apps on xwiki-contrib that we may want to move inside the xwiki GitHub org and here are some candidates (each app would need a manager who volunteer to manage the app as defined by our rules below of course - I’m putting some ideas of names, they’re just ideas!). Note that most of these apps are not ready to be moved and would need some cleanup/some func tests first:
* File Manager App - Marius * GitHub Stats App (used on xwiki.org) - Vincent * Forum App - ? * Mocca Calendar App - Clemens * Meeting Manager App - ? * Idea Application - ? * xwikorg flavor - Vincent * Ratings App - ? * Presentation App - Vincent * Wiki Editor Devtools (autocomplete + highlighting) - Edi/Vincent * Video Macro - ? * Diagram App - Marius * Admin Tools App (would need to be cleaned up) - ? * Task Manager App - ?
The upside of this is that it will be much clearer who is the "expert" on certain domains/applications, however we must also watch out for an increase in the "bus factor" that such a list would introduce. +1 for the intention, ATM.
WDYT about both lists? Any opinion?
2) We’ll need to decide the version number for extensions we move from platform. I propose to continue using their current version but detach them from platform once they’re moved. For example the FAQ app, if moved now, would have version 6.4-SNAPSHOT and its next release would be 6.4, then 6.4.1 or 6.5, etc.
+1 for basing their version numbers from the time they were detached from XWiki's release cycle, as suggested.
3) We’d need to decide what version of XWiki is supported by each extension. Since we officially support 3 versions (last super stable, last stable and dev version), I propose that by default extensions would support the latest super stable version without the bugfixing part. For example right now last super stable is 5.4.5 which would mean that extensions would depend on XWiki 5.4 (ie can be installed in XWiki 5.4+). Of course if some extensions require a new feature that has only be added recently (for example webjars) then it could decide to only support more recent versions of XWiki but it would be on an exception basis.
IMO, the *best* thing about this change for users would be the ability to upgrade individual extensions/modules without having o migrate their entire wiki to a newer version. See the discussion [1] I raised recently about this. As a result, and as Thomas also suggested in a previous reply here (if I am not mistaken), each detached extension should depend on the minimum XWiki version as it is technically possible, in order to maximize compatibility and installability over the widest range of XWiki versions as possible. Introducing artificial bounds like LTS or something else is, I believe, damaging to users and brings no value to either devs or users. Of course, when newer versions of the extensions require features available in later XWiki versions, the minimum required version should be raised accordingly, but always be preserved to a minimum. [1] http://markmail.org/message/zohkn73srh7dwom4 Thanks, Eduard
WDYT?
Thanks -Vincent
On 14 Jul 2014 at 14:11:14, [email protected] ([email protected](mailto: [email protected])) wrote:
Results: 8 +1, no 0, no -1
The vote is passed. I’ve documented it here:
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLevel...
Going to start implementing it by sending some votes to move some
extensions.
Note: let’s not forget to update
http://dev.xwiki.org/xwiki/bin/view/Community/SourceRepository when new top level repos are added in the xwiki organization.
Thanks -Vincent
On 7 Jul 2014 at 18:39:19, [email protected] ([email protected]
(mailto:[email protected])) wrote:
Hi devs,
Following the proposal thread at
http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev
Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc
* Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-. should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.. The needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Nov 14, 2014 at 12:36 PM, Eduard Moraru <[email protected]> wrote:
Hi,
On Thu, Nov 13, 2014 at 6:15 PM, [email protected] <[email protected]> wrote:
Trying to progress on this…
Some points:
1) As an exercice, I’ve started listing all extensions currently located in platform that we should move outside of xwiki-platform, if we follow the voted rule below:
* Active Installs App * Blog (still bundled in XE ATM) * FAQ App * Git module * IRC Bot App * JIRA module (not the macro) * Link Checker * Menu App * Release App * PHP Macro * Gallery Macro * Python Macro * RSS Macro * Useravatar macro * Repository App * Selenium App (should be moved to contrib actually) * Zip Explorer plugin
So the only (/main) criteria here is that these extensions are not bundled in XE, right? +1 from me
Now, this would be just an awesome moment to do something we`ve been talking about for a while, which is to move all UI-related extensions
outside of xwiki-platform so that we end up with xwiki-platform-web
You mean xwiki-enterprise-web? There are no dependencies in xwiki-platform-web.
depending only on the extensions in xwiki-platform/commons/rendering that are vital for a barebone/minimal wiki instance to be up and running and to launch the DistributionWizard/ExtensionManager. Obviously, xwiki-enterprise-ui-* would be left in charge of depending on needed stuff and bringing the dependencies transitively when the UI is installed; one step closer towards flavors.
I also understand that we can do this iteratively and not make that big of a jump right now, but anyway, my suggestion is that we should; or at least schedule it for 7.0.
I’ve also reviewed some apps on xwiki-contrib that we may want to move inside the xwiki GitHub org and here are some candidates (each app would need a manager who volunteer to manage the app as defined by our rules below of course - I’m putting some ideas of names, they’re just ideas!). Note that most of these apps are not ready to be moved and would need some cleanup/some func tests first:
* File Manager App - Marius * GitHub Stats App (used on xwiki.org) - Vincent * Forum App - ? * Mocca Calendar App - Clemens * Meeting Manager App - ? * Idea Application - ? * xwikorg flavor - Vincent * Ratings App - ? * Presentation App - Vincent * Wiki Editor Devtools (autocomplete + highlighting) - Edi/Vincent * Video Macro - ? * Diagram App - Marius * Admin Tools App (would need to be cleaned up) - ? * Task Manager App - ?
The upside of this is that it will be much clearer who is the "expert" on certain domains/applications, however we must also watch out for an increase in the "bus factor" that such a list would introduce.
+1 for the intention, ATM.
WDYT about both lists? Any opinion?
2) We’ll need to decide the version number for extensions we move from platform. I propose to continue using their current version but detach them from platform once they’re moved. For example the FAQ app, if moved now, would have version 6.4-SNAPSHOT and its next release would be 6.4, then 6.4.1 or 6.5, etc.
+1 for basing their version numbers from the time they were detached from XWiki's release cycle, as suggested.
3) We’d need to decide what version of XWiki is supported by each extension. Since we officially support 3 versions (last super stable, last stable and dev version), I propose that by default extensions would support the latest super stable version without the bugfixing part. For example right now last super stable is 5.4.5 which would mean that extensions would depend on XWiki 5.4 (ie can be installed in XWiki 5.4+). Of course if some extensions require a new feature that has only be added recently (for example webjars) then it could decide to only support more recent versions of XWiki but it would be on an exception basis.
IMO, the *best* thing about this change for users would be the ability to upgrade individual extensions/modules without having o migrate their entire wiki to a newer version. See the discussion [1] I raised recently about this.
As a result, and as Thomas also suggested in a previous reply here (if I am not mistaken), each detached extension should depend on the minimum XWiki version as it is technically possible, in order to maximize compatibility and installability over the widest range of XWiki versions as possible. Introducing artificial bounds like LTS or something else is, I believe, damaging to users and brings no value to either devs or users. Of course, when newer versions of the extensions require features available in later XWiki versions, the minimum required version should be raised accordingly, but always be preserved to a minimum.
[1] http://markmail.org/message/zohkn73srh7dwom4
Thanks, Eduard
WDYT?
Thanks -Vincent
On 14 Jul 2014 at 14:11:14, [email protected] ([email protected](mailto: [email protected])) wrote:
Results: 8 +1, no 0, no -1
The vote is passed. I’ve documented it here:
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLevel...
Going to start implementing it by sending some votes to move some
extensions.
Note: let’s not forget to update
http://dev.xwiki.org/xwiki/bin/view/Community/SourceRepository when new top level repos are added in the xwiki organization.
Thanks -Vincent
On 7 Jul 2014 at 18:39:19, [email protected] ([email protected]
(mailto:[email protected])) wrote:
Hi devs,
Following the proposal thread at
http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev
Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc
* Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-. should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.. The needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Nov 17, 2014 at 11:09 AM, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Nov 14, 2014 at 12:36 PM, Eduard Moraru <[email protected]> wrote:
Hi,
On Thu, Nov 13, 2014 at 6:15 PM, [email protected] <[email protected]> wrote:
Trying to progress on this…
Some points:
1) As an exercice, I’ve started listing all extensions currently located in platform that we should move outside of xwiki-platform, if we follow the voted rule below:
* Active Installs App * Blog (still bundled in XE ATM) * FAQ App * Git module * IRC Bot App * JIRA module (not the macro) * Link Checker * Menu App * Release App * PHP Macro * Gallery Macro * Python Macro * RSS Macro * Useravatar macro * Repository App * Selenium App (should be moved to contrib actually) * Zip Explorer plugin
So the only (/main) criteria here is that these extensions are not bundled in XE, right? +1 from me
Now, this would be just an awesome moment to do something we`ve been talking about for a while, which is to move all UI-related extensions
outside of xwiki-platform so that we end up with xwiki-platform-web
You mean xwiki-enterprise-web? There are no dependencies in xwiki-platform-web.
Right. Thanks, Eduard
depending only on the extensions in xwiki-platform/commons/rendering that are vital for a barebone/minimal wiki instance to be up and running and to launch the DistributionWizard/ExtensionManager. Obviously, xwiki-enterprise-ui-* would be left in charge of depending on needed stuff and bringing the dependencies transitively when the UI is installed; one step closer towards flavors.
I also understand that we can do this iteratively and not make that big of a jump right now, but anyway, my suggestion is that we should; or at least schedule it for 7.0.
I’ve also reviewed some apps on xwiki-contrib that we may want to move inside the xwiki GitHub org and here are some candidates (each app would need a manager who volunteer to manage the app as defined by our rules below of course - I’m putting some ideas of names, they’re just ideas!). Note that most of these apps are not ready to be moved and would need
some
cleanup/some func tests first:
* File Manager App - Marius * GitHub Stats App (used on xwiki.org) - Vincent * Forum App - ? * Mocca Calendar App - Clemens * Meeting Manager App - ? * Idea Application - ? * xwikorg flavor - Vincent * Ratings App - ? * Presentation App - Vincent * Wiki Editor Devtools (autocomplete + highlighting) - Edi/Vincent * Video Macro - ? * Diagram App - Marius * Admin Tools App (would need to be cleaned up) - ? * Task Manager App - ?
The upside of this is that it will be much clearer who is the "expert" on certain domains/applications, however we must also watch out for an increase in the "bus factor" that such a list would introduce.
+1 for the intention, ATM.
WDYT about both lists? Any opinion?
2) We’ll need to decide the version number for extensions we move from platform. I propose to continue using their current version but detach them from platform once they’re moved. For example the FAQ app, if moved now, would have version 6.4-SNAPSHOT and its next release would be 6.4, then 6.4.1 or 6.5, etc.
+1 for basing their version numbers from the time they were detached from XWiki's release cycle, as suggested.
3) We’d need to decide what version of XWiki is supported by each extension. Since we officially support 3 versions (last super stable,
last
stable and dev version), I propose that by default extensions would support the latest super stable version without the bugfixing part. For example right now last super stable is 5.4.5 which would mean that extensions would depend on XWiki 5.4 (ie can be installed in XWiki 5.4+). Of course if some extensions require a new feature that has only be added recently (for example webjars) then it could decide to only support more recent versions of XWiki but it would be on an exception basis.
IMO, the *best* thing about this change for users would be the ability to upgrade individual extensions/modules without having o migrate their entire wiki to a newer version. See the discussion [1] I raised recently about this.
As a result, and as Thomas also suggested in a previous reply here (if I am not mistaken), each detached extension should depend on the minimum XWiki version as it is technically possible, in order to maximize compatibility and installability over the widest range of XWiki versions as possible. Introducing artificial bounds like LTS or something else is, I believe, damaging to users and brings no value to either devs or users. Of course, when newer versions of the extensions require features available in later XWiki versions, the minimum required version should be raised accordingly, but always be preserved to a minimum.
[1] http://markmail.org/message/zohkn73srh7dwom4
Thanks, Eduard
WDYT?
Thanks -Vincent
On 14 Jul 2014 at 14:11:14, [email protected] ([email protected] (mailto: [email protected])) wrote:
Results: 8 +1, no 0, no -1
The vote is passed. I’ve documented it here:
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLevel...
Going to start implementing it by sending some votes to move some
extensions.
Note: let’s not forget to update
http://dev.xwiki.org/xwiki/bin/view/Community/SourceRepository when new top level repos are added in the xwiki organization.
Thanks -Vincent
On 7 Jul 2014 at 18:39:19, [email protected] ([email protected]
(mailto:[email protected])) wrote:
Hi devs,
Following the proposal thread at
http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on.
Rationale/Need ===============
The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev
Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc
* Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features).
Governance ==========
Details:
* Extensions are VOTEd in on a case by case basis.
* Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other).
* When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization.
* FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise.
* The Git repository name should be of the form xwiki-. should be part of the VOTE.
* All rules from http://dev.xwiki.org apply
* Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes.
* Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see
http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...
** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved.
* If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE
* We would create one JIRA project per extension
* We would create a new JIRA Category called “XWiki Extensions”
* We would put the extensions in our CI at http://ci.xwiki.org
* The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.. Exceptions would need to be discussed.
* The group id for extensions having their own repo should be org.xwiki.. The needs to be part of the VOTE when proposing a new extensions.
Here’s my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (9)
-
Denis Gervalle -
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume "Louis-Marie" Delhumeau -
Jean SIMARD -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
vincent＠massol.net