Yes, well you write a text to answer questions before they happen, right. 
Making a q&a section is a poetic trick that can work well in these kinds of 
texts though ;) but as you said, lets improve as questions come in.

This is only literary comment which is always up for argument, your content is 
right and to the point.
 
On 28/03/17 16:20, "Rafael Weingärtner" <rafaelweingart...@gmail.com> wrote:

    Thanks for the feedback Daan. I applied the changes as you suggested.
    
    I only created a Q&A section in advance because I was pretty sure someone
    might come with those questions. We can improve it on the fly, when other
    repetitive questions start to pop up.
    
    
    
    On Tue, Mar 28, 2017 at 10:10 AM, Daan Hoogland <daan.hoogl...@shapeblue.com
    > wrote:
    
    > Rafael, generally good but I don’t see why the question “why do we retire
    > … (process implied)” is part of the q&a section. I would make it part of 
an
    > introduction and put it directly after the first sentence, before the rest
    > of that paragraph.
    >
    > Arguably a q&a section only makes sense after a while when questions came
    > forward but I am fine with the other questions as is.
    >
    > On 28/03/17 16:00, "Rafael Weingärtner" <rafaelweingart...@gmail.com>
    > wrote:
    >
    >     I created a page describing the retirement process (it is general, not
    >     Midonet specific). Could I get some feedback from you guys?
    >
    >     https://cwiki.apache.org/confluence/display/CLOUDSTACK/
    > Plugin+retirement+process
    >
    >
    >     Then, I will create a proper voting thread and proceed with the steps
    >     described in our wiki.
    >
    >     On Tue, Mar 28, 2017 at 9:56 AM, Gabriel Beims Bräscher <
    >     gabrasc...@gmail.com> wrote:
    >
    >     > +1 on retiring midonet.
    >     >
    >     > 2017-03-28 10:50 GMT-03:00 Syed Ahmed <sah...@cloudops.com>:
    >     >
    >     > > +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
    >     > > >> >
    >     > > >> >
    >     > > >> >
    >     > > >> >
    >     > > >>
    >     > >
    >     >
    >
    >
    >
    >     --
    >     Rafael Weingärtner
    >
    >
    >
    > daan.hoogl...@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