Don’t worry Marty, non-committers/-coders will be heard here as well.
Good point @swill I think we have enough wording to call this a policy now… As
so far, no objections of any kind have been raised I also think it is now
official unless someone now starts shouting. Here is a semi-formal definition
of the procedure.
Code that is not maintained and breaks the build will be phased out according
to the following retirement procedure:
1. An 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; This will be in
terms of “The firsts release after yyyy/mm/dd”
2. If no objection arises or no one volunteers to maintain the code, a Jira
ticket to disable of the code is created.
3. A patch to disable the code in the build will be created.
4. The patch is applied and released with the next x.y.0 release.
5. A Jira ticket to execute the final removal of the code is created.
6. A patch for the definite removal of the code is created.
7. The patch will be applied 6 months after the x.y.0 release is announced and
thus be release with x.(y+n).0 (n probably being 1 but could be higher)
On 19/03/17 18:53, "Marty Godsey" <ma...@gonsource.com> wrote:
I know that I am not a committer (I am a systems, networking guy, I don’t
"code") but I agree with Will. Giving the community at large some time to yell
if they are using is good.
Regards,
Marty Godsey
Principal Engineer
nSource Solutions, LLC
-----Original Message-----
From: Will Stevens [mailto:williamstev...@gmail.com]
Sent: Sunday, March 19, 2017 7:39 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Retirement of midonet plugin
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
>
>
>
>
daan.hoogl...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
