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
>
>
>
>

Reply via email to