+1 That plugin needs to go :)
On Mon, Mar 27, 2017 at 4:36 PM, Erik Weber <terbol...@gmail.com> wrote: > Sounds good :-) > > > Erik > > man. 27. mar. 2017 kl. 18.03 skrev Will Stevens <wstev...@cloudops.com>: > >> I think we are planning to do something like "at least 6 months" because of >> the irregularity of releases. This gives us a date (from when the >> announcement was release becomes available) till the PR to remove gets >> merged. That PR will then be included in the next release whenever it is. >> So if the "time" is 6 months, it could actually be closer to 9 months >> before it actually gets removes since the release may not be ready to be >> cut at 6 months. >> >> Does this make sense? It gives us a way to have a date alert when a PR >> should be merged rather than trying to track which releases each >> decommissioned item is targeted for, which could mess up timing if there is >> some long release cycles as well as short ones... >> >> *Will STEVENS* >> Lead Developer >> >> <https://goo.gl/NYZ8KK> >> >> On Mon, Mar 27, 2017 at 9:46 AM, Daan Hoogland < >> daan.hoogl...@shapeblue.com> >> wrote: >> >> > I am against that >> > Strain on the community is not in releases but in time. We already >> > guarantee it is at least one minor >> > >> > On 27/03/17 15:24, "Erik Weber" <terbol...@gmail.com> wrote: >> > >> > Personally I would be in favour of using releases rather than months >> > as time unit. >> > Our release schedule is very unpredictable, and it's hard to foresee >> > how many releases we've rolled out in 6 months. >> > >> > Deprecate in the next (4.11?), remove a few releases later (4.13?). >> > >> > -- >> > Erik >> > >> > On Sat, Mar 18, 2017 at 11:23 PM, Rafael Weingärtner >> > <rafaelweingart...@gmail.com> wrote: >> > > Sorry the delay guys, I have been swapped these last days. >> > > >> > > In summary, everybody that spoke is in favor of the plugin >> > retirement. I am >> > > assuming that people who did not present their opinion agree with >> > the ones >> > > presented here. >> > > >> > > The process to retire this plugin would be the following: >> > > >> > > 1. Announce in our mailing lists the road map of retirement, a >> > data for >> > > the final removal should be defined and presented in this road >> > map; >> > > 2. Create a Jira ticket to execute the plugin disabling (is this >> > > expression right?!), and of course, a PR to disable the build >> > until final >> > > deletion; >> > > 3. Create a Jira ticket to execute the final removal of the >> > plugin. The >> > > removal should only happen when the defined date comes by; >> > > 4. Wait patiently while time goes by…. >> > > 5. When the time comes, create the PR and execute the plugin >> > removal. >> > > >> > > >> > > What date would you guys prefer to execute the plugin removal? 3, >> 6, >> > or 12 >> > > months from now? >> > > What do you think of this process? Am I missing something else? >> > > >> > > >> > > >> > > On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair <j...@greenqloud.com> >> > wrote: >> > > >> > >> Complete removal of the plugin was my solution to the problem of >> > the jar >> > >> file's dependencies. If it's not used or maintained, then it >> should >> > be >> > >> removed, in my opinion. Disabling it in the build is a good first >> > step. >> > >> >> > >> *Jeff Hair* >> > >> Technical Lead and Software Developer >> > >> >> > >> Tel: (+354) 415 0200 >> > >> j...@greenqloud.com >> > >> www.greenqloud.com >> > >> >> > >> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < >> > rohit.ya...@shapeblue.com> >> > >> wrote: >> > >> >> > >> > +1 as others have noted >> > >> > >> > >> > >> > >> > Disable the plugin from the default build for next few releases >> > and >> > >> > eventually deprecate/remove the plugin from the codebase. The >> > roadmap can >> > >> > look something like: >> > >> > >> > >> > - Announce on the MLs that we're planning to do this, send a PR >> > and get >> > >> it >> > >> > accepted >> > >> > >> > >> > - During the release process RM should make this information >> > available to >> > >> > everyone (including voting thread, would be nice to have a >> > shortlog of >> > >> > major changes in the voting email?) >> > >> > >> > >> > - In the release notes and release announcement, note that >> > midonet is no >> > >> > longer included in the default build and is planned to be >> > deprecated >> > >> > >> > >> > - By end of the year, if we've no communication received >> > deprecate and >> > >> > remove the plugin with an announcement >> > >> > >> > >> > >> > >> > I think this should be done with Midonet and any other plugins >> > that are >> > >> > causing issues and are no longer maintained by anyway. >> > >> > >> > >> > >> > >> > Regards. >> > >> > >> > >> > ________________________________ >> > >> > From: Sergey Levitskiy <sergey.levits...@autodesk.com> >> > >> > Sent: 15 March 2017 07:00:51 >> > >> > To: dev@cloudstack.apache.org >> > >> > Subject: Re: [DISCUSS] Retirement of midonet plugin >> > >> > >> > >> > I am for: >> > >> > (i) disable the build for the plugin for the next 2 major >> release >> > >> > followed by >> > >> > (ii) remove everything in ACS 4.12 if no one express regrets by >> > then >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > rohit.ya...@shapeblue.com >> > >> > www.shapeblue.com >> > >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK >> > >> > @shapeblue >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> > > >> > > >> > > >> > > -- >> > > Rafael Weingärtner >> > >> > >> > >> > daan.hoogl...@shapeblue.com >> > www.shapeblue.com >> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK >> > @shapeblue >> > >> > >> > >> > >>
