17 Dec
2015
17 Dec
'15
2:51 p.m.
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.
Let me be clear.
We have until Christmas to work on this and after that we will be done.
If we are held up because you want to block us until we do other things, I feel that we
are being abused and extorted for work.
More concretely, if this involves any kind of discussion or back-and-forth which lasts
until Christmas, we will simply miss our objective and not solve our objectives.
* 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.
* 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 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.
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 <cjd(a)cjdns.fr> 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:
_______________________________________________ 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
On 16 Dec 2015 at 16:56:57, Yann Flory (yann.flory(a)xwiki.com(mailto:
yann.flory(a)xwiki.com)) wrote:
Hello devs,
devs mailing list devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/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
_______________________________________________ devs mailing list devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________