Administrator
|
I tried to begin a discussion on this subject few times, notably at http://markmail.org/message/lgqhdtotwhfebqmw
But nothing happened, so I think the best is to start a vote. I see 2 questions hence 2 votes, I don't think it's necessary to start 2 threads because these 2 questions are closely related. So please vote for both questions, the ballot will last a week to allow everybody to have a chance to cast a vote. You can refer to https://www.apache.org/foundation/voting.html if you need information on how to vote. I suggest we only use +1 = I'm for +0 = not sure -1 = I'm against 1) Do you agree to reintroduce the evicted specialpurpose components in R13.07? Notes: The question is not about which components should and should not, it's all or nothing. Choosing component to put to Attic should be done in trunk as we did with appserver recently. I proposed 2 ways for doing that in the thread linked above, depending on the result of this vote this will be or not a new question (or might be discussed again if the vote is positive) The 2nd is of more importance since it concerns future releases 2) Do you agree to reintroduce the evicted specialpurpose components in future R13.07 releases? Note: Jacopo already started a thread about it at http://markmail.org/message/vwyuaokuzcj44z6w that's why I decided to ask for a vote to clearly and definitively close this chapter with the help of the community. Personally I will be happy with the solutions the community will come with. The current situation (all but ecommerce component evicted from specialpurpose in R13.07 branch and releases) comes from a lazy consensus (no formal vote) but weirdly now both questions concern a code modification so can be vetoed. Note that the second question is not about releasing or not. So it's not a vote on releasing a package, it's rather a preamble to future R13.07 package releases. Thanks for your attention and please vote! Jacques |
+1 on question 1
+1 on question 2 On Mar 22, 2015 8:27 PM, "Jacques Le Roux" <[hidden email]> wrote: > I tried to begin a discussion on this subject few times, notably at > http://markmail.org/message/lgqhdtotwhfebqmw > > But nothing happened, so I think the best is to start a vote. I see 2 > questions hence 2 votes, I don't think it's necessary to start 2 threads > because these 2 questions are closely related. > So please vote for both questions, the ballot will last a week to allow > everybody to have a chance to cast a vote. > > You can refer to https://www.apache.org/foundation/voting.html if you > need information on how to vote. I suggest we only use > > +1 = I'm for > +0 = not sure > -1 = I'm against > > 1) Do you agree to reintroduce the evicted specialpurpose components in > R13.07? > Notes: > The question is not about which components should and should not, it's all > or nothing. Choosing component to put to Attic should be done in trunk as > we did with appserver recently. > I proposed 2 ways for doing that in the thread linked above, depending on > the result of this vote this will be or not a new question (or might be > discussed again if the vote is positive) > > The 2nd is of more importance since it concerns future releases > 2) Do you agree to reintroduce the evicted specialpurpose components in > future R13.07 releases? > Note: Jacopo already started a thread about it at > http://markmail.org/message/vwyuaokuzcj44z6w that's why I decided to ask > for a vote to clearly and definitively close this chapter with the help of > the community. Personally I will be happy with the solutions the community > will come with. > > The current situation (all but ecommerce component evicted from > specialpurpose in R13.07 branch and releases) comes from a lazy consensus > (no formal vote) but weirdly now both questions concern a code modification > so can be vetoed. Note that the second question is not about releasing or > not. So it's not a vote on releasing a package, it's rather a preamble to > future R13.07 package releases. > > Thanks for your attention and please vote! > > Jacques > |
In reply to this post by Jacques Le Roux
On Mar 22, 2015, at 6:27 PM, Jacques Le Roux <[hidden email]> wrote: > I tried to begin a discussion on this subject few times, notably at http://markmail.org/message/lgqhdtotwhfebqmw > > But nothing happened, so I think the best is to start a vote. I see 2 questions hence 2 votes, I don't think it's necessary to start 2 threads because these 2 questions are closely related. > So please vote for both questions, the ballot will last a week to allow everybody to have a chance to cast a vote. > > You can refer to https://www.apache.org/foundation/voting.html if you need information on how to vote. I suggest we only use > > +1 = I'm for > +0 = not sure > -1 = I'm against > > 1) Do you agree to reintroduce the evicted specialpurpose components in R13.07? -1 as I mentioned in the past, I may be in favor of adding them back to the release branch in order to simplify maintenance of bug fix backporting to the parties interested; however there are a few conditions that in my opinion we need to address: * the components should be all disabled by default (at least in the release branches): in fact the specialpurpose components are allowed to override standard entities, services, screens, data with use-case (industry, vertical) specific information; the release branches should deliver by default the universal/generic artifacts and all the other stuff should be optional * some of them are old and not maintained and I think that it is odd to add them to the stabilized branch and then discuss if we want to remove them from trunk and branches * there are components that have issues (that can include license concerns and/or vulnerabilities): better to leave them out from release branches * in my opinion it should be better to discuss how to release more than one product rather than a monolithic one Because of all these factors, since you are asking for an all or nothing vote, I have to cast a -1. > Notes: > The question is not about which components should and should not, it's all or nothing. Choosing component to put to Attic should be done in trunk as we did with appserver recently. > I proposed 2 ways for doing that in the thread linked above, depending on the result of this vote this will be or not a new question (or might be discussed again if the vote is positive) > > The 2nd is of more importance since it concerns future releases > 2) Do you agree to reintroduce the evicted specialpurpose components in future R13.07 releases? -1 One important aspect that you didn't mention in this call to vote is: in the spirit of ASF voting, the persons that will vote +1 are stating that they are offering their help in supporting *all* the components in terms of license concerns, vulnerabilities that may be reported on published releases (that undergo a series of audits by external parties); this is why I think that calling a vote for all components is a bad idea (a person interested in supporting component X will have to promise help for all of them, even the old ones with known issues). > Note: Jacopo already started a thread about it at http://markmail.org/message/vwyuaokuzcj44z6w that's why I decided to ask for a vote to clearly and definitively close this chapter with the help of the community. Personally I will be happy with the solutions the community will come with. > > The current situation (all but ecommerce component evicted from specialpurpose in R13.07 branch and releases) comes from a lazy consensus (no formal vote) but weirdly now both questions concern a code modification so can be vetoed. Jacques, you are doing some confusion: this is not a vote about a commit, and my negative votes are not vetos. Jacopo > Note that the second question is not about releasing or not. So it's not a vote on releasing a package, it's rather a preamble to future R13.07 package releases. > > Thanks for your attention and please vote! > > Jacques |
-1 for the same reasons as Jacopo.
Adrian Crum Sandglass Software www.sandglass-software.com On 3/24/2015 9:10 AM, Jacopo Cappellato wrote: > > On Mar 22, 2015, at 6:27 PM, Jacques Le Roux <[hidden email]> wrote: > >> I tried to begin a discussion on this subject few times, notably at http://markmail.org/message/lgqhdtotwhfebqmw >> >> But nothing happened, so I think the best is to start a vote. I see 2 questions hence 2 votes, I don't think it's necessary to start 2 threads because these 2 questions are closely related. >> So please vote for both questions, the ballot will last a week to allow everybody to have a chance to cast a vote. >> >> You can refer to https://www.apache.org/foundation/voting.html if you need information on how to vote. I suggest we only use >> >> +1 = I'm for >> +0 = not sure >> -1 = I'm against >> >> 1) Do you agree to reintroduce the evicted specialpurpose components in R13.07? > > -1 > as I mentioned in the past, I may be in favor of adding them back to the release branch in order to simplify maintenance of bug fix backporting to the parties interested; however there are a few conditions that in my opinion we need to address: > * the components should be all disabled by default (at least in the release branches): in fact the specialpurpose components are allowed to override standard entities, services, screens, data with use-case (industry, vertical) specific information; the release branches should deliver by default the universal/generic artifacts and all the other stuff should be optional > * some of them are old and not maintained and I think that it is odd to add them to the stabilized branch and then discuss if we want to remove them from trunk and branches > * there are components that have issues (that can include license concerns and/or vulnerabilities): better to leave them out from release branches > * in my opinion it should be better to discuss how to release more than one product rather than a monolithic one > > Because of all these factors, since you are asking for an all or nothing vote, I have to cast a -1. > >> Notes: >> The question is not about which components should and should not, it's all or nothing. Choosing component to put to Attic should be done in trunk as we did with appserver recently. >> I proposed 2 ways for doing that in the thread linked above, depending on the result of this vote this will be or not a new question (or might be discussed again if the vote is positive) >> >> The 2nd is of more importance since it concerns future releases >> 2) Do you agree to reintroduce the evicted specialpurpose components in future R13.07 releases? > > -1 > One important aspect that you didn't mention in this call to vote is: in the spirit of ASF voting, the persons that will vote +1 are stating that they are offering their help in supporting *all* the components in terms of license concerns, vulnerabilities that may be reported on published releases (that undergo a series of audits by external parties); this is why I think that calling a vote for all components is a bad idea (a person interested in supporting component X will have to promise help for all of them, even the old ones with known issues). > >> Note: Jacopo already started a thread about it at http://markmail.org/message/vwyuaokuzcj44z6w that's why I decided to ask for a vote to clearly and definitively close this chapter with the help of the community. Personally I will be happy with the solutions the community will come with. >> >> The current situation (all but ecommerce component evicted from specialpurpose in R13.07 branch and releases) comes from a lazy consensus (no formal vote) but weirdly now both questions concern a code modification so can be vetoed. > > Jacques, you are doing some confusion: this is not a vote about a commit, and my negative votes are not vetos. > > Jacopo > >> Note that the second question is not about releasing or not. So it's not a vote on releasing a package, it's rather a preamble to future R13.07 package releases. >> >> Thanks for your attention and please vote! >> >> Jacques > |
R13.07 is a mistake and an embarrassment to this project. It wouldn't have
happened if more attention was paid to my concerns and objections, and those of others. Unfortunately, that can't be undone. Only reduced. We should get past it as fast and as easy possible. Reintroducing the omtted components will need a enormous amount of effort. In stead of correcting the r13.07 branch and get a new release out, we should stop working on that branch, make a statement somewhere on our pages and get 14.12.01 out as fast as possible. Best regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Tue, Mar 24, 2015 at 10:27 AM, Adrian Crum < [hidden email]> wrote: > -1 for the same reasons as Jacopo. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > > On 3/24/2015 9:10 AM, Jacopo Cappellato wrote: > >> >> On Mar 22, 2015, at 6:27 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >> I tried to begin a discussion on this subject few times, notably at >>> http://markmail.org/message/lgqhdtotwhfebqmw >>> >>> But nothing happened, so I think the best is to start a vote. I see 2 >>> questions hence 2 votes, I don't think it's necessary to start 2 threads >>> because these 2 questions are closely related. >>> So please vote for both questions, the ballot will last a week to allow >>> everybody to have a chance to cast a vote. >>> >>> You can refer to https://www.apache.org/foundation/voting.html if you >>> need information on how to vote. I suggest we only use >>> >>> +1 = I'm for >>> +0 = not sure >>> -1 = I'm against >>> >>> 1) Do you agree to reintroduce the evicted specialpurpose components in >>> R13.07? >>> >> >> -1 >> as I mentioned in the past, I may be in favor of adding them back to the >> release branch in order to simplify maintenance of bug fix backporting to >> the parties interested; however there are a few conditions that in my >> opinion we need to address: >> * the components should be all disabled by default (at least in the >> release branches): in fact the specialpurpose components are allowed to >> override standard entities, services, screens, data with use-case >> (industry, vertical) specific information; the release branches should >> deliver by default the universal/generic artifacts and all the other stuff >> should be optional >> * some of them are old and not maintained and I think that it is odd to >> add them to the stabilized branch and then discuss if we want to remove >> them from trunk and branches >> * there are components that have issues (that can include license >> concerns and/or vulnerabilities): better to leave them out from release >> branches >> * in my opinion it should be better to discuss how to release more than >> one product rather than a monolithic one >> >> Because of all these factors, since you are asking for an all or nothing >> vote, I have to cast a -1. >> >> Notes: >>> The question is not about which components should and should not, it's >>> all or nothing. Choosing component to put to Attic should be done in trunk >>> as we did with appserver recently. >>> I proposed 2 ways for doing that in the thread linked above, depending >>> on the result of this vote this will be or not a new question (or might be >>> discussed again if the vote is positive) >>> >>> The 2nd is of more importance since it concerns future releases >>> 2) Do you agree to reintroduce the evicted specialpurpose components in >>> future R13.07 releases? >>> >> >> -1 >> One important aspect that you didn't mention in this call to vote is: in >> the spirit of ASF voting, the persons that will vote +1 are stating that >> they are offering their help in supporting *all* the components in terms of >> license concerns, vulnerabilities that may be reported on published >> releases (that undergo a series of audits by external parties); this is why >> I think that calling a vote for all components is a bad idea (a person >> interested in supporting component X will have to promise help for all of >> them, even the old ones with known issues). >> >> Note: Jacopo already started a thread about it at >>> http://markmail.org/message/vwyuaokuzcj44z6w that's why I decided to >>> ask for a vote to clearly and definitively close this chapter with the help >>> of the community. Personally I will be happy with the solutions the >>> community will come with. >>> >>> The current situation (all but ecommerce component evicted from >>> specialpurpose in R13.07 branch and releases) comes from a lazy consensus >>> (no formal vote) but weirdly now both questions concern a code modification >>> so can be vetoed. >>> >> >> Jacques, you are doing some confusion: this is not a vote about a commit, >> and my negative votes are not vetos. >> >> Jacopo >> >> Note that the second question is not about releasing or not. So it's not >>> a vote on releasing a package, it's rather a preamble to future R13.07 >>> package releases. >>> >>> Thanks for your attention and please vote! >>> >>> Jacques >>> >> >> |
+1
On Tue, Mar 24, 2015 at 11:44 AM, Pierre Smits <[hidden email]> wrote: > R13.07 is a mistake and an embarrassment to this project. It wouldn't have > happened if more attention was paid to my concerns and objections, and > those of others. > > Unfortunately, that can't be undone. Only reduced. We should get past it as > fast and as easy possible. Reintroducing the omtted components will need a > enormous amount of effort. In stead of correcting the r13.07 branch and get > a new release out, we should stop working on that branch, make a statement > somewhere on our pages and get 14.12.01 out as fast as possible. > > Best regards, > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Tue, Mar 24, 2015 at 10:27 AM, Adrian Crum < > [hidden email]> wrote: > > > -1 for the same reasons as Jacopo. > > > > Adrian Crum > > Sandglass Software > > www.sandglass-software.com > > > > > > On 3/24/2015 9:10 AM, Jacopo Cappellato wrote: > > > >> > >> On Mar 22, 2015, at 6:27 PM, Jacques Le Roux < > >> [hidden email]> wrote: > >> > >> I tried to begin a discussion on this subject few times, notably at > >>> http://markmail.org/message/lgqhdtotwhfebqmw > >>> > >>> But nothing happened, so I think the best is to start a vote. I see 2 > >>> questions hence 2 votes, I don't think it's necessary to start 2 > threads > >>> because these 2 questions are closely related. > >>> So please vote for both questions, the ballot will last a week to allow > >>> everybody to have a chance to cast a vote. > >>> > >>> You can refer to https://www.apache.org/foundation/voting.html if you > >>> need information on how to vote. I suggest we only use > >>> > >>> +1 = I'm for > >>> +0 = not sure > >>> -1 = I'm against > >>> > >>> 1) Do you agree to reintroduce the evicted specialpurpose components in > >>> R13.07? > >>> > >> > >> -1 > >> as I mentioned in the past, I may be in favor of adding them back to the > >> release branch in order to simplify maintenance of bug fix backporting > to > >> the parties interested; however there are a few conditions that in my > >> opinion we need to address: > >> * the components should be all disabled by default (at least in the > >> release branches): in fact the specialpurpose components are allowed to > >> override standard entities, services, screens, data with use-case > >> (industry, vertical) specific information; the release branches should > >> deliver by default the universal/generic artifacts and all the other > stuff > >> should be optional > >> * some of them are old and not maintained and I think that it is odd to > >> add them to the stabilized branch and then discuss if we want to remove > >> them from trunk and branches > >> * there are components that have issues (that can include license > >> concerns and/or vulnerabilities): better to leave them out from release > >> branches > >> * in my opinion it should be better to discuss how to release more than > >> one product rather than a monolithic one > >> > >> Because of all these factors, since you are asking for an all or nothing > >> vote, I have to cast a -1. > >> > >> Notes: > >>> The question is not about which components should and should not, it's > >>> all or nothing. Choosing component to put to Attic should be done in > trunk > >>> as we did with appserver recently. > >>> I proposed 2 ways for doing that in the thread linked above, depending > >>> on the result of this vote this will be or not a new question (or > might be > >>> discussed again if the vote is positive) > >>> > >>> The 2nd is of more importance since it concerns future releases > >>> 2) Do you agree to reintroduce the evicted specialpurpose components in > >>> future R13.07 releases? > >>> > >> > >> -1 > >> One important aspect that you didn't mention in this call to vote is: in > >> the spirit of ASF voting, the persons that will vote +1 are stating that > >> they are offering their help in supporting *all* the components in > terms of > >> license concerns, vulnerabilities that may be reported on published > >> releases (that undergo a series of audits by external parties); this is > why > >> I think that calling a vote for all components is a bad idea (a person > >> interested in supporting component X will have to promise help for all > of > >> them, even the old ones with known issues). > >> > >> Note: Jacopo already started a thread about it at > >>> http://markmail.org/message/vwyuaokuzcj44z6w that's why I decided to > >>> ask for a vote to clearly and definitively close this chapter with the > help > >>> of the community. Personally I will be happy with the solutions the > >>> community will come with. > >>> > >>> The current situation (all but ecommerce component evicted from > >>> specialpurpose in R13.07 branch and releases) comes from a lazy > consensus > >>> (no formal vote) but weirdly now both questions concern a code > modification > >>> so can be vetoed. > >>> > >> > >> Jacques, you are doing some confusion: this is not a vote about a > commit, > >> and my negative votes are not vetos. > >> > >> Jacopo > >> > >> Note that the second question is not about releasing or not. So it's > not > >>> a vote on releasing a package, it's rather a preamble to future R13.07 > >>> package releases. > >>> > >>> Thanks for your attention and please vote! > >>> > >>> Jacques > >>> > >> > >> > |
In reply to this post by Jacques Le Roux
1) -1
2) -1 I trust in add-ons management and I think that each special purpose can be an add-on for the framework. The big question is how the community can maintain add-ons without a manager. It's a pity to not be able to see and install easily special purposes in the Apache OFBiz project... but it's better to not have it by default. Julien. Le 22/03/2015 18:27, Jacques Le Roux a écrit : > I tried to begin a discussion on this subject few times, notably at > http://markmail.org/message/lgqhdtotwhfebqmw > > But nothing happened, so I think the best is to start a vote. I see 2 > questions hence 2 votes, I don't think it's necessary to start 2 > threads because these 2 questions are closely related. > So please vote for both questions, the ballot will last a week to > allow everybody to have a chance to cast a vote. > > You can refer to https://www.apache.org/foundation/voting.html if you > need information on how to vote. I suggest we only use > > +1 = I'm for > +0 = not sure > -1 = I'm against > > 1) Do you agree to reintroduce the evicted specialpurpose components > in R13.07? > Notes: > The question is not about which components should and should not, it's > all or nothing. Choosing component to put to Attic should be done in > trunk as we did with appserver recently. > I proposed 2 ways for doing that in the thread linked above, depending > on the result of this vote this will be or not a new question (or > might be discussed again if the vote is positive) > > The 2nd is of more importance since it concerns future releases > 2) Do you agree to reintroduce the evicted specialpurpose components > in future R13.07 releases? > Note: Jacopo already started a thread about it at > http://markmail.org/message/vwyuaokuzcj44z6w that's why I decided to > ask for a vote to clearly and definitively close this chapter with the > help of the community. Personally I will be happy with the solutions > the community will come with. > > The current situation (all but ecommerce component evicted from > specialpurpose in R13.07 branch and releases) comes from a lazy > consensus (no formal vote) but weirdly now both questions concern a > code modification so can be vetoed. Note that the second question is > not about releasing or not. So it's not a vote on releasing a package, > it's rather a preamble to future R13.07 package releases. > > Thanks for your attention and please vote! > > Jacques |
Administrator
|
In reply to this post by Jacopo Cappellato-5
Le 24/03/2015 10:10, Jacopo Cappellato a écrit :
> On Mar 22, 2015, at 6:27 PM, Jacques Le Roux <[hidden email]> wrote: > >> I tried to begin a discussion on this subject few times, notably at http://markmail.org/message/lgqhdtotwhfebqmw >> >> But nothing happened, so I think the best is to start a vote. I see 2 questions hence 2 votes, I don't think it's necessary to start 2 threads because these 2 questions are closely related. >> So please vote for both questions, the ballot will last a week to allow everybody to have a chance to cast a vote. >> >> You can refer to https://www.apache.org/foundation/voting.html if you need information on how to vote. I suggest we only use >> >> +1 = I'm for >> +0 = not sure >> -1 = I'm against >> >> 1) Do you agree to reintroduce the evicted specialpurpose components in R13.07? > -1 > as I mentioned in the past, I may be in favor of adding them back to the release branch in order to simplify maintenance of bug fix backporting to the parties interested; however there are a few conditions that in my opinion we need to address: > * the components should be all disabled by default (at least in the release branches): in fact the specialpurpose components are allowed to override standard entities, services, screens, data with use-case (industry, vertical) specific information; the release branches should deliver by default the universal/generic artifacts and all the other stuff should be optional If this is a criteria I believe the pos component would be in the same situation than the ecommerce component... It adds new entities and some data, but they make sense, it does not redefine anything. I did not look in details at other components but webpos and example are probably in the same situation than the POS. The example/ext component/s notably misse/s IMO. > * some of them are old and not maintained and I think that it is odd to add them to the stabilized branch and then discuss if we want to remove them from trunk and branches Of course nothing that is not in trunk > * there are components that have issues (that can include license concerns and/or vulnerabilities): better to leave them out from release branches They should even not be in trunk then. We should address that with Jira issues ASAP if we want to keep those, else Attic seems the way. Whose are they? > * in my opinion it should b better to discuss how to release more than one product rather than a monolithic one That's an option indeed, but sounds harder to maintain, looking forward for your ideas... > > Because of all these factors, since you are asking for an all or nothing vote, I have to cast a -1. > >> Notes: >> The question is not about which components should and should not, it's all or nothing. Choosing component to put to Attic should be done in trunk as we did with appserver recently. >> I proposed 2 ways for doing that in the thread linked above, depending on the result of this vote this will be or not a new question (or might be discussed again if the vote is positive) >> >> The 2nd is of more importance since it concerns future releases >> 2) Do you agree to reintroduce the evicted specialpurpose components in future R13.07 releases? > -1 > One important aspect that you didn't mention in this call to vote is: in the spirit of ASF voting, the persons that will vote +1 are stating that they are offering their help in supporting *all* the components in terms of license concerns, vulnerabilities that may be reported on published releases (that undergo a series of audits by external parties); this is why I think that calling a vote for all components is a bad idea (a person interested in supporting component X will have to promise help for all of them, even the old ones with known issues). I guess you refer to https://www.apache.org/foundation/voting.html#implications-of-voting. Would it be not too much to start a vote for each component? Actually my idea was more to evaluate the community willing about this subject. For R13.07 it's a bit too late, but I'd not want that we go the same way with R14.12 releases... >> Note: Jacopo already started a thread about it at http://markmail.org/message/vwyuaokuzcj44z6w that's why I decided to ask for a vote to clearly and definitively close this chapter with the help of the community. Personally I will be happy with the solutions the community will come with. >> >> The current situation (all but ecommerce component evicted from specialpurpose in R13.07 branch and releases) comes from a lazy consensus (no formal vote) but weirdly now both questions concern a code modification so can be vetoed. > Jacques, you are doing some confusion: this is not a vote about a commit, and my negative votes are not vetos. I thought about that, it's a moot point. Is removing components from a branch really not a code change? Jacques > > Jacopo > >> Note that the second question is not about releasing or not. So it's not a vote on releasing a package, it's rather a preamble to future R13.07 package releases. >> >> Thanks for your attention and please vote! >> >> Jacques > > |
On Mar 24, 2015, at 2:56 PM, Jacques Le Roux <[hidden email]> wrote:
> I thought about that, it's a moot point. Is removing components from a branch really not a code change? I am sorry but I am not following you... aren't we discussing about adding them instead of removing? Jacopo |
In reply to this post by Jacques Le Roux
On Mar 24, 2015, at 2:56 PM, Jacques Le Roux <[hidden email]> wrote:
> If this is a criteria I believe the pos component would be in the same situation than the ecommerce component... It adds new entities and some data, but they make sense, it does not redefine anything. I think you don't remember the real reason the ecommerce component is in the 13.07 release branch: the only reason is that the framework/applications have a (bad/wrong) dependency on ecommerce and we could not pull it without breaking them. Jacopo |
In reply to this post by Jacques Le Roux
On Mar 24, 2015, at 2:56 PM, Jacques Le Roux <[hidden email]> wrote:
> For R13.07 it's a bit too late, but I'd not want that we go the same way with R14.12 releases... Isn't this vote about 13.07? In fact, because of your decision to call this vote we have stopped the preparation of the release 13.07.02. Jacopo |
In reply to this post by Jacques Le Roux
On Mar 24, 2015, at 2:56 PM, Jacques Le Roux <[hidden email]> wrote:
> They should even not be in trunk then. We should address that with Jira issues ASAP if we want to keep those, else Attic seems the way. Whose are they? Mailing list archives have information about some of these issues. Jacopo |
In reply to this post by Jacques Le Roux
On Mar 24, 2015, at 2:56 PM, Jacques Le Roux <[hidden email]> wrote:
>> * there are components that have issues (that can include license concerns and/or vulnerabilities): better to leave them out from release branches > > They should even not be in trunk then I agree; but if they are in published releases this is even worse because the PMC have to sign them. trunk is not officially published. We discussed about these concepts several times. Jacopo |
Administrator
|
In reply to this post by Jacopo Cappellato-5
Ha right, I did not remember that indeed.
Jacques Le 24/03/2015 15:20, Jacopo Cappellato a écrit : > On Mar 24, 2015, at 2:56 PM, Jacques Le Roux <[hidden email]> wrote: > >> If this is a criteria I believe the pos component would be in the same situation than the ecommerce component... It adds new entities and some data, but they make sense, it does not redefine anything. > I think you don't remember the real reason the ecommerce component is in the 13.07 release branch: the only reason is that the framework/applications have a (bad/wrong) dependency on ecommerce and we could not pull it without breaking them. > > Jacopo > |
Administrator
|
In reply to this post by Jacopo Cappellato-5
Le 24/03/2015 15:23, Jacopo Cappellato a écrit :
> On Mar 24, 2015, at 2:56 PM, Jacques Le Roux <[hidden email]> wrote: > >> I thought about that, it's a moot point. Is removing components from a branch really not a code change? > I am sorry but I am not following you... aren't we discussing about adding them instead of removing? > > Jacopo > For that they must have been removed at some point. For me removing/re-adding is a code change Jacques |
Administrator
|
In reply to this post by Jacopo Cappellato-5
Le 24/03/2015 15:24, Jacopo Cappellato a écrit :
> On Mar 24, 2015, at 2:56 PM, Jacques Le Roux <[hidden email]> wrote: > >> For R13.07 it's a bit too late, but I'd not want that we go the same way with R14.12 releases... > Isn't this vote about 13.07? In fact, because of your decision to call this vote we have stopped the preparation of the release 13.07.02. > > Jacopo > Yes, it's about R13.07. I just mentioned R14.12 here because we need to be careful next time (R14.12.01). I don't think it's a good idea to remove *all* specialpurpose components from a release (but those we can't) Jacques |
Administrator
|
In reply to this post by Jacopo Cappellato-5
Le 24/03/2015 15:25, Jacopo Cappellato a écrit :
> On Mar 24, 2015, at 2:56 PM, Jacques Le Roux <[hidden email]> wrote: > >> They should even not be in trunk then. We should address that with Jira issues ASAP if we want to keep those, else Attic seems the way. Whose are they? > Mailing list archives have information about some of these issues. > > Jacopo > Mmm, we will need to digg them then. We should have opened Jira issues about them then. Nobody remembers? Jacques |
Administrator
|
In reply to this post by Jacques Le Roux
@Ron,
Could you please update the graph at https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies to show the framework dependency on ecommerce? You see this is what I dread, apart you nobody knows Graphviz, hopefully I guess it's easy to use? @Jacopo, About this framework dependency on ecommerce, I hope it's only about data, is https://issues.apache.org/jira/browse/OFBIZ-6110 enough? Thanks Jacques Le 24/03/2015 15:54, Jacques Le Roux a écrit : > Ha right, I did not remember that indeed. > > Jacques > > Le 24/03/2015 15:20, Jacopo Cappellato a écrit : >> On Mar 24, 2015, at 2:56 PM, Jacques Le Roux <[hidden email]> wrote: >> >>> If this is a criteria I believe the pos component would be in the same situation than the ecommerce component... It adds new entities and some >>> data, but they make sense, it does not redefine anything. >> I think you don't remember the real reason the ecommerce component is in the 13.07 release branch: the only reason is that the >> framework/applications have a (bad/wrong) dependency on ecommerce and we could not pull it without breaking them. >> >> Jacopo >> > |
In reply to this post by Jacopo Cappellato-5
Sub-projects?
If anyone is still reading... The project seems to have reached a size where managing it is getting to be too contentious. There was a suggestion about splitting out the framework and releasing it as a separate deliverable. This idea seems to have some merit. - it would force clarity about dependencies - it would allow the framework to be documented and "marketed" as a separate entity for those who do not want all of the apps. - it would allow framework bugs and enhancements (caching fix?) to be released more often. - it would probably add some stability to the framework by forcing applications to provide their own seed data and to be explicit about what versions of the framework are required. - it would allow segregation of commmitters so that people with no interest in applications could work on the framework and vice versa. - it would make the web site and wiki a damn sight easier to understand and maintain. This discussion seems to be about finding a way to split the application base into manageable units that can be released, when and if there is a need, without holding up the progress towards a release of the core (whatever that turns out to be). At some point the OFBiz community is going to have to bite the bullet on this and I think that this might be the time to analyze whether the current effort in managing the floating definition of "core functionality" is more trouble than addressing it properly and breaking the project into separately released sub-projects. Is there a consensus of what constitutes a set of applications that absolutely must be released as a unit in order for cross applications dependencies to work? Can this be reduced? I can not see any reason why it would not be acceptable to have an application that warrants that its version 15.01.1 requires framework > 12.04.0 and core 12.04.5 while version 15.03.01 requires the latest framework 13.07.xx and application core 13.07.xx. I understand that there is some cleaning up of entities and seed data that needs to be done but it does not seem to be a problem beyond the capabilities of the team. Ron On 24/03/2015 10:26 AM, Jacopo Cappellato wrote: > On Mar 24, 2015, at 2:56 PM, Jacques Le Roux <[hidden email]> wrote: > >>> * there are components that have issues (that can include license concerns and/or vulnerabilities): better to leave them out from release branches >> They should even not be in trunk then > I agree; but if they are in published releases this is even worse because the PMC have to sign them. trunk is not officially published. > We discussed about these concepts several times. > > Jacopo > > -- Ron Wheeler President Artifact Software Inc email: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
Administrator
|
In reply to this post by Jacques Le Roux
Le 24/03/2015 16:12, Jacques Le Roux a écrit : > @Ron, > > Could you please update the graph at https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies to show the > framework dependency on ecommerce? > You see this is what I dread, apart you nobody knows Graphviz, hopefully I guess it's easy to use? Sorry for the confusion Ron, only of course if OFBIZ-6110 is not enough (we have and indirect dependency of framework to ecommerce through order and product) So waiting Jacopo's answer Jacques > > @Jacopo, > > About this framework dependency on ecommerce, I hope it's only about data, is https://issues.apache.org/jira/browse/OFBIZ-6110 enough? > > Thanks > > Jacques > > Le 24/03/2015 15:54, Jacques Le Roux a écrit : >> Ha right, I did not remember that indeed. >> >> Jacques >> >> Le 24/03/2015 15:20, Jacopo Cappellato a écrit : >>> On Mar 24, 2015, at 2:56 PM, Jacques Le Roux <[hidden email]> wrote: >>> >>>> If this is a criteria I believe the pos component would be in the same situation than the ecommerce component... It adds new entities and some >>>> data, but they make sense, it does not redefine anything. >>> I think you don't remember the real reason the ecommerce component is in the 13.07 release branch: the only reason is that the >>> framework/applications have a (bad/wrong) dependency on ecommerce and we could not pull it without breaking them. >>> >>> Jacopo >>> >> > |
Free forum by Nabble | Edit this page |