I think there needs to be at least 6 months between the disable code being released and the delete PR being merged. I feel like the clock has to start only when the disable code is generally available in a stable release (not when it is merged).
On Mar 19, 2017 6:47 AM, "Daan Hoogland" <daan.hoogl...@shapeblue.com> wrote: > You are spot on. We can add a due date for the final removal I think. > Let’s not add a target version, I’d say. > > On 18/03/17 23:23, "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 > > > >