17 Nov
2014
17 Nov
'14
11:04 a.m.
On Mon, Nov 17, 2014 at 11:09 AM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
them
last
entire
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Nov 14, 2014 at 12:36 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
bundled
Right.
Thanks,
Eduard
Hi,
On Thu, Nov 13, 2014 at 6:15 PM, vincent(a)massol.net <vincent(a)massol.net>
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 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 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, > 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 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, vincent(a)massol.net (vincent(a)massol.net
(mailto:
> vincent(a)massol.net)) 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#HTopLeve…
> >
> > 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, vincent(a)massol.net (vincent(a)massol.net
> (mailto:vincent@massol.net)) 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/ApplicationDevelopmentBestPra…
> > > ** 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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs >
> * 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs