13 Nov
2014
13 Nov
'14
6:47 p.m.
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
The list looks good. We should make some rules for what we move to contrib
or not (Selenium, etc. - like the last date we did some commits on the app,
if it's still working, etc.), and also a list for functionality that is not
packaged as application/macro, like Indexes (Doc, Users), Share page by
e-mail, Help, etc.
We also have applications like Invitation, Statistics, Annotations,
Watchlist, Dashboard that in the future we might want to move and make
available just for certain flavors.
Also maybe we would want to group somehow the macros?
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 - ?
WDYT about both lists? Any opinion?
There are some other interesting applications on e.x.o, but I guess one of
the rules would be to go over a reviewing process of the code. I don't
think we should hurry with the apps and just move them one by one after the
review.
Some apps might be very useful, but they haven't been updated in a while
(Ratings, Admin Tools, Exports, etc).
Should Flavors be listed separate?
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.
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.
We are redesigning some apps to make them look good on Flamingo, but the
skin is available starting with 6.2. We are making sure they work on
Colibri, but was just a note.
Thank,
Caty
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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.
>
> * 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