23 Jun
2016
23 Jun
'16
9:11 a.m.
On 22 Jun 2016, at 20:13, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
Hi,
On Wed, Jun 22, 2016 at 12:57 PM, Vincent Massol <vincent(a)massol.net> wrote:
that we
individual
I`m personally sensing that we may have a bit of a confusion here between
the notion of separate release cycles and the repo in which an extension
should be located.
AFAIU, the top priority and the actual problem that we want to fix here
(mainly for our users and XWIki`s flexibility) is to allow extensions to
have independent release cycles. Moving stuff to contrib just got somehow
into the discussion as a consequence of the old way we used to handled
things (xwiki org = monolith, single version; contrib org = distributed;
independent versions).
In the past, people (including myself) were pushing to move modules to
contrib for the independent versioning feature of contrib, but not
necessarily for the "openness for anyone to commit" feature of contrib.
That last feature was actually a downside to the quality aspect. If we
handle independent versioning within the xwiki GitHub organization, then we
will no longer have this downside and we will be able to properly control
the quality. This would mean that the Default Flavor would be in a repo
under the xwiki org (similar to xwiki-enterprise, as Vincent's proposal)
and I would even go as far as suggesting that all the dependencies of the
Default Flavor should be located/moved within the xwiki org, perhaps in
some xwiki-extensions repo (that we were talking about at some point).
I agree that this might sound a bit like going in circles, but IMO it`s not
entirely true, now that we introduce independent versioning in the
discussion, since it fixes a lot of problems we have in the previous
discussions were we were wrongly using Contrib, to compensate for it, since
the xwiki org was a big monolith.
Now what happens to the remaining modules inside xwiki-platform and the
Base Flavor, I would guess that, at least at the beginning, they will
continue to function as a monolith, at least until we decide to tackle the
notion of "core" dependencies and if we want to do something about them
(see my note about this on the previous thread).
WDYT?
Indeed going in circles a bit here but it’s an important decision… However we need to
conclude quickly since we need to implement the solution for 8.2RC1 i.e. we need to close
this thread at latest this week.
Point 1: Scope of xwiki github org
==========================
The strategy we’re voting here is about having XWiki Core Dev Team (aka XWiki Github Org)
to be focusing about core stuff and reducing the scope of the core as we progress. And
letting the community at large handle the non-core modules.
What you mention above (and which was already proposed in the previous thread BTW) would
lead to keep the same scope for the XWiki Core Dev Team.
As you mention it also leads to making it more complex for others to contribute.
Also don’t forget that we’ve already voted to move stuff ouf of xwiki github org and we’ve
already started (markdown syntax, various platform modules already moved out), and have
even already voted to move more stuff out.
So the direction is to slim down the xwiki github repo, not just because we also want
users to be able to install extensions in older versions of XWiki.
Point 2: dependency hell
===================
I would prefer that we keep releasing all XWiki Github Org together as much as possible to
avoid dep hell (and increased testing efforts) as we had before. It’s fine to decide to
include a few third party modules but that’s very different from deciding that the rule is
now that all modules can have their own release cycle inside core.
If the way to do this and be consistent is to say that the default flavor is released with
the same versioning cycle than all the rest of the XWiki Github Org then I’d prefer that.
Other thoughts
============
Now we could decide to move just CKEditor inside xwiki github org with the argument of
controlling the quality. I think it would be more difficult to justify moving the Tour
app. Also note that we should prevent ourselves from being able to bundle other third
party extensions in the future in the default flavor if we think they should be in by
default so I think we should still keep the strategy proposed in this thread.
I view the proposal in this mail as an add-on and not a replacement, i.e. to be clear:
* Keep the same logic as proposed for xwiki github org
* Still have a base and default flavor in xwiki github org
* Still be allowed to bundle third party extensions in the default flavor
* NEW: Allow ourselves to have special extensions in xwiki github org that have their own
release cycles, and CK would be the first
Right now I’m not fully convinced that we need to do this and I’d rather continue with the
proposal as is and keep CK outside. The only reason to move it to the xwiki github org IMO
is for quality reasons and I’d rather wait till we see a problem before considering it.
Actually this thread mentioned about defining what a “basic wiki” is. I think we should
consider moving CK in only if we consider that a WYSIWYG editor is part of a “basic wiki”.
But I’m not convinced that a basic wiki requires 2 editors (the wiki one + a WYSIWYG
one).
WDYT?
Thanks
-Vincent
On 22 Jun 2016, at 10:02, Marius Dumitru Florea
<
mariusdumitru.florea(a)xwiki.com> wrote:
+1
On Tue, Jun 21, 2016 at 7:00 PM, Vincent Massol <vincent(a)massol.net>
wrote:
> Hi devs,
>
> I’m transforming the brainstorming that was started in the thread
> http://markmail.org/message/exlndbq3tw2thmmu into a VOTE mail since
this
> is a very important decision.
>
> So I’m asking you to vote for defining a new direction for the XWiki
Core
> Dev Team (i.e. for the XWiki GitHub
Organization). The need was
triggered
> by the Tour and CKEditor extensions which are
currently in xwiki-contrib
> and that we want our users to have by default. For more details see this
> thread: http://markmail.org/message/exlndbq3tw2thmmu
>
> So here’s the strategy:
>
> * Make XWiki Github org == minimal runtime, where minimal means “basic
> wiki” (page edition, history, linking, wiki markup, etc). The notion of
> “basic wiki” would need to be better defined but this can be done later
on.
> * Provide a "Base Flavor" which
corresponds to this “basic wiki”, as
part
> of xwiki-platform (this would be
xwiki-platform-distribution).
> * Provide another flavor, the "Default Flavor” which would add some
> hand-picked third-party extensions (i.e. from contrib) such as the Tour
app
and
CKEditor (to start with, we could also add the markdown syntax for
example which is one of the most asked syntaxes). Note that this Default
Flavor would actually be a “replacement" of xwiki-enterprise.
> * The Default Flavor would have at least the same release cycle as the
> base flavor but it could have more releases (if some of the bundled
> third-party extensions has some important bug fixes or new features want to
offer quickly without waiting for the next base flavor release).
I don't think we need to release the Default Flavor more often than the
Base Flavor because with this new strategy the users can upgrade extensions (those that are not in the Base
Flavor) without upgrading the
WAR.
As I said, if we find some important bug (for example) and this bug is
only in one of the 3rd party extensions, it would be a pity not to release
just the Default Flavor IMO and wait for 2 months more. Even if users can
upgrade their extensions, it’s better that users new to XWiki
download/install the best possible version right away instead of having to
upgrade.
We’ll see when the need arises but I don’t think we should stop ourselves
from this possibility. Technically this means putting the Default Flavor in
a separate github repo (same as xwiki-enterprise being in a separate repo).
We need to discuss how we do it:
- consider it’s XE for now and just add the 2 deps of Tour and CK to XE
- introduce a new repo for the default flavor and do the build for it and
deprecate XE in favor of it. For now we probably need to hardcode the
flavor id in the platform WAR till we’re ready to have the flavor selection
screen at startup (and for HSQLDB/Jetty packaging we need a hard-coded
flavor anyway).
Thanks,
Eduard
So, having that in mind, I would think of some questions:
-
>
> Thanks
> -Vincent
>
>> Currently the users cannot upgrade the Blog because the new version of
>> the Blog depends on a new version of the XWiki WAR. With this new
> strategy
>> the users will be able to upgrade the Blog (considering that the Blog is
>> not part of the Base Flavor).
>>
>> On the same topic, we have the Extension Updater administration section
>> where users can check for extension updates. The problem is that the
>> extensions included in a flavor are considered dependencies of the flavor
>> and thus are installed as dependencies which means the Extension Updater
>> cannot separate them from other technical dependencies and thus won't
> check
>> for their updates. Ideally a flavor should be a pack of extensions that
> are
>> installed explicitly (not as dependencies). This way the Extension
> Updater
>> can propose updates and at the same time the users can uninstall
> extensions
>> from a flavor without removing the flavor.
>>
>> Thanks,
>> Marius
>>
>>
>>> * The consequence is that the XWiki Dev Team would need to be a bit more
>>> careful to monitor the quality of bundled third-party extensions in
> contrib
>>> (check commits, do some smoke testing, etc). Note that the goal of the
>>> Default flavor would not be to offer verticals (for this there should be
>>> some contrib flavors) and thus it wouldn’t bundle a lot of third-party
>>> extensions. Basically we’ll need to validate the version of those
>>> third-party extensions that include in the flavor.
>>>
>>> My POV is that globally this would offer more flexibility for our users
>>> (they’ll be able to install extensions such as CK and Tour in older
> XWiki
>>> versions and they’ll get more frequent releases) at the cost of some
>>> overhead to develop extensions that work in several versions. The dev
> team
>>> is pretty small and thus it means developing a bit less fast but it’s
>>> probably as important, if not more important, to make the code we
> develop
>>> available in older xwiki versions, as XWiki gains traction.
>>>
>>> Here’s my +1
>>>
>>> Please cast your vote.
>>>
>>> Thanks
>>> -Vincent