In theory the proposal sounds good, although it increases the process rules and number of organizations, etc. We still have things to figure out, but it looks ok +1
Thanks, Caty On Thu, Dec 4, 2014 at 11:37 AM, [email protected] <[email protected]> wrote: > > > > > > On 4 Dec 2014 at 10:28:43, Guillaume Louis-Marie Delhumeau ( > [email protected](mailto:[email protected])) wrote: > > > Hi > > > > 2014-12-03 15:57 GMT+01:00 [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”. > > There’s just 2 problems with “incubator”: > > 1) we’re going to not have any place to put our extensions/modules that > are no longer supported… And I’d rather not create another org just for > that… > 2) incubator means that it’s a transient location and that the goal is > always to go in xwiki-contrib-extensions while “sandbox” is more neutral. > > Thanks > -Vincent > > > > ** “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 > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
