17 Dec
2015
17 Dec
'15
10:49 p.m.
Hi Caleb,
On 17 Dec 2015 at 14:53:13, Caleb James DeLisle (cjd@cjdns.fr(mailto:cjd@cjdns.fr))
wrote:
I’ve already explained why it makes sense to keep them together for me:
* This allows to release them together and thus ensure they’re compatible. If you don’t do
this you need to test multiple combinations of versions and keep a compatibility matrix,
which is a pain. We’ve been there in the past if you remember and it was a nightmare. This
is for example why we release all modules together for commons, rendering, platform and
enterprise.
So if by maintenance you mean ensuring that the syntax highlighting and autocompletion
apps continue to work the yes you’re right, that’s the idea! It seems fair to ensure that
changing the library used by those 2 apps shouldn’t introduce breakages in them.
Don’t you think so?
[snip]
also be
available to the application, on release. If we desynchronize them, the application will
most likely be left behind.
I interpret your words to mean: we want to keep them merged in order to conscript any
contributors (meaning us) into doing additional maintanence. * We can split this into 2 extensions as we discussed,
I am willing to proceed with the same repository/JIRA.
* We can test the result and verify that there are no changes to the frontend version for
the user.
Cool
* We cannot do this within the given time requirement
as long as there is NO BIKESHEDDING.
** An example of bikeshedding is here:
https://github.com/xwiki-contrib/wiki-editor-devtools/pull/3
** What makes it bikeshedding is the fact that the complaints are about process or
"a better way to do it", not code which is seriously dangerous to accept.
I’m not going to comment more on this as it won’t make us progress.
I want to collaborate on this, what I don't want
is to be in a gatekeeper relationship in 1 week and then fail at my objective because of
that.
Please let me know if this is ok for you.
If by gatekeeper you mean being responsible for all future maintenance of this module,
then rest assured that it won’t happen. We’ve been wanting to bring this repository into
platform from day one (when Edy and I started it in a hackathon session a few years ago).
So the goal is for us to maintain it in some not too long future hopefully. Unfortunately
our roadmap so far has not really been very keen for this module but I have the feeling
that its importance is going to rise :)
Thanks for helping,
-Vincent
PS: I think it would be nice to hear from Yann too since he’s the developer of this work
and it would be interesting to hear his POV and work with him and understand if he has any
issue with this.
Thanks,
Caleb
On 17/12/15 09:25, vincent(a)massol.net wrote:
> I agree with Edy that it’s better to release them together: * Simplifies a lot the
matrix compatibility tests * Ensure they’re in sync * Simplify release processes
>
> Thanks -Vincent On 16 Dec 2015 at 19:01:38, Eduard Moraru (enygma2002(a)gmail.com)
wrote:
>
> Hi Caleb,
>
> (just saw your reply)
>
> On Wed, Dec 16, 2015 at 6:19 PM, Caleb James DeLisle wrote:
>
>> They're going to have distinct release cycles
>
>
> This is exactly what I hope to avoid by not separating the code from the
application. This way, whatever improvements you bring to the code, will also be available
to the application, on release. If we desynchronize them, the application will most likely
be left behind.
>
> Also, it will give you a way be constantly reminded that the code module is used by
other projects as well, and should remain generic enough and, at the same time, it will
not bring any overload since the application itself is extremely basic to maintain.
>
> Thanks, Eduard
>
>
>> so I think the least ugly thing to do is have 2 projects.
>>
>> Thanks, Caleb
>>
>
>>
>>
>> On 16/12/15 17:12, vincent(a)massol.net wrote:
>>
>>>
>>>
>>> On 16 Dec 2015 at 16:56:57, Yann Flory (yann.flory(a)xwiki.com(mailto:
yann.flory(a)xwiki.com)) wrote:
>>>
>>> Hello devs,
>>>>
>>>> In order to be able to use the CodeMirror editor in other extensions,
we'd like to split the Syntax Highlighting application in two parts (Cf
http://jira.xwiki.org/browse/WIKIEDITOR-37) A new extension, Syntax Highlighting UI
Module, would be created and it would provides the ability to transform a given textarea
into a CodeMirror editor. The current extension would keep the part which detect all
textareas in 'edit' mode and transform them into CodeMirror editors (with a
dependency on
>>>> the new extension). If this is accepted, we'll need a new Jira
project for the module.
>>>>
>>>
>>> Note: We create a jira project per repo, I don’t think we need 2 jira
projects. We could have 2 jira “components” though.
>>>
>>> Thanks -Vincent