Hi 2014-12-03 15:57 GMT+01:00 [email protected] <[email protected]>:
> 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 > I prefer xwiki-contrib-incubator because the "sandbox" name gives me the impression of projects that are not serious. I would not like to create a project in a "sandbox", but I would be OK to put it in an "incubator". > ** “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 > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > +1 for the proposal. -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
