Ok, so more than 72 hours have now elapsed and the VOTE is passed! Results: 7 +1, no 0 and no -1
I’ll update dev.xwiki.org to reflect the fact that the xwiki github organization is now focused on core extensions only and that vertical extensions are to be located in xwiki-contrib. Note that the delimitation is a bit fuzzy and the move requires a VOTE every time so I’ll send another VOTE mail to propose some extensions to move out of platform. Thanks -Vincent On 19 Jan 2016 at 17:17:42, [email protected] ([email protected](mailto:[email protected])) wrote: > > > 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
