Hi Edy, On 3 Dec 2014 at 22:36:34, Eduard Moraru ([email protected](mailto:[email protected])) wrote:
> Hi, > > On Wed, Dec 3, 2014 at 5:16 PM, Thomas Mortagne > wrote: > > > Sounds good. +1 > > > > On Wed, Dec 3, 2014 at 3:57 PM, [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. > > > > So no plan at this point to address > http://xwiki.markmail.org/thread/zohkn73srh7dwom4 and This proposal and the one referenced are orthogonal. That said, my proposal does solve a lot of the problem you mention since: - we move several extensions out of xwiki-platform into xwiki-contrib-extensions and thus they’ll have their lifecycle and can specify the dep versions they wish - I have explicitly mentioned in my proposal that a good condition for joining xwiki-contrib-extensions would be that: "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 I said “should” and not “must” since this is hard to do *initially* if we move out extensions from xwiki-platform but as time goes by, XWiki versions will increase but the moved extension doesn’t have to increase its dep versions at the same rate. - what will remain in xwiki-platform is just core extensions, i.e. extensions that are bundled and that you don’t install! > http://xwiki.markmail.org/thread/cuqpsqsxtvslmlkp , right? This proposal has not much to do with "XWiki Core" since it’s about extensions currently in xwiki-contrib. Also AFAIK we’ve already agreed that we want these apps to work with the latest XWiki LTS (except when they have to use newer APIs/features that only exist in more recent versions). And this is very compatible with my proposal: "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).” So I don’t see any problem at all. Either I don’t understand your point or you’re trying to make this proposal something much bigger than what it is. > > > ** Generally follow the practices defined at http://dev.xwiki.org > > > * Each extension in xwiki-extensions > > > > xwiki-contrib-extensions > > > > has a leader/maintainer. He/she’s the one proposing to move the extension > > from xwiki-sandbox > > > > xwiki-contrib-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. > > > > I propose that all XWiki core committers are, by default, members of this > PMC. They can choose not to get involved in every decision, but they should > have a voice if they need it, without needing to pass through a vote > process from the current members of the PMC. I didn’t proposa this for a very simple reason: One very big point of this proposal (if not the main one) is to make equal citizenship in the XWiki community between XWiki Core Devs and Contributors of xwiki-contrib. It’s about shifting the balance: have XWiki Core devs focus on core and have contributors focus on providing extensions to the core. Thus they need to have separate decision power. In addition, not all Core Devs may want to spend extra time to handle Contrib Extensions. This is why it’ll be a mail asking who’s interested. If Core Devs are not interested I’ll certainly not force them to have to attend Contrib duties, that would be stupid IMO and not productive since they wouldn’t participate if they’re not interested, and thus block decision making. I remind you that when there’s a VOTE it’s a duty of the committers to reply (among other duties, which span doing code review, etc). > > > * Contrib extensions keep using the org.xwiki.contrib package name and > > groupid as currently defined at http://contrib.xwiki.org > > > > "A generic *maven groupId*: org.xwiki.contrib (or org.xwiki.contrib.> name> > if the project has several modules). That's until the project reaches > a certain size and visibility, in which case it can have its own maven > group id." > > Projects part of xwiki-contrib-extensions seem to qualify the for the > "until the project reaches a certain size and visibility" part. > > Do we really want to enforce the org.xwiki.contrib group? Personally, I > never did understand *why* we are enforcing it, above the simple fact that > we just can. The reason is simple, each project needs a group id for its artifact. When people join xwiki-contrib it’s about joining a community and doing community-based developmment (ie the code doesn’t belong to you anymore). So imagine that I publish an extension with a groupid of “net.massol.vincent” or “com.google.xxx", do you think it makes this project a nice community project owned by everyone? :) The second reason reason is that we wanted to keep open the org.xwiki.XXX (where XXX != “contrib”) namespace for the xwiki github organization. Imagine some uses org.xwiki.job for an Extension about Job Reruitment. Then Thomas would not have been able org.xwiki.job for the Job module he coded... > I don't have something in particular against new projects in > xwiki-contrib-sandbox, but for projects we are migrating from the xwiki > organization, if they are java projects, we are forcing anybody that was > using them in the past to rewrite their code (so no longer a simple > dependency change in their pom.xml), since package name would change (due > to our maven group id policy) and any code using those packages needs an > update. This is still a grey area for projects moved out of the xwiki github organization. For groupid/artifact it’s not really a problem with the relocation feature. For package names it’s much harder and I propose an exception there till the next big refactoring of the module when it’ll next break backward compat. That said there won’t be many java code moved out, it’ll be mainly XARs and thus the problem won’t happen much. You forgot to voice your opinion about this proposal! Thanks -Vincent > Thanks, > Eduard > > > > > > > > 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
