So is the plan option 3?  I have seen tickets fixing licenses, so good work
there.  When a vote is started on dev@mxnet.a.o, include wording about not
waiting the full 72 hours since this is just updating licensing.  Get as
many +1 votes as you can on both the release and not waiting then move on
to IPMC.  The vote on general@incubator.a.o should still stay open 72
hours.  I will look at it as soon as it is posted, but maybe reach out to
the other mentors directly asking for their help to review as soon as it is
out.  The goal is to have the 3 or more +1 votes and more positive then
negative as soon as the 72 hours hits.

Mike

On Wed, Feb 13, 2019 at 2:44 AM Justin Mclean <jus...@classsoftware.com>
wrote:

> forgot to CC dev
>
> > Begin forwarded message:
> >
> > From: Justin Mclean <jus...@classsoftware.com>
> > Subject: Re: [RESTARTING][VOTE] Release Apache MXNet (incubating)
> version 1.4.0.rc2
> > Date: 13 February 2019 at 6:43:48 pm AEDT
> > To: Michael Wall <mjw...@gmail.com>
> >
> > Hi,
> >
> >> Option 1:
> >> Do nothing.  I don't know how a RESTARTED vote works.
> >
> > I don’t believe there is such a concept.
> >
> >> Option 2:
> >> Start another vote thread on general@incubator.a.o pointing to the
> original vote thread on dev@mxnet.a.o and the canceled vote thread.
> >
> > It may end up with the same outcome.
> >
> >> Option 3:
> >> 1 - Fix the header issues.
> > <snip>
> >> 3 - Start a vote thread on general@incubator.a.o pointing to the new
> vote thread from step 2.  Will likely need to be open 72 hours.
> >
> > Just be aware it can take longer, sometime much longer, to get the 3 +1
> IPMC votes.
> >
> >> Tough position to be in with Horovod being released.
> >
> > Which show the risk of tying in your release cycle with a non Apache
> product. IMO you need to be independent of 3rd party releases and not tied
> to their milestones. If they wanted to include a particular unreleased
> version of ASF software, you should started the release a long time ahead
> of time just in case problems were encountered issues.This probably
> wouldn't be an issue if you made more frequent releases, it’s easier to
> check compliance with frequent releases so the 3rd party could just take
> the last good release and go with that.
> >
> > Thanks,
> > Justin
>
>

Reply via email to