18 Jan
2016
18 Jan
'16
10:27 p.m.
+1
Thanks,
Eduard
On Mon, Jan 18, 2016 at 9:37 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
+1, sounds good to me too :)
On Mon, Jan 18, 2016 at 5:05 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
commented
xwiki
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).
Do not forget that you can enforce a lot of practice by defining
constraints in the extension pom for extension in Java, like checkstyles,
etc… which also enforce the quality of coding. Of course this does not
cover everything, but the owner of the repository will surely also check
and review committed code to keep the quality of the extension to a good
level. I am not really afraid by this point, I have already some contrib
extension that follow platform rules, and I have never seen any degradation
yet.
* 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).
On 2 Aug 2015 at 19:43:18, vincent(a)massol.net (vincent(a)massol.net
(mailto:
vincent(a)massol.net)) wrote:
:)
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 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?
this
* 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 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.
check
* 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 it out for making repo changes)
tune
** xwiki-extensions (new). For maintained and
good quality level
extensions, following the charter defined in the first proposal
(we’ll 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)
to
** 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 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?
starting
Once (and if) we agree on this, I’d like to quickly move some existing
extensions
from the xwiki-core organization into xwiki-extensions, with the FAQ Application, in order to start
testing this new
organization.
WDYT?
Thanks
-Vincent
On 3 Dec 2014 at 15:58:36, vincent(a)massol.net (vincent(a)massol.net
(mailto:vincent@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 github organization) is increasing but the team
stays relatively small
installs,
> * 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 one base flavor (the “XWiki” flavor), etc
we
> ** 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 rename it to “xwiki-contrib-sandbox”):
located.
> ** “xwiki-contrib-sandbox” (or
“xwiki-incubator”), where newly
proposed extensions or abandoned extensions are
located
> > ** “xwiki-contrib-extensions”, where maintained extensions are > > * 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.
published
> * 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 on
extensions.xwiki.org(http://extensions.xwiki.org) with documentation
work
> ** 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 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.
stand
> * 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 up.
> > * Contrib extensions keep using the org.xwiki.contrib package name
and
groupid as currently defined at
http://contrib.xwiki.org
(each
>
> Note: The idea is that xwiki core is developed as a team maintaining
all code
in there, xwiki contrib is developed extension by extension extension is an island). This allows anyone to
propose extensions in
XWiki
Contrib without the need for everyone to support
them.
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
>
> WDYT?
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs