Results: 8 +1, no 0, no -1
The vote is passed. I’ve documented it
here:
Going to start implementing it by sending some votes to move some extensions.
Note: let’s not forget to
update
when new top level
repos are added in the xwiki organization.
Thanks
-Vincent
On 7 Jul 2014 at 18:39:19, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) 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/ApplicationDevelopmentBestPra…
** 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