Hi,
On Wed, Dec 3, 2014 at 5:16 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
Sounds good. +1
On Wed, Dec 3, 2014 at 3:57 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi committers (and devs in general),
I’m submitting to you this idea, to try to improve the xwiki open source
project
and to give it a new dynamism. I believe the topics discussed below
are made even more important since we’re soon going to develop the notion
of flavors in XWiki.
Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km
proposal (i.e. the move of
some extensions in the xwiki github organization), which itself was
obsoleting
http://markmail.org/message/ppw2slpgqou2ihai
Issues to solve
===============
* The scope of the code maintained by the XWiki Dev Team (== the xwiki
github
organization) is increasing but the team stays relatively small
* The more stuff we move into the repos of the
xwiki github
organization, the less easy it is for non-“XWiki Dev Team” committers
to
participate and we want more contributions
Proposed solution
=================
Executive summary:
* Reduce the scope of all the code located in the xwiki github
organization by
only keeping “core” modules
* A “core" module is defined by being a
generic transversal module (i.e.
that can be used in lots of XWiki flavors, if not
all). This is opposed to
“vertical” modules which are modules specific of a usage of XWiki.
** Examples of “core" modules: logging
module, configuration module,
distribution wizard, statistics application,
annotations, active installs,
one base flavor (the “XWiki” flavor), etc
** Example of “vertical” modules: meeting manager
application, blog
application, FAQ application, flavors (except the base flavor),
etc
Some consequences:
* We need a new location for several modules that would go out of the
xwiki github
organization repos
* It would be good to separate sandbox extensions
from 1st class
extensions that are maintained and developed following best
practices. We
need some way to maintain the quality of important extensions
Detailed Implementation:
* The “xwiki” github organization’s description becomes “XWiki Core”
(it’s too
complex to rename the org to “xwiki-core” IMO)
* “XWiki Dev Team” becomes the “XWiki Core Team”
(and committers in
there are called “XWiki Core Committers”).
* “xwiki-contrib” is split into 2 github
organizations (technically we
rename it to “xwiki-contrib-sandbox”):
** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly proposed
extensions or abandoned extensions are
located
** “xwiki-contrib-extensions”, where maintained
extensions are located.
* These 2 organizations are commonly referred to as “XWiki Contrib"
* Same as now, anyone requesting a repo in xwiki-contrib-sandbox would
be granted
one and he/she’d be given write access to all repos in the
xwiki-contrib-sandbox organization.
* We define some rules for graduating from
xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example:
** The extension should have been in
xwiki-contrib-sandbox at least 6
months (this gives time to see if the extension is
maintained during that
time and will survive the test of time - most extensions will die in the
first months)
** The extension should have had more than 2
releases and be published
on extensions.xwiki.org(http://extensions.xwiki.org) with
documentation
** The extension should work with the latest LTS
version of XWiki + the
latest stable version of XWiki (right now that would be
5.4.5 + 6.3). Note
that if the extension has to use new API it’s ok that it doesn’t work on
the latest LTS.
has a leader/maintainer. He/she’s the one proposing to
move the extension
from xwiki-sandbox
to xwiki-extensions. He/she’s responsible for ensuring
that the extension
gets regular releases and is maintained in general. He/she defines
initially the list of committers in his email proposal for moving the
extension.
* We create a PMC (Project Management Committee)
for XWiki Contrib,
generally in charge of both xwiki-contrib-sandbox and
xwiki-contrib-extensions (voting new extensions in
xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I
would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to stand
up.
I propose that all XWiki core committers are, by default, members of this
PMC. They can choose not to get involved in every decision, but they should
have a voice if they need it, without needing to pass through a vote
process from the current members of the PMC.
"A generic *maven groupId*: org.xwiki.contrib (or org.xwiki.contrib.<module
name> if the project has several modules). That's until the project reaches
a certain size and visibility, in which case it can have its own maven
group id."
Projects part of xwiki-contrib-extensions seem to qualify the for the
"until the project reaches a certain size and visibility" part.
Do we really want to enforce the org.xwiki.contrib group? Personally, I
never did understand *why* we are enforcing it, above the simple fact that
we just can.
I don't have something in particular against new projects in
xwiki-contrib-sandbox, but for projects we are migrating from the xwiki
organization, if they are java projects, we are forcing anybody that was
using them in the past to rewrite their code (so no longer a simple
dependency change in their pom.xml), since package name would change (due
to our maven group id policy) and any code using those packages needs an
update.
Thanks,
Eduard
Note: The idea is that xwiki core is developed as a team maintaining all
code in
there, xwiki contrib is developed extension by extension (each
extension is an island). This allows anyone to propose extensions in XWiki
Contrib without the need for everyone to support them.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs