Policy on plugins maintenance
Locked
Policy on plugins maintenance
 
Administrator
|
Hi,
In recent discussions I wrote <<I believe committers need now to agree about checking out all plugins and maintaining them as we did before. This must be documented in our policies.>> in <<[DISCUSSION] Plugins: svn:external or Gradle Task?)>> thread <<It seems to me that if a committer, committing something on the framework, breaks a plugins s/he is also responsible of fixing the plugins issue.>> in <<[proposal] actions to take with plugins>> thread but got no attention so far. Beside the last pending technical aspects defined in the <<[DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk>> http://markmail.org/message/6r4qnuu5v2c2aes2 6. Investigate how to create a plugin repository with dependencies clearly defined, not only on external libraries but also other plugins! 7. Investigate and propose a methodology for maintaining plugins and versioning compatibility with OFBiz. 8. Investigate and propose a methodology for upgrading plugins within OFBiz I think we need to agree, not at a technical but political level, about how the plugins will be maintained, IMO not as second-class citizens! This is a very important topic because with the trunk split it's already there and the plugins could suffer from the split. Thanks Jacques |
Re: Policy on plugins maintenance
|
Administrator
|
To sum up and as a kind of TL;DR, the question is <<should we "force" the committers to maintain the plugins?>>
Jacques Le 14/03/2017 à 08:17, Jacques Le Roux a écrit : > Hi, > > In recent discussions I wrote > > <<I believe committers need now to agree about checking out all plugins and maintaining them as we did before. This must be documented in our > policies.>> in <<[DISCUSSION] Plugins: svn:external or Gradle Task?)>> thread > > <<It seems to me that if a committer, committing something on the framework, breaks a plugins s/he is also responsible of fixing the plugins > issue.>> in <<[proposal] actions to take with plugins>> thread > > but got no attention so far. > > Beside the last pending technical aspects defined in the <<[DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk>> > http://markmail.org/message/6r4qnuu5v2c2aes2 > > 6. Investigate how to create a plugin repository with dependencies clearly defined, not only on external libraries but also other plugins! > 7. Investigate and propose a methodology for maintaining plugins and versioning compatibility with OFBiz. > 8. Investigate and propose a methodology for upgrading plugins within OFBiz > > I think we need to agree, not at a technical but political level, about how the plugins will be maintained, IMO not as second-class citizens! > This is a very important topic because with the trunk split it's already there and the plugins could suffer from the split. > > Thanks > > Jacques > > > |
Re: Policy on plugins maintenance
|
Administrator
|
Hi,
Without any reactions, and because I believe this is important I'll start a vote If I get no attention at all, I'll consider this is a lazy consensus and will enforce this rule in the committers page in wiki Thanks Jacques Le 14/03/2017 à 08:25, Jacques Le Roux a écrit : > To sum up and as a kind of TL;DR, the question is <<should we "force" the committers to maintain the plugins?>> > > Jacques > > > Le 14/03/2017 à 08:17, Jacques Le Roux a écrit : >> Hi, >> >> In recent discussions I wrote >> >> <<I believe committers need now to agree about checking out all plugins and maintaining them as we did before. This must be documented in our >> policies.>> in <<[DISCUSSION] Plugins: svn:external or Gradle Task?)>> thread >> >> <<It seems to me that if a committer, committing something on the framework, breaks a plugins s/he is also responsible of fixing the plugins >> issue.>> in <<[proposal] actions to take with plugins>> thread >> >> but got no attention so far. >> >> Beside the last pending technical aspects defined in the <<[DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk>> >> http://markmail.org/message/6r4qnuu5v2c2aes2 >> >> 6. Investigate how to create a plugin repository with dependencies clearly defined, not only on external libraries but also other plugins! >> 7. Investigate and propose a methodology for maintaining plugins and versioning compatibility with OFBiz. >> 8. Investigate and propose a methodology for upgrading plugins within OFBiz >> >> I think we need to agree, not at a technical but political level, about how the plugins will be maintained, IMO not as second-class citizens! >> This is a very important topic because with the trunk split it's already there and the plugins could suffer from the split. >> >> Thanks >> >> Jacques >> >> >> > > |
Re: Policy on plugins maintenance
|
Administrator
|
Mmm, I realise my last message is ambiguous.
I mean, should I start a vote? Without any answers I'll assume it's a lazy consensus Thanks Jacques Le 12/04/2017 à 08:24, Jacques Le Roux a écrit : > Hi, > > Without any reactions, and because I believe this is important I'll start a vote > > If I get no attention at all, I'll consider this is a lazy consensus and will enforce this rule in the committers page in wiki > > Thanks > > Jacques > > > Le 14/03/2017 à 08:25, Jacques Le Roux a écrit : >> To sum up and as a kind of TL;DR, the question is <<should we "force" the committers to maintain the plugins?>> >> >> Jacques >> >> >> Le 14/03/2017 à 08:17, Jacques Le Roux a écrit : >>> Hi, >>> >>> In recent discussions I wrote >>> >>> <<I believe committers need now to agree about checking out all plugins and maintaining them as we did before. This must be documented in our >>> policies.>> in <<[DISCUSSION] Plugins: svn:external or Gradle Task?)>> thread >>> >>> <<It seems to me that if a committer, committing something on the framework, breaks a plugins s/he is also responsible of fixing the plugins >>> issue.>> in <<[proposal] actions to take with plugins>> thread >>> >>> but got no attention so far. >>> >>> Beside the last pending technical aspects defined in the <<[DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk>> >>> http://markmail.org/message/6r4qnuu5v2c2aes2 >>> >>> 6. Investigate how to create a plugin repository with dependencies clearly defined, not only on external libraries but also other plugins! >>> 7. Investigate and propose a methodology for maintaining plugins and versioning compatibility with OFBiz. >>> 8. Investigate and propose a methodology for upgrading plugins within OFBiz >>> >>> I think we need to agree, not at a technical but political level, about how the plugins will be maintained, IMO not as second-class citizens! >>> This is a very important topic because with the trunk split it's already there and the plugins could suffer from the split. >>> >>> Thanks >>> >>> Jacques >>> >>> >>> >> >> > > |
Re: Policy on plugins maintenance
|
In reply to this post by Jacques Le Roux
On Tue, Mar 14, 2017 at 8:17 AM, Jacques Le Roux <
[hidden email]> wrote: > [...] 7. Investigate and propose a methodology for maintaining plugins and > versioning compatibility with OFBiz. > I think the easiest way to implement for now is to maintain one trunk for both (ofbiz-framework/trunk and ofbiz-plugins/trunk) and one for each release branch for both (e.g. ofbiz-framework/branches/release17.12 and ofbiz-plugins/branches/release17.12) and then maintain compatibility between the same branches (and trunks). Jacopo |
|
In reply to this post by Jacques Le Roux
I think starting any vote right now might be a little premature. I list
below what I propose as the logical sequence of steps to take: - Create a maven repo for OFBiz plugins - Update the plugins API to be able to pull and push to that repo - Allow contributors some time to get familiar, fix bugs, and improve the workflow for plugins - Separate the builds for the plugins from the builds for the framework and fix all dependency problems (from framework to plugins) - Start a thread to discuss the release strategy once all the technical issues of the plugin system are completed. This would include things like versioning the plugins, releasing them, where to place them on the website, how to update them, etc. This is a rather complex topic that requires further discussion. For example, we release all plugins but the plugin system allows installing individual plugins. So we might need two releases, one for all plugins in a compressed archive, and another one in the maven repository. So I would suggest not to rush this before we test and fully understand how the plugin system will work which is going to enforce how we can do things anyway. Cheers, Taher Alkhateeb On Wed, Apr 12, 2017 at 9:42 AM, Jacques Le Roux < [hidden email]> wrote: > Mmm, I realise my last message is ambiguous. > > I mean, should I start a vote? > > Without any answers I'll assume it's a lazy consensus > > Thanks > > Jacques > > > > Le 12/04/2017 à 08:24, Jacques Le Roux a écrit : > >> Hi, >> >> Without any reactions, and because I believe this is important I'll start >> a vote >> >> If I get no attention at all, I'll consider this is a lazy consensus and >> will enforce this rule in the committers page in wiki >> >> Thanks >> >> Jacques >> >> >> Le 14/03/2017 à 08:25, Jacques Le Roux a écrit : >> >>> To sum up and as a kind of TL;DR, the question is <<should we "force" >>> the committers to maintain the plugins?>> >>> >>> Jacques >>> >>> >>> Le 14/03/2017 à 08:17, Jacques Le Roux a écrit : >>> >>>> Hi, >>>> >>>> In recent discussions I wrote >>>> >>>> <<I believe committers need now to agree about checking out all plugins >>>> and maintaining them as we did before. This must be documented in our >>>> policies.>> in <<[DISCUSSION] Plugins: svn:external or Gradle Task?)>> >>>> thread >>>> >>>> <<It seems to me that if a committer, committing something on the >>>> framework, breaks a plugins s/he is also responsible of fixing the plugins >>>> issue.>> in <<[proposal] actions to take with plugins>> thread >>>> >>>> but got no attention so far. >>>> >>>> Beside the last pending technical aspects defined in the <<[DISCUSSION] >>>> Proposed Task List for Moving Forward with Gradle and the Trunk>> >>>> http://markmail.org/message/6r4qnuu5v2c2aes2 >>>> >>>> 6. Investigate how to create a plugin repository with dependencies >>>> clearly defined, not only on external libraries but also other plugins! >>>> 7. Investigate and propose a methodology for maintaining plugins and >>>> versioning compatibility with OFBiz. >>>> 8. Investigate and propose a methodology for upgrading plugins within >>>> OFBiz >>>> >>>> I think we need to agree, not at a technical but political level, about >>>> how the plugins will be maintained, IMO not as second-class citizens! >>>> This is a very important topic because with the trunk split it's >>>> already there and the plugins could suffer from the split. >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> >>>> >>>> >>> >>> >> >> > |
Re: Policy on plugins maintenance
|
Administrator
|
Actually it's only about a policy to support plugins with a clear how-to documentation.
We can start that right now. We need to clarify that plugins deserve the same attention than the framework and committers need to be aware of it. Jacques Le 12/04/2017 à 08:59, Taher Alkhateeb a écrit : > I think starting any vote right now might be a little premature. |
Re: Policy on plugins maintenance
|
Administrator
|
In reply to this post by Jacopo Cappellato-5
Le 12/04/2017 à 08:49, Jacopo Cappellato a écrit :
> On Tue, Mar 14, 2017 at 8:17 AM, Jacques Le Roux < > [hidden email]> wrote: > >> [...] > 7. Investigate and propose a methodology for maintaining plugins and >> versioning compatibility with OFBiz. >> > I think the easiest way to implement for now is to maintain one trunk for > both (ofbiz-framework/trunk and ofbiz-plugins/trunk) and one for each > release branch for both (e.g. ofbiz-framework/branches/release17.12 and > ofbiz-plugins/branches/release17.12) and then maintain compatibility > between the same branches (and trunks). > > Jacopo > Then you need to commit plugins separately because it's actually 2 working copies. But in an IDE you see the whole source code as a block. So you can maintain the whole easily, just need to remember to commit plugins separately. What is miss though is a updateAllPluginsSource Gradle task to automatise the plugins working copy update. For now I do it by hand or with a .bat. I had a try with https://issues.apache.org/jira/browse/OFBIZ-9275 but no success so far I agree about releases Jacques |
|
|
In reply to this post by Jacques Le Roux
Hmmm, I think maybe there might be a mix-up between treating the products
as separate and not-maintaining plugins. In the discussion in the referenced thread, I mentioned that the plugins should be a separate product as in having their own separate build system and release strategy. This does not mean they are not supported or do not get the same attention, it just means they are separate. So elaborating on this, if you commit something in the framework and it breaks something in plugins then my suggestion is that it should not be fixed in one single commit but rather as two separate unrelated commits. In other words, the two products should be very loosely coupled which is the main advantage of separating the project into two products. I hope this clarifies it better. On Wed, Apr 12, 2017 at 12:49 PM, Jacques Le Roux < [hidden email]> wrote: > Actually it's only about a policy to support plugins with a clear how-to > documentation. > > We can start that right now. We need to clarify that plugins deserve the > same attention than the framework and committers need to be aware of it. > > Jacques > > > > Le 12/04/2017 à 08:59, Taher Alkhateeb a écrit : > >> I think starting any vote right now might be a little premature. >> > > |
Re: Policy on plugins maintenance
|
Administrator
|
Thanks Taher,
I agree, and this indeed begins to clarify things Jacques Le 12/04/2017 à 12:09, Taher Alkhateeb a écrit : > Hmmm, I think maybe there might be a mix-up between treating the products > as separate and not-maintaining plugins. > > In the discussion in the referenced thread, I mentioned that the plugins > should be a separate product as in having their own separate build system > and release strategy. This does not mean they are not supported or do not > get the same attention, it just means they are separate. > > So elaborating on this, if you commit something in the framework and it > breaks something in plugins then my suggestion is that it should not be > fixed in one single commit but rather as two separate unrelated commits. In > other words, the two products should be very loosely coupled which is the > main advantage of separating the project into two products. > > I hope this clarifies it better. > > On Wed, Apr 12, 2017 at 12:49 PM, Jacques Le Roux < > [hidden email]> wrote: > >> Actually it's only about a policy to support plugins with a clear how-to >> documentation. >> >> We can start that right now. We need to clarify that plugins deserve the >> same attention than the framework and committers need to be aware of it. >> >> Jacques >> >> >> >> Le 12/04/2017 à 08:59, Taher Alkhateeb a écrit : >> >>> I think starting any vote right now might be a little premature. >>> >> |
Re: Policy on plugins maintenance
|
Administrator
|
Ah forgot to say that with the (very simple and logical) way I use, and have exposed in my answer to Jacopo, you can't commit in framework and plugins
at the same time. Jacques Le 12/04/2017 à 12:12, Jacques Le Roux a écrit : > Thanks Taher, > > I agree, and this indeed begins to clarify things > > Jacques > > > Le 12/04/2017 à 12:09, Taher Alkhateeb a écrit : >> Hmmm, I think maybe there might be a mix-up between treating the products >> as separate and not-maintaining plugins. >> >> In the discussion in the referenced thread, I mentioned that the plugins >> should be a separate product as in having their own separate build system >> and release strategy. This does not mean they are not supported or do not >> get the same attention, it just means they are separate. >> >> So elaborating on this, if you commit something in the framework and it >> breaks something in plugins then my suggestion is that it should not be >> fixed in one single commit but rather as two separate unrelated commits. In >> other words, the two products should be very loosely coupled which is the >> main advantage of separating the project into two products. >> >> I hope this clarifies it better. >> >> On Wed, Apr 12, 2017 at 12:49 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >>> Actually it's only about a policy to support plugins with a clear how-to >>> documentation. >>> >>> We can start that right now. We need to clarify that plugins deserve the >>> same attention than the framework and committers need to be aware of it. >>> >>> Jacques >>> >>> >>> >>> Le 12/04/2017 à 08:59, Taher Alkhateeb a écrit : >>> >>>> I think starting any vote right now might be a little premature. >>>> >>> > > |
Re: Policy on plugins maintenance
|
Administrator
|
In reply to this post by Jacques Le Roux
OK, I assume nobody is again setting a policy for committers to maintain plugins. As a 1st step I'll suggest the way I do it for now. When we will
have better ways we will update I'll change this page https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities Jacques Le 12/04/2017 à 08:42, Jacques Le Roux a écrit : > Mmm, I realise my last message is ambiguous. > > I mean, should I start a vote? > > Without any answers I'll assume it's a lazy consensus > > Thanks > > Jacques > > > Le 12/04/2017 à 08:24, Jacques Le Roux a écrit : >> Hi, >> >> Without any reactions, and because I believe this is important I'll start a vote >> >> If I get no attention at all, I'll consider this is a lazy consensus and will enforce this rule in the committers page in wiki >> >> Thanks >> >> Jacques >> >> >> Le 14/03/2017 à 08:25, Jacques Le Roux a écrit : >>> To sum up and as a kind of TL;DR, the question is <<should we "force" the committers to maintain the plugins?>> >>> >>> Jacques >>> >>> >>> Le 14/03/2017 à 08:17, Jacques Le Roux a écrit : >>>> Hi, >>>> >>>> In recent discussions I wrote >>>> >>>> <<I believe committers need now to agree about checking out all plugins and maintaining them as we did before. This must be documented in our >>>> policies.>> in <<[DISCUSSION] Plugins: svn:external or Gradle Task?)>> thread >>>> >>>> <<It seems to me that if a committer, committing something on the framework, breaks a plugins s/he is also responsible of fixing the plugins >>>> issue.>> in <<[proposal] actions to take with plugins>> thread >>>> >>>> but got no attention so far. >>>> >>>> Beside the last pending technical aspects defined in the <<[DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk>> >>>> http://markmail.org/message/6r4qnuu5v2c2aes2 >>>> >>>> 6. Investigate how to create a plugin repository with dependencies clearly defined, not only on external libraries but also other plugins! >>>> 7. Investigate and propose a methodology for maintaining plugins and versioning compatibility with OFBiz. >>>> 8. Investigate and propose a methodology for upgrading plugins within OFBiz >>>> >>>> I think we need to agree, not at a technical but political level, about how the plugins will be maintained, IMO not as second-class citizens! >>>> This is a very important topic because with the trunk split it's already there and the plugins could suffer from the split. >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> >>>> >>> >>> >> >> > |
Re: Policy on plugins maintenance
|
Administrator
|
Done
Jacques Le 13/04/2017 à 16:05, Jacques Le Roux a écrit : > OK, I assume nobody is again setting a policy for committers to maintain plugins. As a 1st step I'll suggest the way I do it for now. When we will > have better ways we will update > > I'll change this page https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities > > Jacques > > > Le 12/04/2017 à 08:42, Jacques Le Roux a écrit : >> Mmm, I realise my last message is ambiguous. >> >> I mean, should I start a vote? >> >> Without any answers I'll assume it's a lazy consensus >> >> Thanks >> >> Jacques >> >> >> Le 12/04/2017 à 08:24, Jacques Le Roux a écrit : >>> Hi, >>> >>> Without any reactions, and because I believe this is important I'll start a vote >>> >>> If I get no attention at all, I'll consider this is a lazy consensus and will enforce this rule in the committers page in wiki >>> >>> Thanks >>> >>> Jacques >>> >>> >>> Le 14/03/2017 à 08:25, Jacques Le Roux a écrit : >>>> To sum up and as a kind of TL;DR, the question is <<should we "force" the committers to maintain the plugins?>> >>>> >>>> Jacques >>>> >>>> >>>> Le 14/03/2017 à 08:17, Jacques Le Roux a écrit : >>>>> Hi, >>>>> >>>>> In recent discussions I wrote >>>>> >>>>> <<I believe committers need now to agree about checking out all plugins and maintaining them as we did before. This must be documented in our >>>>> policies.>> in <<[DISCUSSION] Plugins: svn:external or Gradle Task?)>> thread >>>>> >>>>> <<It seems to me that if a committer, committing something on the framework, breaks a plugins s/he is also responsible of fixing the plugins >>>>> issue.>> in <<[proposal] actions to take with plugins>> thread >>>>> >>>>> but got no attention so far. >>>>> >>>>> Beside the last pending technical aspects defined in the <<[DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk>> >>>>> http://markmail.org/message/6r4qnuu5v2c2aes2 >>>>> >>>>> 6. Investigate how to create a plugin repository with dependencies clearly defined, not only on external libraries but also other plugins! >>>>> 7. Investigate and propose a methodology for maintaining plugins and versioning compatibility with OFBiz. >>>>> 8. Investigate and propose a methodology for upgrading plugins within OFBiz >>>>> >>>>> I think we need to agree, not at a technical but political level, about how the plugins will be maintained, IMO not as second-class citizens! >>>>> This is a very important topic because with the trunk split it's already there and the plugins could suffer from the split. >>>>> >>>>> Thanks >>>>> >>>>> Jacques >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |