On Thu, Dec 4, 2014 at 10: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. > I agree with Guillaume, the Sandbox is not motivating, and create for those who do not catch with the rules a nice place to stay. I agree that it will push for moving to a better repository, but if it slow down the initial contribution, there will be nothing to move. Why not keeping the first naming, even if the rules will differ: xwiki-extensions and xwiki-contrib (or xwiki-contrib-extensions if you prefer) ? > > 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 > Well, there are several kind of extension, and their level of risk are very different. For example, a mostly Javascript base extension, with a bit of XWiki Macro, could really be stable since its version 1.0, not having much compatibility issue over time, and therefore, works on the latest versions, being a nice helper, all this without any maintenance work. Let take the ShowHide Macro or the LiveValidation Macros, both are now generally following the best practice, works on latest versions, but I doubt I will have to make any new release of them in the near future. I do not think we can really measure the maintenance quality of an extension with the frequency of its release. I also think that simple extension could be really well done while being only release as simple XAR, putting the contribution to the level of the advance user, not necessarily programmers. So, I am afraid that the separation between first class extension and other ones is more subtil than you would like it to be. What you describe is well adapted to large extension, like meeting applications, filemanager, etc... > > > * 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. > It sounds to me a bit like Apple policies for its app store... Do we really want to keep that level of control ? Is it really fair ?. If you look at other software that provide extensions, most of them as not follow that way, but they have left the users vote and put their most useful and preferred extensions at the top of the results. I am not sure we are making the good choice by creating that committee. I understand that you want a way to keep the quality of good extensions. Wouldn't this be naturally done if the extension has a maintainer (that self design himself) and a way for user to express their happiness about extensions ? I am just afraid by more policies (which is opposite to the issues you try to solve), and I am pleading for more natural selection. Also, aren't we mixing two different aspects of the problem: 1) repositories, and developper tools for extensions 2) publishing extension in the XWiki "central" repository For 1), we can provide helps, keeping our actual very open policies For 2), we can have some more strict rules, since it does not prevent anyone to provide their extension from any external repository. Maybe we could make something in the line of Ubuntu packages, and their Personal Package Repositories. I mean: - provide tools for developers (and simple users) to create good extensions without annoying them with policies - provide way to publish those extension into our maven repository, and require for this purpose that the project follow some rules. We may even provide two different maven repos, one for first grade and one for others. I do not think separating first grade and other extensions are useful for the sources repositories. The sources could be anywhere, in our github contrib, or anywhere else. Of course, only well managed project, which imply well managed sources has a chance to be accepted in the first grade extension maven repository. This repository will be only recommandation, but we will never imply that an extension should be in that repository to be good. This would allow IMO a better and more acceptable control. Moreover, again like what debian/ubuntu, the users of XWiki will be able to decide from which repositories they accept to pull extension from. IMO, in that context, the rules and voting for releasing an extension into the first grade repository could be managed as a committers vote. Providing ratings on extension will help committers make good proposals and decisions. Moreover, anyone as the right to make a non binding vote, and therefore help in the decision process. So, with this approach, we do not have to add more complexity to the management of the project. WDYT ? > > * 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 > -- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
