Looks good, +1. On Mon, Jan 18, 2016 at 5:05 PM, [email protected] <[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. For now it's safer to allow keeping the same id but here are some reading about extensions upgrades and ids modifications: * Maven provide some relocation system (basically you release a new version of the old id which will be used as redirect to the new one) but need to test how well EM supports it * Right now we deal with previous id by listing them as features but feature can also be used for other things like indicating embedded extensions or actual features/API implemented by several implementations that can't be installed at the same time. We would probably need to make it more explicit what was a previous id of the extension in a different property so that we can safely search for it in extensions.xwiki.org * By default upgrade manager only search for extensions explicitly installed by user (so not installed as dependency) so extensions installed as XE dependencies for example are not checked anyway > > 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 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
