Re: [xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?

[Marius Dumitru Florea]

On Wed, May 24, 2017 at 3:28 PM, Guillaume Delhumeau <
guillaume.delhum...@xwiki.com> wrote:

> +1 for Classic
>

Classic sounds good. +1


>
> 2017-05-24 14:16 GMT+02:00 Olivier Seres :
>
> > I m also in flavor of Classic Flavor for 3 reasons :
> > For the last 10 years, it was THE (only one) proposed flavor, now we
> might
> > have more than one
> > There is "Class" in classic , sound positive to me
> > It has a distinguishable name
> >
> > I find "xwiki flavour"  confusing ( it implies that other flavors are
> > non-xwiki ones...)
> >
> > Olivier Sérès
> >
> > > Le 24 mai 2017 à 14:03, Thomas Mortagne  a
> > écrit :
> > >
> > >> On Wed, May 24, 2017 at 1:44 PM, Sergiu Dumitriu 
> > wrote:
> > >>> On 05/24/2017 05:51 AM, Thomas Mortagne wrote:
> > >>> Hi devs,
> > >>>
> > >>> I'm getting closer to finish with the hard work around new platform
> > >>> flavor which is going to replace XE.
> > >>>
> > >>> Need to decide what user will see in the Flavor picker when installed
> > XWiki now.
> > >>>
> > >>> As a reminder we decided that this would be a generic flavor, not
> tied
> > >>> to any specific use case (so forget about "Knwonledge Base Flavor"
> > >>> :)).
> > >>>
> > >>> Here is a few ideas gathered in previous mails:
> > >>> * "XWiki Flavor"
> > >>> * "Default XWiki Flavor"
> > >>> * "Generic XWiki Flavor"
> > >>> * "Base XWiki Flavor"
> > >>
> > >> A few more ideas:
> > >>
> > >> * Classic
> > >> * Raw
> > >> * Starter
> > >
> > > Not a fan or "Raw".
> > >
> > > I like "Classic", might sound better than "Default" for most users.
> > > Not sure about "Starter".
> > >
> > >>
> > >>> "Generic" is probably a way too technical term.
> > >>>
> > >>> "Base" would be misleading IMO since it's not really a base flavor.
> > >>> Its primary goal is not to be used as a dependency (of course it's
> > >>> fine to have it as dependency if you just want to add pre installed
> > >>> extensions to the default flavor). It's a -1 for me.
> > >>>
> > >>> Frankly I would simply go for "XWiki Flavor". I know, it's not going
> > >>> to be the only flavor for XWiki but it's obvious when you actually
> see
> > >>> severals of those in the picker anyway and I find it nicer than
> > >>> "Default XWiki Flavor" which basically means the same thing since the
> > >>> XWiki core project does not plan to provide any other flavor. I'm
> also
> > >>> fine with "Default XWiki Favor" if others think it's a better name.
> > >>>
> > >>> WDYT ?
> > >>>
> > >>
> > >>
> > >> --
> > >> Sergiu Dumitriu
> > >> http://purl.org/net/sergiu/
> > >
> > >
> > >
> > > --
> > > Thomas Mortagne
> >
>
>
>
> --
> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
>

Re: [xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?

[Guillaume Delhumeau]

+1 for Classic

2017-05-24 14:16 GMT+02:00 Olivier Seres :

> I m also in flavor of Classic Flavor for 3 reasons :
> For the last 10 years, it was THE (only one) proposed flavor, now we might
> have more than one
> There is "Class" in classic , sound positive to me
> It has a distinguishable name
>
> I find "xwiki flavour"  confusing ( it implies that other flavors are
> non-xwiki ones...)
>
> Olivier Sérès
>
> > Le 24 mai 2017 à 14:03, Thomas Mortagne  a
> écrit :
> >
> >> On Wed, May 24, 2017 at 1:44 PM, Sergiu Dumitriu 
> wrote:
> >>> On 05/24/2017 05:51 AM, Thomas Mortagne wrote:
> >>> Hi devs,
> >>>
> >>> I'm getting closer to finish with the hard work around new platform
> >>> flavor which is going to replace XE.
> >>>
> >>> Need to decide what user will see in the Flavor picker when installed
> XWiki now.
> >>>
> >>> As a reminder we decided that this would be a generic flavor, not tied
> >>> to any specific use case (so forget about "Knwonledge Base Flavor"
> >>> :)).
> >>>
> >>> Here is a few ideas gathered in previous mails:
> >>> * "XWiki Flavor"
> >>> * "Default XWiki Flavor"
> >>> * "Generic XWiki Flavor"
> >>> * "Base XWiki Flavor"
> >>
> >> A few more ideas:
> >>
> >> * Classic
> >> * Raw
> >> * Starter
> >
> > Not a fan or "Raw".
> >
> > I like "Classic", might sound better than "Default" for most users.
> > Not sure about "Starter".
> >
> >>
> >>> "Generic" is probably a way too technical term.
> >>>
> >>> "Base" would be misleading IMO since it's not really a base flavor.
> >>> Its primary goal is not to be used as a dependency (of course it's
> >>> fine to have it as dependency if you just want to add pre installed
> >>> extensions to the default flavor). It's a -1 for me.
> >>>
> >>> Frankly I would simply go for "XWiki Flavor". I know, it's not going
> >>> to be the only flavor for XWiki but it's obvious when you actually see
> >>> severals of those in the picker anyway and I find it nicer than
> >>> "Default XWiki Flavor" which basically means the same thing since the
> >>> XWiki core project does not plan to provide any other flavor. I'm also
> >>> fine with "Default XWiki Favor" if others think it's a better name.
> >>>
> >>> WDYT ?
> >>>
> >>
> >>
> >> --
> >> Sergiu Dumitriu
> >> http://purl.org/net/sergiu/
> >
> >
> >
> > --
> > Thomas Mortagne
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?

[Olivier Seres]

I m also in flavor of Classic Flavor for 3 reasons :
For the last 10 years, it was THE (only one) proposed flavor, now we might have 
more than one 
There is "Class" in classic , sound positive to me
It has a distinguishable name

I find "xwiki flavour"  confusing ( it implies that other flavors are non-xwiki 
ones...)

Olivier Sérès

> Le 24 mai 2017 à 14:03, Thomas Mortagne  a écrit :
> 
>> On Wed, May 24, 2017 at 1:44 PM, Sergiu Dumitriu  wrote:
>>> On 05/24/2017 05:51 AM, Thomas Mortagne wrote:
>>> Hi devs,
>>> 
>>> I'm getting closer to finish with the hard work around new platform
>>> flavor which is going to replace XE.
>>> 
>>> Need to decide what user will see in the Flavor picker when installed XWiki 
>>> now.
>>> 
>>> As a reminder we decided that this would be a generic flavor, not tied
>>> to any specific use case (so forget about "Knwonledge Base Flavor"
>>> :)).
>>> 
>>> Here is a few ideas gathered in previous mails:
>>> * "XWiki Flavor"
>>> * "Default XWiki Flavor"
>>> * "Generic XWiki Flavor"
>>> * "Base XWiki Flavor"
>> 
>> A few more ideas:
>> 
>> * Classic
>> * Raw
>> * Starter
> 
> Not a fan or "Raw".
> 
> I like "Classic", might sound better than "Default" for most users.
> Not sure about "Starter".
> 
>> 
>>> "Generic" is probably a way too technical term.
>>> 
>>> "Base" would be misleading IMO since it's not really a base flavor.
>>> Its primary goal is not to be used as a dependency (of course it's
>>> fine to have it as dependency if you just want to add pre installed
>>> extensions to the default flavor). It's a -1 for me.
>>> 
>>> Frankly I would simply go for "XWiki Flavor". I know, it's not going
>>> to be the only flavor for XWiki but it's obvious when you actually see
>>> severals of those in the picker anyway and I find it nicer than
>>> "Default XWiki Flavor" which basically means the same thing since the
>>> XWiki core project does not plan to provide any other flavor. I'm also
>>> fine with "Default XWiki Favor" if others think it's a better name.
>>> 
>>> WDYT ?
>>> 
>> 
>> 
>> --
>> Sergiu Dumitriu
>> http://purl.org/net/sergiu/
> 
> 
> 
> -- 
> Thomas Mortagne

Re: [xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?

[Thomas Mortagne]

On Wed, May 24, 2017 at 1:44 PM, Sergiu Dumitriu  wrote:
> On 05/24/2017 05:51 AM, Thomas Mortagne wrote:
>> Hi devs,
>>
>> I'm getting closer to finish with the hard work around new platform
>> flavor which is going to replace XE.
>>
>> Need to decide what user will see in the Flavor picker when installed XWiki 
>> now.
>>
>> As a reminder we decided that this would be a generic flavor, not tied
>> to any specific use case (so forget about "Knwonledge Base Flavor"
>> :)).
>>
>> Here is a few ideas gathered in previous mails:
>> * "XWiki Flavor"
>> * "Default XWiki Flavor"
>> * "Generic XWiki Flavor"
>> * "Base XWiki Flavor"
>
> A few more ideas:
>
> * Classic
> * Raw
> * Starter

Not a fan or "Raw".

I like "Classic", might sound better than "Default" for most users.
Not sure about "Starter".

>
>> "Generic" is probably a way too technical term.
>>
>> "Base" would be misleading IMO since it's not really a base flavor.
>> Its primary goal is not to be used as a dependency (of course it's
>> fine to have it as dependency if you just want to add pre installed
>> extensions to the default flavor). It's a -1 for me.
>>
>> Frankly I would simply go for "XWiki Flavor". I know, it's not going
>> to be the only flavor for XWiki but it's obvious when you actually see
>> severals of those in the picker anyway and I find it nicer than
>> "Default XWiki Flavor" which basically means the same thing since the
>> XWiki core project does not plan to provide any other flavor. I'm also
>> fine with "Default XWiki Favor" if others think it's a better name.
>>
>> WDYT ?
>>
>
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/



-- 
Thomas Mortagne

Re: [xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?

[Sergiu Dumitriu]

On 05/24/2017 05:51 AM, Thomas Mortagne wrote:
> Hi devs,
> 
> I'm getting closer to finish with the hard work around new platform
> flavor which is going to replace XE.
> 
> Need to decide what user will see in the Flavor picker when installed XWiki 
> now.
> 
> As a reminder we decided that this would be a generic flavor, not tied
> to any specific use case (so forget about "Knwonledge Base Flavor"
> :)).
> 
> Here is a few ideas gathered in previous mails:
> * "XWiki Flavor"
> * "Default XWiki Flavor"
> * "Generic XWiki Flavor"
> * "Base XWiki Flavor"

A few more ideas:

* Classic
* Raw
* Starter

> "Generic" is probably a way too technical term.
> 
> "Base" would be misleading IMO since it's not really a base flavor.
> Its primary goal is not to be used as a dependency (of course it's
> fine to have it as dependency if you just want to add pre installed
> extensions to the default flavor). It's a -1 for me.
> 
> Frankly I would simply go for "XWiki Flavor". I know, it's not going
> to be the only flavor for XWiki but it's obvious when you actually see
> severals of those in the picker anyway and I find it nicer than
> "Default XWiki Flavor" which basically means the same thing since the
> XWiki core project does not plan to provide any other flavor. I'm also
> fine with "Default XWiki Favor" if others think it's a better name.
> 
> WDYT ?
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/

Re: [xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?

[Ecaterina Moraru (Valica)]

On Wed, May 24, 2017 at 12:51 PM, Thomas Mortagne  wrote:

> Hi devs,
>
> I'm getting closer to finish with the hard work around new platform
> flavor which is going to replace XE.
>
> Need to decide what user will see in the Flavor picker when installed
> XWiki now.
>
> As a reminder we decided that this would be a generic flavor, not tied
> to any specific use case (so forget about "Knwonledge Base Flavor"
> :)).
>
> Here is a few ideas gathered in previous mails:
> * "XWiki Flavor"
> * "Default XWiki Flavor"
>

+1 for Default XWiki Flavor


> * "Generic XWiki Flavor"
> * "Base XWiki Flavor"
>
> "Generic" is probably a way too technical term.
>
> "Base" would be misleading IMO since it's not really a base flavor.
> Its primary goal is not to be used as a dependency (of course it's
> fine to have it as dependency if you just want to add pre installed
> extensions to the default flavor). It's a -1 for me.
>
> Frankly I would simply go for "XWiki Flavor". I know, it's not going
> to be the only flavor for XWiki but it's obvious when you actually see
> severals of those in the picker anyway and I find it nicer than
> "Default XWiki Flavor" which basically means the same thing since the
> XWiki core project does not plan to provide any other flavor.


I really hope that in future we will change our mind (and have the
resources) to support more than 1 flavor.

Thanks,
Caty


> I'm also
> fine with "Default XWiki Favor" if others think it's a better name.
>
> WDYT ?
>
> --
> Thomas Mortagne
>

[xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?

[Thomas Mortagne]

Hi devs,

I'm getting closer to finish with the hard work around new platform
flavor which is going to replace XE.

Need to decide what user will see in the Flavor picker when installed XWiki now.

As a reminder we decided that this would be a generic flavor, not tied
to any specific use case (so forget about "Knwonledge Base Flavor"
:)).

Here is a few ideas gathered in previous mails:
* "XWiki Flavor"
* "Default XWiki Flavor"
* "Generic XWiki Flavor"
* "Base XWiki Flavor"

"Generic" is probably a way too technical term.

"Base" would be misleading IMO since it's not really a base flavor.
Its primary goal is not to be used as a dependency (of course it's
fine to have it as dependency if you just want to add pre installed
extensions to the default flavor). It's a -1 for me.

Frankly I would simply go for "XWiki Flavor". I know, it's not going
to be the only flavor for XWiki but it's obvious when you actually see
severals of those in the picker anyway and I find it nicer than
"Default XWiki Flavor" which basically means the same thing since the
XWiki core project does not plan to provide any other flavor. I'm also
fine with "Default XWiki Favor" if others think it's a better name.

WDYT ?

-- 
Thomas Mortagne

Re: [xwiki-devs] [Proposal] GitHub code reviews and protected branches

[Thomas Mortagne]

I really don't believe in mandatory pull requests for everyone, it
always sounds good in theory but in practice it would just be a
frustrating nightmare for core committers (at best we'll just validate
each other pull request without really looking at them much most of
the time defeating the whole purpose). I prefer trusting core
committers to create pull requests (or ask for branch review) when
they are not confident enough with what they did (which they currently
do).

On the lets make master branch great again, it would sure be nice to
have build results for branches/pullrequests on
commons/rendering/platform/enterprise (I'm very happy to have this on
Contrib extensions). But with the current flickerings tests we have in
some UI tests, an automated merge is simply not applicable right now.
It can only be an information (a very useful one) given to whoever
created the branch before merging it. But as Edy pointed out it should
not be over used as Jenkins already suffer quite a bit right now
(unless we boost ci infrastructure of course).

Also keep in mind that in a multi repositories projects like XWiki you
can't fully rely on build result of your commit/branch's repository,
xwiki-platform build is often broken by a changes made to
xwiki-commons and xwiki-enterprise build failures almost never have
anything to do with one of its commits (even if xwiki-enterprise
repository should vanish is not too long but it won't improve the
already very long platform build).

On Wed, May 24, 2017 at 1:08 AM, Eduard Moraru  wrote:
> Hi,
>
> Very interesting discussion.
>
> Not much to add to what was already said.
>
> I have always questioned the fact that we keep the master branch as the
> main development branch and it is very easy for someone new to clone it at
> the wrong time (i.e. when the build is failing) and get confused fast. Most
> github projects I see use the master branch as a stable-development branch
> to which they merge reviewed code or code from other active-development
> branch(es).
>
> Side note: One really nice feature that I would like to see on GitHub would
> be the ability to review already pushed commits (i.e. a "post-mortem"
> review). You would then have a nice overview of code that was *never*
> reviewed by anyone and could easily develop a workflow that tolerates
> direct pushes, but requires that even they are eventually reviewed
> (possibly with some Review Percentage Coverage minimum limit). I`m not sure
> I`m such a big fan of PR-only commits. Ultimately, I think I would even be
> in favor of getting your code in faster and fixing/reverting in case of
> problems (i.e. the opposite direction) instead of raising even more
> barriers in front of the contribution/commit.
>
> General question about building-checking each PR: If PR1 is built by CI
> automatically and is marked as PASSED, but commit A is pushed into master
> and it would make PR1 now fail the build, is PR1 re-built after commit A is
> pushed to master? If so, does it mean that each commit to master also
> triggers a rebuild of all the N PRs waiting for review to make sure they
> are not broken? AFAIU, this is the way things should work, however, given
> the elegant behemoth that XWiki has become, the build times and the stress
> on the CI infrastructure would IMO kill any fun and joy of developing and
> actually making a change in the project.
>
> I`m all for Code Reviews and a system that improves the current state where
> nobody is really responsible with it and, if it happens, it is generally
> done by the same few people.
>
> The way I imagine the perfect review system is one where each commit and
> each PR gets a reviewer automatically assigned from the organization (other
> than the author, ofc). PRs are blocked by the reviewer's approval and
> direct commits should (maybe/somehow?) be blocked by a Review Coverage
> Threshold, similar to the TPC at build time. I believe that if we could
> achieve this, it would invalidate the need for more complex branch/fork
> management and other formalities. With a bit of an effort and maybe GitHub
> API magic, I believe it could even be achievable to a certain extent.
>
> As you`ve said, the ultimate goal is for people to see the code and avoid
> finding things introduced 7 years ago that nobody *ever* had a second look
> at.
>
> Hope this helps, somehow :)
>
> -Eduard
>
> On Tue, May 23, 2017 at 9:05 AM, Sergiu Dumitriu  wrote:
>
>> Hi Vincent,
>>
>> On 05/17/2017 09:30 AM, Vincent Massol wrote:
>> > Hi Sergiu,
>> >
>> >> On 16 May 2017, at 07:36, Sergiu Dumitriu  wrote:
>> >>
>> >> Hi devs,
>> >>
>> >> A while ago GitHub introduced several features that I think can help
>> >> boost even more the code quality, reduce the bus factor, and make it
>> >> more attractive to contribute to the project.
>> >>
>> >> = Protected branches =
>> >>
>> >> Branches can be configured as protected in several ways:
>> >> * Require pull 

Re: [xwiki-devs] [Proposal] Removed deprecated "Panels.SpaceDocs", "Panels.Spaces", "Main.Spaces" and "Main.SpaceIndex"

[Thomas Mortagne]

On Wed, May 24, 2017 at 12:14 AM, Eduard Moraru  wrote:
> On Tue, May 23, 2017 at 7:55 PM, Vincent Massol  wrote:
>
>>
>> > On 23 May 2017, at 18:37, Eduard Moraru  wrote:
>> >
>> > Hi,
>> >
>> > My only point to this discussion is that, as Thomas (I believe) already
>> > mentioned, since 7.2 spaces are deprecated. We can consider that the time
>> > in between (7.2-9.5) was more than enough for anyone still using spaces
>> to
>> > migrate to Nested Pages (and the NP-based alternatives), this includes us
>> > doing the "deprecation" approach and keeping those pages.
>>
>> I agree that it’s been a long time. I actually put this information in the
>> jira issue:
>> https://jira.xwiki.org/browse/XWIKI-13101
>>
>> "
>> Specifically:
>> * Panels.SpaceDocs was deprecated in XWiki 7.3M2 (XWIKI-12599)
>> * Panels.Spaces  was deprecated in XWiki 7.4.2/8.0M2 (XWIKI-12829)
>> * Main.Spaces and Main.SpaceIndex are also deprecated by the move to
>> nested pages and the removal of the Space notion from the UI
>> “
>>
>> Note that we never deprecated officially Main.Spaces and Main.SpaceIndex.
>>
>> > Now that the time
>> > has past, I believe it is safe to remove those pages and move forward.
>> >
>> > Otherwise, if we plan to support them even further, IMO, we`ll end up in
>> a
>> > ridiculous situation, supporting code that has no value and that nobody
>> > should be using anymore.
>>
>> Note that this is what we’re doing for APIs so I assume you consider pages
>> to not be as important as APIs (or at least those pages).
>>
>
> I think you`ve missed by point completely :)
>
> I consider those pages deprecated by default (because their behavior is no
> longer doing what it was originally supposed to do) starting with 7.2. Our
> deprecation strategy says to leave them on about 2 major releases. We are
> now working towards 9.5. I consider that enough time in order to both
> respect our deprecation strategy and be able to move forward (i.e.
> dropping/removing/killing them with fire :) ).
>

> Yes, we *are* doing the same thing with API, so I don`t see why we should
> add yet *another* deprecation layer (i.e. 2 major releases starting from
> now), hence the "ridiculous situation" I`ve mentioned). Yes, it was never
> "deprecated officially", but so what if they stopped doing what they were
> supposed to do?

Note: no we are not doing this with deprecated Java APIs actually. You
are mixing with @Unstable rule I think. The current rule is to never
fully "dropping/removing/killing them with fire", just when it's not
too hard extract them in easily installable extensions after a while
(which is what I'm proposing here, 7.2 -> 9.4 sounds like "a while"
enough to me).

>
> Note: I don`t have anything against moving them to some dark basement (i.e.
> contrib repo) either, just that I would not invest more in the process more
> than writing one phrase in the readme file. AFAIK, we did not do this in
> the past (i.e. retiring code without properly documenting it), however,
> previously retired projects had a lifecycle of their own and basic value,
> so that`s why I`m in favor of just discarding this now unused/not working
> code.
>
> Anyway, that`s my view of the subject.
>
> Thanks,
> Eduard
>
>
>> > So I`m +1 for removing them.
>>
>> Remove them altogether or do the hard work of creating a special extension
>> for them and releasing that extension?
>>
>> Personally if we do the "remove from platform” (which seems to be the
>> direction so far) then I’d drop them altogether because I don’t think
>> anyone would notice that those pages still exist somewhere and we don’t
>> have any automatic way of conveying that information to the user (except
>> release notes but we know this isn’t foolproof and we could link to the
>> last version of those pages in the SCM or the last version of the XARs
>> containing them if someone really needs to get them back.
>>
>> Thanks
>> -Vincent
>>
>> >
>> > Thanks,
>> > Eduard
>> >
>> > On Tue, May 23, 2017 at 6:33 PM, Vincent Massol 
>> wrote:
>> >
>> >>
>> >>> On 23 May 2017, at 17:03, Marius Dumitru Florea <
>> >> mariusdumitru.flo...@xwiki.com> wrote:
>> >>>
>> >>> On Tue, May 23, 2017 at 5:07 PM, Vincent Massol 
>> >> wrote:
>> >>>
>> 
>> > On 23 May 2017, at 16:01, Marius Dumitru Florea <
>>  mariusdumitru.flo...@xwiki.com> wrote:
>> >
>> > On Tue, May 23, 2017 at 4:25 PM, Vincent Massol 
>>  wrote:
>> >
>> >>
>> >>> On 23 May 2017, at 15:22, Marius Dumitru Florea <
>> >> mariusdumitru.flo...@xwiki.com> wrote:
>> >>>
>> >>> On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne <
>> >> thomas.morta...@xwiki.com>
>> >>> wrote:
>> >>>
>>  I would be more in favor of moving them to some extension than can
>> >> be
>>  easily installed if really needed.
>> 
>> >>>
>> >>> +1 for moving to an