atom feed25 messages in org.xwiki.devs[xwiki-devs] [VOTE] XWiki Core - Take 3
FromSent OnAttachments
vinc...@massol.netDec 3, 2014 6:57 am 
Thomas MortagneDec 3, 2014 7:16 am 
Eduard MoraruDec 3, 2014 1:35 pm 
vinc...@massol.netDec 4, 2014 12:44 am 
Guillaume "Louis-Marie" DelhumeauDec 4, 2014 1:28 am 
vinc...@massol.netDec 4, 2014 1:37 am 
Ecaterina Moraru (Valica)Dec 4, 2014 4:35 am 
Marius Dumitru FloreaDec 5, 2014 7:19 am 
Denis GervalleDec 6, 2014 12:56 pm 
Thomas MortagneDec 7, 2014 1:52 am 
vinc...@massol.netAug 2, 2015 10:43 am 
Gabriela SmeriaAug 7, 2015 2:46 am 
Eduard MoraruAug 7, 2015 7:52 am 
Thomas MortagneAug 7, 2015 8:06 am 
Denis GervalleAug 8, 2015 2:58 pm 
Marius Dumitru FloreaAug 19, 2015 2:07 am 
vinc...@massol.netJan 18, 2016 8:05 am 
Thomas MortagneJan 18, 2016 8:22 am 
Denis GervalleJan 18, 2016 11:37 am 
Eduard MoraruJan 18, 2016 1:27 pm 
Marius Dumitru FloreaJan 18, 2016 10:06 pm 
Guillaume "Louis-Marie" DelhumeauJan 19, 2016 1:24 am 
Ecaterina Moraru (Valica)Jan 19, 2016 3:00 am 
vinc...@massol.netJan 19, 2016 8:17 am 
vinc...@massol.netJan 21, 2016 3:28 am 
Subject:[xwiki-devs] [VOTE] XWiki Core - Take 3
From:vinc...@massol.net (vinc@massol.net)
Date:Jan 18, 2016 8:05:03 am
List:org.xwiki.devs

Hi devs,

Since the first 2 takes did not pas, I’m making a new proposal taking into
account the latest comments and making the minimal changes from the current
situation to get a consensus.

Issues to solve ===============

* The scope of the code maintained by the XWiki Dev Team (== the xwiki github
organization) is increasing but the team stays relatively small * The more stuff we move into the repos of the xwiki github organization, the
less easy it is for non-“XWiki Dev Team” committers to participate and we want
more contributions

Proposed solution =================

Executive summary: * Reduce the scope of all the code located in the xwiki github organization by
only keeping “core” modules * A “core" module is defined by being a generic transversal module (i.e. that
can be used in lots of XWiki flavors, if not all). This is opposed to “vertical”
modules which are modules specific of a usage of XWiki. ** Examples of “core" modules: logging module, configuration module,
distribution wizard, annotations, active installs, one base flavor (the “XWiki”
flavor), etc ** Example of “vertical” modules: meeting manager application, blog application,
FAQ application, flavors (except the base flavor), etc

Some consequences: * We need a new location for several modules that would go out of the xwiki
github organization repos * It would be good that extensions that were developed inside the xwiki github
organization continue to follow the dev practices of http://dev.xwiki.org

Details: * We keep the current github organization names for now, i.e. “xwiki” and
“xwiki-contrib”. * Each extension in xwiki-contrib continues to be an island with a leader
(defined in jira) and continues to be able to decide what dev practices it
should follow. The leader continues to be the one to contact when needing to
perform a release. When the leader goes MIA the next person interested in
working on the extension can become its new leader. * Since extensions moved from the xwiki github organization should continue to
follow all the practices from http://dev.xwiki.org we need a way to indicate
this so that code committed against those and PR can be reviewed in light of
these practices. Thus we should encourage extensions to have a README file in
each repo in xwiki-contrib that defines what practices the extension is
following. We’ll also update contrib.xwiki.org with explanations about this
(both for extension creators and for contributors to them). * Note that on contrib.xwiki.org we will propose a generic template for README
files that should exist for all repos in xwiki-contrib. This template will
include (but not be limited to): Dev practices to follow, Link to e.x.o, Status
of the extension (useful to indicate non-working/abandoned extensions for
example), link to its jira. * When moving an extension from the xwiki github org to xwiki-contrib, depending
on the moved extension, the extension can keep its id (this allows the EM
upgrade job to propose upgrading it). Whenever possible the extension id should
be updated to follow the rules of contrib.xwiki.org (group id of
org.xwiki.contrib, artifact id matching the rules). In addition, since we don’t
want to cause API breakages, the java packages can be kept as org.xwiki.* till
the next large refactoring of the extension, at which time it should move to
org.xwiki.contrib.*. Similarly the version of the moved extension should be kept
and not be reset to 1.0-SNAPSHOT. We can probably develop some EM tooling in the
future to handle relocation of extension id transparently.

Please cast your vote.

Here’s my +1

Thanks -Vincent

PS: The previous 2 takes were proposal but I’m making it a VOTE now because I
believe the “XWiki Core” strategy is important enough so that we need to be sure
that committers agree (based on our voting rules).

Hi,

I’d like to progress with this idea so let me summarize this thread’s discussion
so far:

* +1 from Thomas, Guillaume, Caty and Marius * No answer from Edy on whether he’s ok with the proposal or not. Edy? :) * Denis seems negative about it but I agree with Thomas’s reply in that the
points raised by Denis do not concern this discussion. Denis commented about
publishing and installing Extensions, whereas this proposal was only about a
location for storing some extensions. Extensions can be developed anywhere and
don’t have to go into this new proposed location. Denis, could you please review
this new proposal with this in mind? * There were discussions about the name and devs express doubts about using
xwiki-contrib-sandbox.

I’d like to progress so here’s my second proposal. It differs from the first
proposal on the following points:

* All our code is contributed so I don’t think we need to emphasize this point
and I don’t think we need to have “contrib” in the name of the github repos.
This will lead to shorter names which is better. * I propose to have 3 github org: ** xwiki-core (currently “xwiki” but we should probably rename it - Github will
create redirects and the only downside is that we need to check it out for
making repo changes) ** xwiki-extensions (new). For maintained and good quality level extensions,
following the charter defined in the first proposal (we’ll tune it). Committers
are added extension by extension and will be voted on the devs list for now, by
the xwiki core devs (we’ll tune that later on) ** xwiki-incubator (currently “xwiki-contrib” but we should rename it).
Extensions in xwiki-extensions that are no longer working with the latest LTS
and that nobody is fixing will move back to xwiki-incubator too. * I propose to change the goal of the contrib.xwiki.org wiki and to expand its
goal. Right now it’s focused about the xwiki-contrib organization on GitHub. I
propose to make it the wiki that explains how to make contributions to the XWiki
ecosystem in general. We would move
http://dev.xwiki.org/xwiki/bin/view/Community/Contributing + add pages for
explaining how to contribute to xwiki-core, xwiki-extensions and
xwiki-incubator. * ATM we should continue to use the “org.xwiki.contrib" groupid for code in the
xwiki-incubator and xwiki-extensions organizations. Ideally we should use
org.xwiki.extension but it’s already used by the Extension module in xwiki-core.
An option would have been to use org.xwiki.core for the core but that would
break too much code so the only option is to keep having a special prefix for
non-core code. Other ideas: “org.xwiki.module”, “org.xwiki.ext”,
“org.xwiki.external”, “org.xwiki.addon”. The simplest is to keep
“org.xwiki.contrib” I think, WDYT?

Once (and if) we agree on this, I’d like to quickly move some existing
extensions from the xwiki-core organization into xwiki-extensions, starting with
the FAQ Application, in order to start testing this new organization.

WDYT?

Thanks -Vincent

Hi committers (and devs in general),

I’m submitting to you this idea, to try to improve the xwiki open source project
and to give it a new dynamism. I believe the topics discussed below are made
even more important since we’re soon going to develop the notion of flavors in
XWiki.

Note that this proposal obsoletes the
http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move of some
extensions in the xwiki github organization), which itself was obsoleting
http://markmail.org/message/ppw2slpgqou2ihai

Issues to solve ===============

* The scope of the code maintained by the XWiki Dev Team (== the xwiki github
organization) is increasing but the team stays relatively small * The more stuff we move into the repos of the xwiki github organization, the
less easy it is for non-“XWiki Dev Team” committers to participate and we want
more contributions

Proposed solution =================

Executive summary: * Reduce the scope of all the code located in the xwiki github organization by
only keeping “core” modules * A “core" module is defined by being a generic transversal module (i.e. that
can be used in lots of XWiki flavors, if not all). This is opposed to “vertical”
modules which are modules specific of a usage of XWiki. ** Examples of “core" modules: logging module, configuration module,
distribution wizard, statistics application, annotations, active installs, one
base flavor (the “XWiki” flavor), etc ** Example of “vertical” modules: meeting manager application, blog application,
FAQ application, flavors (except the base flavor), etc

Some consequences: * We need a new location for several modules that would go out of the xwiki
github organization repos * It would be good to separate sandbox extensions from 1st class extensions that
are maintained and developed following best practices. We need some way to
maintain the quality of important extensions

Detailed Implementation: * The “xwiki” github organization’s description becomes “XWiki Core” (it’s too
complex to rename the org to “xwiki-core” IMO) * “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in there are
called “XWiki Core Committers”). * “xwiki-contrib” is split into 2 github organizations (technically we rename it
to “xwiki-contrib-sandbox”): ** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed
extensions or abandoned extensions are located ** “xwiki-contrib-extensions”, where maintained extensions are located. * These 2 organizations are commonly referred to as “XWiki Contrib" * Same as now, anyone requesting a repo in xwiki-contrib-sandbox would be
granted one and he/she’d be given write access to all repos in the
xwiki-contrib-sandbox organization. * We define some rules for graduating from xwiki-contrib-sandbox to
xwiki-contrib-extensions. For example: ** The extension should have been in xwiki-contrib-sandbox at least 6 months
(this gives time to see if the extension is maintained during that time and will
survive the test of time - most extensions will die in the first months) ** The extension should have had more than 2 releases and be published on
extensions.xwiki.org(http://extensions.xwiki.org) with documentation ** The extension should work with the latest LTS version of XWiki + the latest
stable version of XWiki (right now that would be 5.4.5 + 6.3). Note that if the
extension has to use new API it’s ok that it doesn’t work on the latest LTS. ** Generally follow the practices defined at http://dev.xwiki.org * Each extension in xwiki-extensions has a leader/maintainer. He/she’s the one
proposing to move the extension from xwiki-sandbox to xwiki-extensions. He/she’s
responsible for ensuring that the extension gets regular releases and is
maintained in general. He/she defines initially the list of committers in his
email proposal for moving the extension. * We create a PMC (Project Management Committee) for XWiki Contrib, generally in
charge of both xwiki-contrib-sandbox and xwiki-contrib-extensions (voting new
extensions in xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap
it, I would send a mail on devs@ asking who’s interested to be part of this
committee. I expect some core committers + some contrib committers to stand up. * Contrib extensions keep using the org.xwiki.contrib package name and groupid
as currently defined at http://contrib.xwiki.org

Note: The idea is that xwiki core is developed as a team maintaining all code in
there, xwiki contrib is developed extension by extension (each extension is an
island). This allows anyone to propose extensions in XWiki Contrib without the
need for everyone to support them.

WDYT?

Thanks -Vincent