Re: [xwiki-devs] [VOTE] XWiki Core - Take 3 (RESULT)
Ok, so more than 72 hours have now elapsed and the VOTE is passed! Results: 7 +1, no 0 and no -1 I’ll update dev.xwiki.org to reflect the fact that the xwiki github organization is now focused on core extensions only and that vertical extensions are to be located in xwiki-contrib. Note that the delimitation is a bit fuzzy and the move requires a VOTE every time so I’ll send another VOTE mail to propose some extensions to move out of platform. Thanks -Vincent On 19 Jan 2016 at 17:17:42, [email protected] ([email protected](mailto:[email protected])) wrote: > > > On 19 Jan 2016 at 12:01:01, Ecaterina Moraru (Valica) > ([email protected](mailto:[email protected])) wrote: > > > +1 > > > > My only comment is that we will start again to have discrepancies between > > applications versions. That's going to be fun :) > > Yes this is my worry too: the compatibilty matrix. The more contrib > extensions we have, the more complex testing and compatibility is. We need to > work on improving user contributions in this domain, directly from inside XE > for example. > > Thanks > -Vincent > > > Thanks, > > Caty > > > > On Tue, Jan 19, 2016 at 11:24 AM, Guillaume "Louis-Marie" Delhumeau < > > [email protected]> wrote: > > > > > +1 > > > > > > Thanks, > > > > > > 2016-01-19 7:06 GMT+01:00 Marius Dumitru Florea < > > > [email protected]>: > > > > > > > +1 > > > > > > > > Thanks, > > > > Marius > > > > > > > > On Mon, Jan 18, 2016 at 6:05 PM, [email protected] > > > > wrote: > > > > > > > > > Hi devs, > > > > > > > > > > Since the first 2 takes did not pas, I’m making a new proposal taking > > > > into > > > > > account the latest comments and making the minimal changes from the > > > > current > > > > > situation to get a consensus. > > > > > > > > > > Issues to solve > > > > > === > > > > > > > > > > * The scope of the code maintained by the XWiki Dev Team (== the xwiki > > > > > github organization) is increasing but the team stays relatively small > > > > > * The more stuff we move into the repos of the xwiki github > > > organization, > > > > > the less easy it is for non-“XWiki Dev Team” committers to participate > > > > and > > > > > we want more contributions > > > > > > > > > > Proposed solution > > > > > = > > > > > > > > > > Executive summary: > > > > > * Reduce the scope of all the code located in the xwiki github > > > > > organization by only keeping “core” modules > > > > > * A “core" module is defined by being a generic transversal module > > > (i.e. > > > > > that can be used in lots of XWiki flavors, if not all). This is > > > > > opposed > > > > to > > > > > “vertical” modules which are modules specific of a usage of XWiki. > > > > > ** Examples of “core" modules: logging module, configuration module, > > > > > distribution wizard, annotations, active installs, one base flavor > > > > > (the > > > > > “XWiki” flavor), etc > > > > > ** Example of “vertical” modules: meeting manager application, blog > > > > > application, FAQ application, flavors (except the base flavor), etc > > > > > > > > > > Some consequences: > > > > > * We need a new location for several modules that would go out of the > > > > > xwiki github organization repos > > > > > * It would be good that extensions that were developed inside the > > > > > xwiki > > > > > github organization continue to follow the dev practices of > > > > > http://dev.xwiki.org > > > > > > > > > > Details: > > > > > * We keep the current github organization names for now, i.e. “xwiki” > > > and > > > > > “xwiki-contrib”. > > > > > * Each extension in xwiki-contrib continues to be an island with a > > > leader > > > > > (defined in jira) and continues to be able to decide what dev > > > > > practices > > > > it > > > > > should follow. The leader continues to be the one to contact when > > > needing > > > > > to perform a release. When the leader goes MIA the next person > > > interested > > > > > in working on the extension can become its new leader. > > > > > * Since extensions moved from the xwiki github organization should > > > > > continue to follow all the practices from http://dev.xwiki.org we > > > need a > > > > > way to indicate this so that code committed against those and PR can > > > > > be > > > > > reviewed in light of these practices. Thus we should encourage > > > extensions > > > > > to have a README file in each repo in xwiki-contrib that defines what > > > > > practices the extension is following. We’ll also update > > > > contrib.xwiki.org with > > > > > explanations about this (both for extension creators and for > > > contributors > > > > > to them). > > > > > * Note that on contrib.xwiki.org we will propose a generic template > > > for > > > > > README files that should exist for all repos in xwiki-contrib. This > > > > > template will include (but not be limited to): Dev practices to > > > > > follow, > > > > > Link to e.x.o, Status of the extension (usef
Re: [xwiki-devs] [VOTE] XWiki Core - Take 3
On 19 Jan 2016 at 12:01:01, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote: > +1 > > My only comment is that we will start again to have discrepancies between > applications versions. That's going to be fun :) Yes this is my worry too: the compatibilty matrix. The more contrib extensions we have, the more complex testing and compatibility is. We need to work on improving user contributions in this domain, directly from inside XE for example. Thanks -Vincent > Thanks, > Caty > > On Tue, Jan 19, 2016 at 11:24 AM, Guillaume "Louis-Marie" Delhumeau < > [email protected]> wrote: > > > +1 > > > > Thanks, > > > > 2016-01-19 7:06 GMT+01:00 Marius Dumitru Florea < > > [email protected]>: > > > > > +1 > > > > > > Thanks, > > > Marius > > > > > > On Mon, Jan 18, 2016 at 6:05 PM, [email protected] > > > wrote: > > > > > > > Hi devs, > > > > > > > > Since the first 2 takes did not pas, I’m making a new proposal taking > > > into > > > > account the latest comments and making the minimal changes from the > > > current > > > > situation to get a consensus. > > > > > > > > Issues to solve > > > > === > > > > > > > > * The scope of the code maintained by the XWiki Dev Team (== the xwiki > > > > github organization) is increasing but the team stays relatively small > > > > * The more stuff we move into the repos of the xwiki github > > organization, > > > > the less easy it is for non-“XWiki Dev Team” committers to participate > > > and > > > > we want more contributions > > > > > > > > Proposed solution > > > > = > > > > > > > > Executive summary: > > > > * Reduce the scope of all the code located in the xwiki github > > > > organization by only keeping “core” modules > > > > * A “core" module is defined by being a generic transversal module > > (i.e. > > > > that can be used in lots of XWiki flavors, if not all). This is opposed > > > to > > > > “vertical” modules which are modules specific of a usage of XWiki. > > > > ** Examples of “core" modules: logging module, configuration module, > > > > distribution wizard, annotations, active installs, one base flavor (the > > > > “XWiki” flavor), etc > > > > ** Example of “vertical” modules: meeting manager application, blog > > > > application, FAQ application, flavors (except the base flavor), etc > > > > > > > > Some consequences: > > > > * We need a new location for several modules that would go out of the > > > > xwiki github organization repos > > > > * It would be good that extensions that were developed inside the xwiki > > > > github organization continue to follow the dev practices of > > > > http://dev.xwiki.org > > > > > > > > Details: > > > > * We keep the current github organization names for now, i.e. “xwiki” > > and > > > > “xwiki-contrib”. > > > > * Each extension in xwiki-contrib continues to be an island with a > > leader > > > > (defined in jira) and continues to be able to decide what dev practices > > > it > > > > should follow. The leader continues to be the one to contact when > > needing > > > > to perform a release. When the leader goes MIA the next person > > interested > > > > in working on the extension can become its new leader. > > > > * Since extensions moved from the xwiki github organization should > > > > continue to follow all the practices from http://dev.xwiki.org we > > need a > > > > way to indicate this so that code committed against those and PR can be > > > > reviewed in light of these practices. Thus we should encourage > > extensions > > > > to have a README file in each repo in xwiki-contrib that defines what > > > > practices the extension is following. We’ll also update > > > contrib.xwiki.org with > > > > explanations about this (both for extension creators and for > > contributors > > > > to them). > > > > * Note that on contrib.xwiki.org we will propose a generic template > > for > > > > README files that should exist for all repos in xwiki-contrib. This > > > > template will include (but not be limited to): Dev practices to follow, > > > > Link to e.x.o, Status of the extension (useful to indicate > > > > non-working/abandoned extensions for example), link to its jira. > > > > * When moving an extension from the xwiki github org to xwiki-contrib, > > > > depending on the moved extension, the extension can keep its id (this > > > > allows the EM upgrade job to propose upgrading it). Whenever possible > > the > > > > extension id should be updated to follow the rules of > > contrib.xwiki.org > > > (group > > > > id of org.xwiki.contrib, artifact id matching the rules). In addition, > > > > since we don’t want to cause API breakages, the java packages can be > > kept > > > > as org.xwiki.* till the next large refactoring of the extension, at > > which > > > > time it should move to org.xwiki.contrib.*. Similarly the version of > > the > > > > moved extension should be kept and not be reset to 1.0-SNAPSHOT. We can > > > > probably develop
Re: [xwiki-devs] [VOTE] XWiki Core - Take 3
+1 My only comment is that we will start again to have discrepancies between applications versions. That's going to be fun :) Thanks, Caty On Tue, Jan 19, 2016 at 11:24 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote: > +1 > > Thanks, > > 2016-01-19 7:06 GMT+01:00 Marius Dumitru Florea < > [email protected]>: > > > +1 > > > > Thanks, > > Marius > > > > On Mon, Jan 18, 2016 at 6:05 PM, [email protected] > > wrote: > > > > > Hi devs, > > > > > > Since the first 2 takes did not pas, I’m making a new proposal taking > > into > > > account the latest comments and making the minimal changes from the > > current > > > situation to get a consensus. > > > > > > Issues to solve > > > === > > > > > > * The scope of the code maintained by the XWiki Dev Team (== the xwiki > > > github organization) is increasing but the team stays relatively small > > > * The more stuff we move into the repos of the xwiki github > organization, > > > the less easy it is for non-“XWiki Dev Team” committers to participate > > and > > > we want more contributions > > > > > > Proposed solution > > > = > > > > > > Executive summary: > > > * Reduce the scope of all the code located in the xwiki github > > > organization by only keeping “core” modules > > > * A “core" module is defined by being a generic transversal module > (i.e. > > > that can be used in lots of XWiki flavors, if not all). This is opposed > > to > > > “vertical” modules which are modules specific of a usage of XWiki. > > > ** Examples of “core" modules: logging module, configuration module, > > > distribution wizard, annotations, active installs, one base flavor (the > > > “XWiki” flavor), etc > > > ** Example of “vertical” modules: meeting manager application, blog > > > application, FAQ application, flavors (except the base flavor), etc > > > > > > Some consequences: > > > * We need a new location for several modules that would go out of the > > > xwiki github organization repos > > > * It would be good that extensions that were developed inside the xwiki > > > github organization continue to follow the dev practices of > > > http://dev.xwiki.org > > > > > > Details: > > > * We keep the current github organization names for now, i.e. “xwiki” > and > > > “xwiki-contrib”. > > > * Each extension in xwiki-contrib continues to be an island with a > leader > > > (defined in jira) and continues to be able to decide what dev practices > > it > > > should follow. The leader continues to be the one to contact when > needing > > > to perform a release. When the leader goes MIA the next person > interested > > > in working on the extension can become its new leader. > > > * Since extensions moved from the xwiki github organization should > > > continue to follow all the practices from http://dev.xwiki.org we > need a > > > way to indicate this so that code committed against those and PR can be > > > reviewed in light of these practices. Thus we should encourage > extensions > > > to have a README file in each repo in xwiki-contrib that defines what > > > practices the extension is following. We’ll also update > > contrib.xwiki.org with > > > explanations about this (both for extension creators and for > contributors > > > to them). > > > * Note that on contrib.xwiki.org we will propose a generic template > for > > > README files that should exist for all repos in xwiki-contrib. This > > > template will include (but not be limited to): Dev practices to follow, > > > Link to e.x.o, Status of the extension (useful to indicate > > > non-working/abandoned extensions for example), link to its jira. > > > * When moving an extension from the xwiki github org to xwiki-contrib, > > > depending on the moved extension, the extension can keep its id (this > > > allows the EM upgrade job to propose upgrading it). Whenever possible > the > > > extension id should be updated to follow the rules of > contrib.xwiki.org > > (group > > > id of org.xwiki.contrib, artifact id matching the rules). In addition, > > > since we don’t want to cause API breakages, the java packages can be > kept > > > as org.xwiki.* till the next large refactoring of the extension, at > which > > > time it should move to org.xwiki.contrib.*. Similarly the version of > the > > > moved extension should be kept and not be reset to 1.0-SNAPSHOT. We can > > > probably develop some EM tooling in the future to handle relocation of > > > extension id transparently. > > > > > > Please cast your vote. > > > > > > Here’s my +1 > > > > > > Thanks > > > -Vincent > > > > > > PS: The previous 2 takes were proposal but I’m making it a VOTE now > > > because I believe the “XWiki Core” strategy is important enough so that > > we > > > need to be sure that committers agree (based on our voting rules). > > > > > > On 2 Aug 2015 at 19:43:18, [email protected] ([email protected] > > (mailto: > > > [email protected])) wrote: > > > > > > > Hi, > > > > > > > > I’d like to progress wi
Re: [xwiki-devs] [VOTE] XWiki Core - Take 3
+1 Thanks, 2016-01-19 7:06 GMT+01:00 Marius Dumitru Florea < [email protected]>: > +1 > > Thanks, > Marius > > On Mon, Jan 18, 2016 at 6:05 PM, [email protected] > wrote: > > > Hi devs, > > > > Since the first 2 takes did not pas, I’m making a new proposal taking > into > > account the latest comments and making the minimal changes from the > current > > situation to get a consensus. > > > > Issues to solve > > === > > > > * The scope of the code maintained by the XWiki Dev Team (== the xwiki > > github organization) is increasing but the team stays relatively small > > * The more stuff we move into the repos of the xwiki github organization, > > the less easy it is for non-“XWiki Dev Team” committers to participate > and > > we want more contributions > > > > Proposed solution > > = > > > > Executive summary: > > * Reduce the scope of all the code located in the xwiki github > > organization by only keeping “core” modules > > * A “core" module is defined by being a generic transversal module (i.e. > > that can be used in lots of XWiki flavors, if not all). This is opposed > to > > “vertical” modules which are modules specific of a usage of XWiki. > > ** Examples of “core" modules: logging module, configuration module, > > distribution wizard, annotations, active installs, one base flavor (the > > “XWiki” flavor), etc > > ** Example of “vertical” modules: meeting manager application, blog > > application, FAQ application, flavors (except the base flavor), etc > > > > Some consequences: > > * We need a new location for several modules that would go out of the > > xwiki github organization repos > > * It would be good that extensions that were developed inside the xwiki > > github organization continue to follow the dev practices of > > http://dev.xwiki.org > > > > Details: > > * We keep the current github organization names for now, i.e. “xwiki” and > > “xwiki-contrib”. > > * Each extension in xwiki-contrib continues to be an island with a leader > > (defined in jira) and continues to be able to decide what dev practices > it > > should follow. The leader continues to be the one to contact when needing > > to perform a release. When the leader goes MIA the next person interested > > in working on the extension can become its new leader. > > * Since extensions moved from the xwiki github organization should > > continue to follow all the practices from http://dev.xwiki.org we need a > > way to indicate this so that code committed against those and PR can be > > reviewed in light of these practices. Thus we should encourage extensions > > to have a README file in each repo in xwiki-contrib that defines what > > practices the extension is following. We’ll also update > contrib.xwiki.org with > > explanations about this (both for extension creators and for contributors > > to them). > > * Note that on contrib.xwiki.org we will propose a generic template for > > README files that should exist for all repos in xwiki-contrib. This > > template will include (but not be limited to): Dev practices to follow, > > Link to e.x.o, Status of the extension (useful to indicate > > non-working/abandoned extensions for example), link to its jira. > > * When moving an extension from the xwiki github org to xwiki-contrib, > > depending on the moved extension, the extension can keep its id (this > > allows the EM upgrade job to propose upgrading it). Whenever possible the > > extension id should be updated to follow the rules of contrib.xwiki.org > (group > > id of org.xwiki.contrib, artifact id matching the rules). In addition, > > since we don’t want to cause API breakages, the java packages can be kept > > as org.xwiki.* till the next large refactoring of the extension, at which > > time it should move to org.xwiki.contrib.*. Similarly the version of the > > moved extension should be kept and not be reset to 1.0-SNAPSHOT. We can > > probably develop some EM tooling in the future to handle relocation of > > extension id transparently. > > > > Please cast your vote. > > > > Here’s my +1 > > > > Thanks > > -Vincent > > > > PS: The previous 2 takes were proposal but I’m making it a VOTE now > > because I believe the “XWiki Core” strategy is important enough so that > we > > need to be sure that committers agree (based on our voting rules). > > > > On 2 Aug 2015 at 19:43:18, [email protected] ([email protected] > (mailto: > > [email protected])) wrote: > > > > > Hi, > > > > > > I’d like to progress with this idea so let me summarize this thread’s > > discussion so far: > > > > > > * +1 from Thomas, Guillaume, Caty and Marius > > > * No answer from Edy on whether he’s ok with the proposal or not. Edy? > :) > > > * Denis seems negative about it but I agree with Thomas’s reply in that > > the points raised by Denis do not concern this discussion. Denis > commented > > about publishing and installing Extensions, whereas this proposal was > only > > about a location for storing some exte
Re: [xwiki-devs] [VOTE] XWiki Core - Take 3
+1 Thanks, Marius On Mon, Jan 18, 2016 at 6:05 PM, [email protected] wrote: > Hi devs, > > Since the first 2 takes did not pas, I’m making a new proposal taking into > account the latest comments and making the minimal changes from the current > situation to get a consensus. > > Issues to solve > === > > * The scope of the code maintained by the XWiki Dev Team (== the xwiki > github organization) is increasing but the team stays relatively small > * The more stuff we move into the repos of the xwiki github organization, > the less easy it is for non-“XWiki Dev Team” committers to participate and > we want more contributions > > Proposed solution > = > > Executive summary: > * Reduce the scope of all the code located in the xwiki github > organization by only keeping “core” modules > * A “core" module is defined by being a generic transversal module (i.e. > that can be used in lots of XWiki flavors, if not all). This is opposed to > “vertical” modules which are modules specific of a usage of XWiki. > ** Examples of “core" modules: logging module, configuration module, > distribution wizard, annotations, active installs, one base flavor (the > “XWiki” flavor), etc > ** Example of “vertical” modules: meeting manager application, blog > application, FAQ application, flavors (except the base flavor), etc > > Some consequences: > * We need a new location for several modules that would go out of the > xwiki github organization repos > * It would be good that extensions that were developed inside the xwiki > github organization continue to follow the dev practices of > http://dev.xwiki.org > > Details: > * We keep the current github organization names for now, i.e. “xwiki” and > “xwiki-contrib”. > * Each extension in xwiki-contrib continues to be an island with a leader > (defined in jira) and continues to be able to decide what dev practices it > should follow. The leader continues to be the one to contact when needing > to perform a release. When the leader goes MIA the next person interested > in working on the extension can become its new leader. > * Since extensions moved from the xwiki github organization should > continue to follow all the practices from http://dev.xwiki.org we need a > way to indicate this so that code committed against those and PR can be > reviewed in light of these practices. Thus we should encourage extensions > to have a README file in each repo in xwiki-contrib that defines what > practices the extension is following. We’ll also update contrib.xwiki.org with > explanations about this (both for extension creators and for contributors > to them). > * Note that on contrib.xwiki.org we will propose a generic template for > README files that should exist for all repos in xwiki-contrib. This > template will include (but not be limited to): Dev practices to follow, > Link to e.x.o, Status of the extension (useful to indicate > non-working/abandoned extensions for example), link to its jira. > * When moving an extension from the xwiki github org to xwiki-contrib, > depending on the moved extension, the extension can keep its id (this > allows the EM upgrade job to propose upgrading it). Whenever possible the > extension id should be updated to follow the rules of contrib.xwiki.org (group > id of org.xwiki.contrib, artifact id matching the rules). In addition, > since we don’t want to cause API breakages, the java packages can be kept > as org.xwiki.* till the next large refactoring of the extension, at which > time it should move to org.xwiki.contrib.*. Similarly the version of the > moved extension should be kept and not be reset to 1.0-SNAPSHOT. We can > probably develop some EM tooling in the future to handle relocation of > extension id transparently. > > Please cast your vote. > > Here’s my +1 > > Thanks > -Vincent > > PS: The previous 2 takes were proposal but I’m making it a VOTE now > because I believe the “XWiki Core” strategy is important enough so that we > need to be sure that committers agree (based on our voting rules). > > On 2 Aug 2015 at 19:43:18, [email protected] ([email protected](mailto: > [email protected])) wrote: > > > Hi, > > > > I’d like to progress with this idea so let me summarize this thread’s > discussion so far: > > > > * +1 from Thomas, Guillaume, Caty and Marius > > * No answer from Edy on whether he’s ok with the proposal or not. Edy? :) > > * Denis seems negative about it but I agree with Thomas’s reply in that > the points raised by Denis do not concern this discussion. Denis commented > about publishing and installing Extensions, whereas this proposal was only > about a location for storing some extensions. Extensions can be developed > anywhere and don’t have to go into this new proposed location. Denis, could > you please review this new proposal with this in mind? > > * There were discussions about the name and devs express doubts about > using xwiki-contrib-sandbox. > > > > I’d like to progress so here’s my second
Re: [xwiki-devs] [VOTE] XWiki Core - Take 3
+1 Thanks, Eduard On Mon, Jan 18, 2016 at 9:37 PM, Denis Gervalle wrote: > +1, sounds good to me too :) > > On Mon, Jan 18, 2016 at 5:05 PM, [email protected] > wrote: > > > Hi devs, > > > > Since the first 2 takes did not pas, I’m making a new proposal taking > into > > account the latest comments and making the minimal changes from the > current > > situation to get a consensus. > > > > Issues to solve > > === > > > > * The scope of the code maintained by the XWiki Dev Team (== the xwiki > > github organization) is increasing but the team stays relatively small > > * The more stuff we move into the repos of the xwiki github organization, > > the less easy it is for non-“XWiki Dev Team” committers to participate > and > > we want more contributions > > > > Proposed solution > > = > > > > Executive summary: > > * Reduce the scope of all the code located in the xwiki github > > organization by only keeping “core” modules > > * A “core" module is defined by being a generic transversal module (i.e. > > that can be used in lots of XWiki flavors, if not all). This is opposed > to > > “vertical” modules which are modules specific of a usage of XWiki. > > ** Examples of “core" modules: logging module, configuration module, > > distribution wizard, annotations, active installs, one base flavor (the > > “XWiki” flavor), etc > > ** Example of “vertical” modules: meeting manager application, blog > > application, FAQ application, flavors (except the base flavor), etc > > > > Some consequences: > > * We need a new location for several modules that would go out of the > > xwiki github organization repos > > * It would be good that extensions that were developed inside the xwiki > > github organization continue to follow the dev practices of > > http://dev.xwiki.org > > > > Details: > > * We keep the current github organization names for now, i.e. “xwiki” and > > “xwiki-contrib”. > > * Each extension in xwiki-contrib continues to be an island with a leader > > (defined in jira) and continues to be able to decide what dev practices > it > > should follow. The leader continues to be the one to contact when needing > > to perform a release. When the leader goes MIA the next person interested > > in working on the extension can become its new leader. > > * Since extensions moved from the xwiki github organization should > > continue to follow all the practices from http://dev.xwiki.org we need a > > way to indicate this so that code committed against those and PR can be > > reviewed in light of these practices. Thus we should encourage extensions > > to have a README file in each repo in xwiki-contrib that defines what > > practices the extension is following. We’ll also update > contrib.xwiki.org with > > explanations about this (both for extension creators and for contributors > > to them). > > > > Do not forget that you can enforce a lot of practice by defining > constraints in the extension pom for extension in Java, like checkstyles, > etc… which also enforce the quality of coding. Of course this does not > cover everything, but the owner of the repository will surely also check > and review committed code to keep the quality of the extension to a good > level. I am not really afraid by this point, I have already some contrib > extension that follow platform rules, and I have never seen any degradation > yet. > > > > * Note that on contrib.xwiki.org we will propose a generic template for > > README files that should exist for all repos in xwiki-contrib. This > > template will include (but not be limited to): Dev practices to follow, > > Link to e.x.o, Status of the extension (useful to indicate > > non-working/abandoned extensions for example), link to its jira. > > * When moving an extension from the xwiki github org to xwiki-contrib, > > depending on the moved extension, the extension can keep its id (this > > allows the EM upgrade job to propose upgrading it). Whenever possible the > > extension id should be updated to follow the rules of contrib.xwiki.org > (group > > id of org.xwiki.contrib, artifact id matching the rules). In addition, > > since we don’t want to cause API breakages, the java packages can be kept > > as org.xwiki.* till the next large refactoring of the extension, at which > > time it should move to org.xwiki.contrib.*. Similarly the version of the > > moved extension should be kept and not be reset to 1.0-SNAPSHOT. We can > > probably develop some EM tooling in the future to handle relocation of > > extension id transparently. > > > > Please cast your vote. > > > > Here’s my +1 > > > > Thanks > > -Vincent > > > > PS: The previous 2 takes were proposal but I’m making it a VOTE now > > because I believe the “XWiki Core” strategy is important enough so that > we > > need to be sure that committers agree (based on our voting rules). > > > > On 2 Aug 2015 at 19:43:18, [email protected] ([email protected] > (mailto: > > [email protected])) wrote: > > > > > Hi, > > >
Re: [xwiki-devs] [VOTE] XWiki Core - Take 3
+1, sounds good to me too :) On Mon, Jan 18, 2016 at 5:05 PM, [email protected] wrote: > Hi devs, > > Since the first 2 takes did not pas, I’m making a new proposal taking into > account the latest comments and making the minimal changes from the current > situation to get a consensus. > > Issues to solve > === > > * The scope of the code maintained by the XWiki Dev Team (== the xwiki > github organization) is increasing but the team stays relatively small > * The more stuff we move into the repos of the xwiki github organization, > the less easy it is for non-“XWiki Dev Team” committers to participate and > we want more contributions > > Proposed solution > = > > Executive summary: > * Reduce the scope of all the code located in the xwiki github > organization by only keeping “core” modules > * A “core" module is defined by being a generic transversal module (i.e. > that can be used in lots of XWiki flavors, if not all). This is opposed to > “vertical” modules which are modules specific of a usage of XWiki. > ** Examples of “core" modules: logging module, configuration module, > distribution wizard, annotations, active installs, one base flavor (the > “XWiki” flavor), etc > ** Example of “vertical” modules: meeting manager application, blog > application, FAQ application, flavors (except the base flavor), etc > > Some consequences: > * We need a new location for several modules that would go out of the > xwiki github organization repos > * It would be good that extensions that were developed inside the xwiki > github organization continue to follow the dev practices of > http://dev.xwiki.org > > Details: > * We keep the current github organization names for now, i.e. “xwiki” and > “xwiki-contrib”. > * Each extension in xwiki-contrib continues to be an island with a leader > (defined in jira) and continues to be able to decide what dev practices it > should follow. The leader continues to be the one to contact when needing > to perform a release. When the leader goes MIA the next person interested > in working on the extension can become its new leader. > * Since extensions moved from the xwiki github organization should > continue to follow all the practices from http://dev.xwiki.org we need a > way to indicate this so that code committed against those and PR can be > reviewed in light of these practices. Thus we should encourage extensions > to have a README file in each repo in xwiki-contrib that defines what > practices the extension is following. We’ll also update contrib.xwiki.org with > explanations about this (both for extension creators and for contributors > to them). > Do not forget that you can enforce a lot of practice by defining constraints in the extension pom for extension in Java, like checkstyles, etc… which also enforce the quality of coding. Of course this does not cover everything, but the owner of the repository will surely also check and review committed code to keep the quality of the extension to a good level. I am not really afraid by this point, I have already some contrib extension that follow platform rules, and I have never seen any degradation yet. > * Note that on contrib.xwiki.org we will propose a generic template for > README files that should exist for all repos in xwiki-contrib. This > template will include (but not be limited to): Dev practices to follow, > Link to e.x.o, Status of the extension (useful to indicate > non-working/abandoned extensions for example), link to its jira. > * When moving an extension from the xwiki github org to xwiki-contrib, > depending on the moved extension, the extension can keep its id (this > allows the EM upgrade job to propose upgrading it). Whenever possible the > extension id should be updated to follow the rules of contrib.xwiki.org (group > id of org.xwiki.contrib, artifact id matching the rules). In addition, > since we don’t want to cause API breakages, the java packages can be kept > as org.xwiki.* till the next large refactoring of the extension, at which > time it should move to org.xwiki.contrib.*. Similarly the version of the > moved extension should be kept and not be reset to 1.0-SNAPSHOT. We can > probably develop some EM tooling in the future to handle relocation of > extension id transparently. > > Please cast your vote. > > Here’s my +1 > > Thanks > -Vincent > > PS: The previous 2 takes were proposal but I’m making it a VOTE now > because I believe the “XWiki Core” strategy is important enough so that we > need to be sure that committers agree (based on our voting rules). > > On 2 Aug 2015 at 19:43:18, [email protected] ([email protected](mailto: > [email protected])) wrote: > > > Hi, > > > > I’d like to progress with this idea so let me summarize this thread’s > discussion so far: > > > > * +1 from Thomas, Guillaume, Caty and Marius > > * No answer from Edy on whether he’s ok with the proposal or not. Edy? :) > > * Denis seems negative about it but I agree with Thomas’s reply in
Re: [xwiki-devs] [VOTE] XWiki Core - Take 3
Looks good, +1. On Mon, Jan 18, 2016 at 5:05 PM, [email protected] wrote: > Hi devs, > > Since the first 2 takes did not pas, I’m making a new proposal taking into > account the latest comments and making the minimal changes from the current > situation to get a consensus. > > Issues to solve > === > > * The scope of the code maintained by the XWiki Dev Team (== the xwiki github > organization) is increasing but the team stays relatively small > * The more stuff we move into the repos of the xwiki github organization, the > less easy it is for non-“XWiki Dev Team” committers to participate and we > want more contributions > > Proposed solution > = > > Executive summary: > * Reduce the scope of all the code located in the xwiki github organization > by only keeping “core” modules > * A “core" module is defined by being a generic transversal module (i.e. that > can be used in lots of XWiki flavors, if not all). This is opposed to > “vertical” modules which are modules specific of a usage of XWiki. > ** Examples of “core" modules: logging module, configuration module, > distribution wizard, annotations, active installs, one base flavor (the > “XWiki” flavor), etc > ** Example of “vertical” modules: meeting manager application, blog > application, FAQ application, flavors (except the base flavor), etc > > Some consequences: > * We need a new location for several modules that would go out of the xwiki > github organization repos > * It would be good that extensions that were developed inside the xwiki > github organization continue to follow the dev practices of > http://dev.xwiki.org > > Details: > * We keep the current github organization names for now, i.e. “xwiki” and > “xwiki-contrib”. > * Each extension in xwiki-contrib continues to be an island with a leader > (defined in jira) and continues to be able to decide what dev practices it > should follow. The leader continues to be the one to contact when needing to > perform a release. When the leader goes MIA the next person interested in > working on the extension can become its new leader. > * Since extensions moved from the xwiki github organization should continue > to follow all the practices from http://dev.xwiki.org we need a way to > indicate this so that code committed against those and PR can be reviewed in > light of these practices. Thus we should encourage extensions to have a > README file in each repo in xwiki-contrib that defines what practices the > extension is following. We’ll also update contrib.xwiki.org with explanations > about this (both for extension creators and for contributors to them). > * Note that on contrib.xwiki.org we will propose a generic template for > README files that should exist for all repos in xwiki-contrib. This template > will include (but not be limited to): Dev practices to follow, Link to e.x.o, > Status of the extension (useful to indicate non-working/abandoned extensions > for example), link to its jira. > * When moving an extension from the xwiki github org to xwiki-contrib, > depending on the moved extension, the extension can keep its id (this allows > the EM upgrade job to propose upgrading it). Whenever possible the extension > id should be updated to follow the rules of contrib.xwiki.org (group id of > org.xwiki.contrib, artifact id matching the rules). In addition, since we > don’t want to cause API breakages, the java packages can be kept as > org.xwiki.* till the next large refactoring of the extension, at which time > it should move to org.xwiki.contrib.*. Similarly the version of the moved > extension should be kept and not be reset to 1.0-SNAPSHOT. We can probably > develop some EM tooling in the future to handle relocation of extension id > transparently. For now it's safer to allow keeping the same id but here are some reading about extensions upgrades and ids modifications: * Maven provide some relocation system (basically you release a new version of the old id which will be used as redirect to the new one) but need to test how well EM supports it * Right now we deal with previous id by listing them as features but feature can also be used for other things like indicating embedded extensions or actual features/API implemented by several implementations that can't be installed at the same time. We would probably need to make it more explicit what was a previous id of the extension in a different property so that we can safely search for it in extensions.xwiki.org * By default upgrade manager only search for extensions explicitly installed by user (so not installed as dependency) so extensions installed as XE dependencies for example are not checked anyway > > Please cast your vote. > > Here’s my +1 > > Thanks > -Vincent > > PS: The previous 2 takes were proposal but I’m making it a VOTE now because I > believe the “XWiki Core” strategy is important enough so that we need to be > sure that committers agree (based on our
[xwiki-devs] [VOTE] XWiki Core - Take 3
Hi devs, Since the first 2 takes did not pas, I’m making a new proposal taking into account the latest comments and making the minimal changes from the current situation to get a consensus. Issues to solve === * The scope of the code maintained by the XWiki Dev Team (== the xwiki github organization) is increasing but the team stays relatively small * The more stuff we move into the repos of the xwiki github organization, the less easy it is for non-“XWiki Dev Team” committers to participate and we want more contributions Proposed solution = Executive summary: * Reduce the scope of all the code located in the xwiki github organization by only keeping “core” modules * A “core" module is defined by being a generic transversal module (i.e. that can be used in lots of XWiki flavors, if not all). This is opposed to “vertical” modules which are modules specific of a usage of XWiki. ** Examples of “core" modules: logging module, configuration module, distribution wizard, annotations, active installs, one base flavor (the “XWiki” flavor), etc ** Example of “vertical” modules: meeting manager application, blog application, FAQ application, flavors (except the base flavor), etc Some consequences: * We need a new location for several modules that would go out of the xwiki github organization repos * It would be good that extensions that were developed inside the xwiki github organization continue to follow the dev practices of http://dev.xwiki.org Details: * We keep the current github organization names for now, i.e. “xwiki” and “xwiki-contrib”. * Each extension in xwiki-contrib continues to be an island with a leader (defined in jira) and continues to be able to decide what dev practices it should follow. The leader continues to be the one to contact when needing to perform a release. When the leader goes MIA the next person interested in working on the extension can become its new leader. * Since extensions moved from the xwiki github organization should continue to follow all the practices from http://dev.xwiki.org we need a way to indicate this so that code committed against those and PR can be reviewed in light of these practices. Thus we should encourage extensions to have a README file in each repo in xwiki-contrib that defines what practices the extension is following. We’ll also update contrib.xwiki.org with explanations about this (both for extension creators and for contributors to them). * Note that on contrib.xwiki.org we will propose a generic template for README files that should exist for all repos in xwiki-contrib. This template will include (but not be limited to): Dev practices to follow, Link to e.x.o, Status of the extension (useful to indicate non-working/abandoned extensions for example), link to its jira. * When moving an extension from the xwiki github org to xwiki-contrib, depending on the moved extension, the extension can keep its id (this allows the EM upgrade job to propose upgrading it). Whenever possible the extension id should be updated to follow the rules of contrib.xwiki.org (group id of org.xwiki.contrib, artifact id matching the rules). In addition, since we don’t want to cause API breakages, the java packages can be kept as org.xwiki.* till the next large refactoring of the extension, at which time it should move to org.xwiki.contrib.*. Similarly the version of the moved extension should be kept and not be reset to 1.0-SNAPSHOT. We can probably develop some EM tooling in the future to handle relocation of extension id transparently. Please cast your vote. Here’s my +1 Thanks -Vincent PS: The previous 2 takes were proposal but I’m making it a VOTE now because I believe the “XWiki Core” strategy is important enough so that we need to be sure that committers agree (based on our voting rules). On 2 Aug 2015 at 19:43:18, [email protected] ([email protected](mailto:[email protected])) wrote: > Hi, > > I’d like to progress with this idea so let me summarize this thread’s > discussion so far: > > * +1 from Thomas, Guillaume, Caty and Marius > * No answer from Edy on whether he’s ok with the proposal or not. Edy? :) > * Denis seems negative about it but I agree with Thomas’s reply in that the > points raised by Denis do not concern this discussion. Denis commented about > publishing and installing Extensions, whereas this proposal was only about a > location for storing some extensions. Extensions can be developed anywhere > and don’t have to go into this new proposed location. Denis, could you please > review this new proposal with this in mind? > * There were discussions about the name and devs express doubts about using > xwiki-contrib-sandbox. > > I’d like to progress so here’s my second proposal. It differs from the first > proposal on the following points: > > * All our code is contributed so I don’t think we need to emphasize this > point and I don’t think we need to have “contrib”
