zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mick Semb Wever <m...@thelastpickle.com>
Subject Re: calling our mentors and champion to action (brave-karaf release)
Date Thu, 14 Feb 2019 05:13:07 GMT
It's normal for graduate projects to cancel releases.
I see releases often cancelled or vetoed.

Although, in a graduate project it typically will not be process or legal
issues. Rather it will be bugs identified (caused by the release or newly
found).

In the incubator the first release attempt rarely makes it through. There's
a lot of minor legal details to get right. Fortunately these things are a
one-off exercise.

Sorry for being MIA on this stuff, and congratulations on the work and
progress you done so far!

regards,
Mick


On Mon, 11 Feb 2019 at 18:00, Adrian Cole <adrian.f.cole@gmail.com> wrote:

> OK I restarted the vote after writing this wiki. Please edit as you
> see fit. Also, I think we should be allowed to automate most of this
> even if still required to execute on a real person's workstation
>
> https://cwiki.apache.org/confluence/display/ZIPKIN/Verifying+a+Source+Release
>
> On Mon, Feb 11, 2019 at 4:38 AM Willem Jiang <willem.jiang@gmail.com>
> wrote:
> >
> > Hi Adrian,
> >
> > If you want to CANCEL the vote, you can send a mail to close it and
> > start a new thread once you finish the second cut.
> > It's a normal practices for our first around release.
> >
> > I think you did a great job on the release. I'm around if you want to
> > ask for help.
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Mon, Feb 11, 2019 at 11:02 AM Adrian Cole <adrian.f.cole@gmail.com>
> wrote:
> > >
> > > Hi, folks.
> > >
> > > We just tried to do a release of brave-karaf, but I think we realized
> > > that many of us have no experience or no recent experience in ASF
> > > releases. Some were giving +1s without doing any verification
> > > whatsoever, and others possibly asking for more than required to pass
> > > the release. First release was going to be bumpy, so no big deal.
> > > However, I think there's some more to it.
> > >
> > > I think some confusion was caused due to the various incubator mailing
> > > list discussions. Some are calling out projects for not doing things
> > > right, and some are not clarified on topics about source vs binary
> > > etc. The way I perceive these discussions are just that.. discussions.
> > > I don't think we have to hold ourselves to standards higher than
> > > graduated project (standard of practice). However, I think if this is
> > > a valid interpretation, a mentor should step up as sometimes the
> > > language in these discussions is distracting (ex blamey phrasing
> > > happened in those threads and is strong language for an evolving
> > > process especially around github).
> > >
> > > During our own release, we wandered, possibly into the correct
> > > corners, but some topics feel more like guessing what we should do
> > > than people knowing they need to. Lacking guidance, personally I
> > > looked at a couple projects, jclouds and dubbo, and arbitrarily chose
> > > the latter as the docs were polished.
> > >
> https://dubbo.incubator.apache.org/en-us/blog/prepare-an-apache-release.html
> > > This doesn't mean they were right, but seems they are right enough.
> > > Maybe we can be right enough, too, as re-releasing and
> > > meta-discussions are taxing timewise and emotionally.
> > >
> > > The main thing here is I think we should have not started without a
> > > mentor present to help navigate these topics.
> > >
> > > The short of it is, that as a RM, I'd like to re-start the release
> > > vote to clean the slate. I think that involves a "CANCEL" process
> > > which I'll look up. However, I'd like a mentor to both be present for
> > > questions and also participate in verifying the release and voting.
> > > So, if someone can reply with their availability, I'm happy to
> > > continue this and learn how to make the next one smooth.
> > >
> > > Best,
> > > -A
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> > > For additional commands, e-mail: dev-help@zipkin.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> > For additional commands, e-mail: dev-help@zipkin.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> For additional commands, e-mail: dev-help@zipkin.apache.org
>
>

-- 
Mick Semb Wever
Australia

The Last Pickle
Apache Cassandra Consulting
http://www.thelastpickle.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message