On Fri, Nov 14, 2014 at 12:36 PM, Eduard Moraru <[email protected]> wrote: > Hi, > > On Thu, Nov 13, 2014 at 6:15 PM, [email protected] <[email protected]> > wrote: > >> Trying to progress on this… >> >> Some points: >> >> 1) As an exercice, I’ve started listing all extensions currently located >> in platform that we should move outside of xwiki-platform, if we follow the >> voted rule below: >> >> * Active Installs App >> * Blog (still bundled in XE ATM) >> * FAQ App >> * Git module >> * IRC Bot App >> * JIRA module (not the macro) >> * Link Checker >> * Menu App >> * Release App >> * PHP Macro >> * Gallery Macro >> * Python Macro >> * RSS Macro >> * Useravatar macro >> * Repository App >> * Selenium App (should be moved to contrib actually) >> * Zip Explorer plugin >> > > So the only (/main) criteria here is that these extensions are not bundled > in XE, right? +1 from me > > Now, this would be just an awesome moment to do something we`ve been > talking about for a while, which is to move all UI-related extensions
> outside of xwiki-platform so that we end up with xwiki-platform-web You mean xwiki-enterprise-web? There are no dependencies in xwiki-platform-web. > depending only on the extensions in xwiki-platform/commons/rendering that > are vital for a barebone/minimal wiki instance to be up and running and to > launch the DistributionWizard/ExtensionManager. Obviously, > xwiki-enterprise-ui-* would be left in charge of depending on needed stuff > and bringing the dependencies transitively when the UI is installed; one > step closer towards flavors. > > I also understand that we can do this iteratively and not make that big of > a jump right now, but anyway, my suggestion is that we should; or at least > schedule it for 7.0. > > >> >> I’ve also reviewed some apps on xwiki-contrib that we may want to move >> inside the xwiki GitHub org and here are some candidates (each app would >> need a manager who volunteer to manage the app as defined by our rules >> below of course - I’m putting some ideas of names, they’re just ideas!). >> Note that most of these apps are not ready to be moved and would need some >> cleanup/some func tests first: >> >> * File Manager App - Marius >> * GitHub Stats App (used on xwiki.org) - Vincent >> * Forum App - ? >> * Mocca Calendar App - Clemens >> * Meeting Manager App - ? >> * Idea Application - ? >> * xwikorg flavor - Vincent >> * Ratings App - ? >> * Presentation App - Vincent >> * Wiki Editor Devtools (autocomplete + highlighting) - Edi/Vincent >> * Video Macro - ? >> * Diagram App - Marius >> * Admin Tools App (would need to be cleaned up) - ? >> * Task Manager App - ? >> >> > The upside of this is that it will be much clearer who is the "expert" on > certain domains/applications, however we must also watch out for an > increase in the "bus factor" that such a list would introduce. > > +1 for the intention, ATM. > > >> WDYT about both lists? Any opinion? >> >> 2) We’ll need to decide the version number for extensions we move from >> platform. I propose to continue using their current version but detach them >> from platform once they’re moved. For example the FAQ app, if moved now, >> would have version 6.4-SNAPSHOT and its next release would be 6.4, then >> 6.4.1 or 6.5, etc. >> > > +1 for basing their version numbers from the time they were detached from > XWiki's release cycle, as suggested. > > >> >> 3) We’d need to decide what version of XWiki is supported by each >> extension. Since we officially support 3 versions (last super stable, last >> stable and dev version), I propose that by default extensions would support >> the latest super stable version without the bugfixing part. For example >> right now last super stable is 5.4.5 which would mean that extensions would >> depend on XWiki 5.4 (ie can be installed in XWiki 5.4+). Of course if some >> extensions require a new feature that has only be added recently (for >> example webjars) then it could decide to only support more recent versions >> of XWiki but it would be on an exception basis. >> > > IMO, the *best* thing about this change for users would be the ability to > upgrade individual extensions/modules without having o migrate their entire > wiki to a newer version. See the discussion [1] I raised recently about > this. > > As a result, and as Thomas also suggested in a previous reply here (if I am > not mistaken), each detached extension should depend on the minimum XWiki > version as it is technically possible, in order to maximize compatibility > and installability over the widest range of XWiki versions as possible. > Introducing artificial bounds like LTS or something else is, I believe, > damaging to users and brings no value to either devs or users. Of course, > when newer versions of the extensions require features available in later > XWiki versions, the minimum required version should be raised accordingly, > but always be preserved to a minimum. > > [1] http://markmail.org/message/zohkn73srh7dwom4 > > Thanks, > Eduard > > >> WDYT? >> >> Thanks >> -Vincent >> >> On 14 Jul 2014 at 14:11:14, [email protected] ([email protected](mailto: >> [email protected])) wrote: >> >> > >> > Results: 8 +1, no 0, no -1 >> > >> > The vote is passed. I’ve documented it here: >> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLevelExtensions >> > >> > Going to start implementing it by sending some votes to move some >> extensions. >> > >> > Note: let’s not forget to update >> http://dev.xwiki.org/xwiki/bin/view/Community/SourceRepository when new >> top level repos are added in the xwiki organization. >> > >> > Thanks >> > -Vincent >> > >> > >> > On 7 Jul 2014 at 18:39:19, [email protected] ([email protected] >> (mailto:[email protected])) wrote: >> > >> > > >> > > Hi devs, >> > > >> > > Following the proposal thread at >> http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve >> prepared below a full proposal that I’d like us to VOTE on. >> > > >> > > Rationale/Need >> > > =============== >> > > >> > > The needs: >> > > * Be able to extract some apps from xwiki-contrib that the XWiki Dev >> Team would like to maintain. Example: File Manager app developed by Marius >> when it’ll have had some releases and tests (if it doesn’t have some >> already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum >> App, etc >> > > * Be able to extract some extensions currently located in >> xwiki-platform but not released with XE so that they can have a different >> release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). >> Having different release cycle allow to release new versions quicker to our >> users (bug fixes, new features). >> > > >> > > Governance >> > > ========== >> > > >> > > Details: >> > > >> > > * Extensions are VOTEd in on a case by case basis. >> > > >> > > * Each voted extensions will have its own Git Repository in the >> “xwiki” organization (so that each extension can be released independently >> of each other). >> > > >> > > * When moving an extension either from xwiki-contrib or from >> xwiki-platform, keep its Git history as much as possible or simply donate >> the repo to the “xwiki" organization. >> > > >> > > * FTM extensions bundled by default with XE would still remain in >> XWiki Commons/Rendering/Platform/Enterprise. >> > > >> > > * The Git repository name should be of the form xwiki-. should be part >> of the VOTE. >> > > >> > > * All rules from http://dev.xwiki.org apply >> > > >> > > * Each extension has a Release Manager defined and he’s responsible >> for defining its own Roadmap/Release notes (if need be), on the extension >> page on e.x.o and perform the releases or ensure the extension is released >> regularly when there are changes. >> > > >> > > * Each extension must follow these criteria for being VOTEd: >> > > ** A Release Manager needs to be defined in the proposal >> > > ** The extension must have had several releases already (i.e. someone >> wanting to propose a new extensions that doesn’t exist would start in >> xwiki-contrib for ex and prove that his extension works and is useful by >> doing several releases and creating the pages on e.x.o) >> > > ** It must follow our best practices defined on http://dev.xwiki.org >> (coding practices, tests, etc) and follow the apps best practices (for >> apps), see >> http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPractices >> > > ** It must have one or several integration or functional tests (for >> apps) to prove that it works. This allows to prove the app continues >> working when XWiki progresses >> > > ** The main contributors of the extensions must agree about the move. >> If they have the “level" to be an xwiki dev committer then they should be >> voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). >> If not then either they’re ok to send Pull Requests or the extension should >> not be moved. >> > > >> > > * If an extension ceases to work or if its quality becomes too low, it >> can be moved to xwiki-contrib with a VOTE >> > > >> > > * We would create one JIRA project per extension >> > > >> > > * We would create a new JIRA Category called “XWiki Extensions” >> > > >> > > * We would put the extensions in our CI at http://ci.xwiki.org >> > > >> > > * The Java package should follow the same rule as for XWiki Platform, >> i.e. org.xwiki.. Exceptions would need to be discussed. >> > > >> > > * The group id for extensions having their own repo should be >> org.xwiki.. The needs to be part of the VOTE when proposing a new >> extensions. >> > > >> > > Here’s my +1 >> > > >> > > 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 >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
