+1
On Mon, Jul 7, 2014 at 7:24 PM, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote:
+1.
On 07/07/2014 12:39 PM, vincent(a)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-<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/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.<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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org