On 19 Jan 2016 at 12:01:01, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote:
> +1 > > My only comment is that we will start again to have discrepancies between > applications versions. That's going to be fun :) Yes this is my worry too: the compatibilty matrix. The more contrib extensions we have, the more complex testing and compatibility is. We need to work on improving user contributions in this domain, directly from inside XE for example. Thanks -Vincent > Thanks, > Caty > > On Tue, Jan 19, 2016 at 11:24 AM, Guillaume "Louis-Marie" Delhumeau < > [email protected]> wrote: > > > +1 > > > > Thanks, > > > > 2016-01-19 7:06 GMT+01:00 Marius Dumitru Florea < > > [email protected]>: > > > > > +1 > > > > > > Thanks, > > > Marius > > > > > > On Mon, Jan 18, 2016 at 6:05 PM, [email protected] > > > wrote: > > > > > > > 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). > > > > > > > > On 2 Aug 2015 at 19:43:18, [email protected] ([email protected] > > > (mailto: > > > > [email protected])) 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 > > > 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 > > > > > > > > > > On 3 Dec 2014 at 15:58:36, [email protected] ([email protected] > > > > (mailto:[email protected])) 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 > > > 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 > > > > > > > > _______________________________________________ > > > > devs mailing list > > > > [email protected] > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > -- > > 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
