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 < adrian.c...@sandglass-software.com> 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 < >> jacques.le.r...@les7arts.com> 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 >>> >> >>
