Hi Vincent, In the light of the discussion about speed versus quality that is in progress on these modules, I feel that it would make only things worse for speed if these modules go in the core. If would mean that the modules would only evolve with the core releases.
I don't see how this would help people writing extensions be efficient when they need patches in the underlying modules. I've seen this issue with other core modules where as an extension developer you still have to work around a bug or a lacking feature because the fix or improvement needed will only come in the next major release. I would suggest we move things into the core only when we consider them highly stable. Ludo On Dec 17, 2015 15:00, "vinc...@massol.net" <vinc...@massol.net> wrote: > Also note that we’ve discussed in the past about moving the autocompletion > and syntax highlighting modules into xwiki-platform as they can be > considered core modules. > > I’ll send a proposal about this as I feel these modules should be > maintained and developed in the core, for the same reason that AWM should > be in the core: the core should provide good developer tools by default. > > Thanks > -Vincent > > On 17 Dec 2015 at 14:53:16, Caleb James DeLisle (c...@cjdns.fr) wrote: > > > 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, vinc...@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 ( > enygma2...@gmail.com) wrote: > > > > Hi Caleb, > > > > (just saw your reply) > > > > On Wed, Dec 16, 2015 at 6:19 PM, Caleb James DeLisle <c...@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, vinc...@massol.net wrote: > >> > >>> > >>> > >>> On 16 Dec 2015 at 16:56:57, Yann Flory (yann.fl...@xwiki.com(mailto: > yann.fl...@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 > >>> > >>> _______________________________________________ devs mailing list > devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs > >>> > >>> _______________________________________________ > >> devs mailing list devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > >> > > _______________________________________________ devs mailing list > devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list > devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
