zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zoltán Nagy <abe...@apache.org>
Subject Re: [VOTE] Release Apache Zipkin Brave Karaf (incubating) version 0.1.2
Date Sun, 10 Feb 2019 12:08:53 GMT
> however if there is something in the zip it should work.

Agree. I pretended to be a user with relatively little knowledge about the
internals here - with that hat on, I don't mind whether it's the itests or
whatever else that's failing, all I know is that `./mvnw package` should
give me something I can deploy.

> I will lightly look into how much logic we need in
> general to strip itests out completely.

Weak opinion: I like that tests are shipped with the release, so that (if I
use the source release) there's a last line of defense against badness. Not
to mention, this way tests are also run in an environment that's closer to
my production. Still, this is mostly academical - I expect 99% of our users
to use the binary convenience artifacts, so the point is somewhat moot.

> on a related note, it could be helpful to have Jenkins check our release
> tags

That should be simple enough to add, since in pipelines we can say stuff
like "when { tag "release-*" }" where the wildcard is an Ant-style
wildcard. At the same time: since tags for us are always on master, I
mostly expect this to add no additional value, since we already run tests
on master pushes. Since tests on CI passed on the commit you tagged for the
release, I expect the error to be somehow introduced by the packaging
process. In that case we'd want to run tests against the RC source
artifacts - this also shouldn't be too hard to add, but would probably be
best to set up as a job that's manually triggered against a specific zip
once it's uploaded (consider: we can automatically trigger on tags, but
more likely than not, the release at that point hasn't been uploaded to the
ASF dev repo yet). At that point this is "just" a convenience / extra
safety net, since voting PMC members will do this check locally anyway.

On Sun, Feb 10, 2019 at 10:38 AM Adrian Cole <adrian.f.cole@gmail.com>
wrote:

> thanks zoltan. we dont deploy the itests so probably dont generally need to
> validate them for ASF reasons. however if there is something in the zip it
> should work. I will look into this to see if it is failing because it
> should fail or not. also I will lightly look into how much logic we need in
> general to strip itests out completely.
>
> on a related note, it could be helpful to have Jenkins check our release
> tags (mvnw install not deploy) so that we know the actual code still works
> (vs a distribution of it)
>
> On Sun, Feb 10, 2019, 5:20 PM Zoltán Nagy <abesto@apache.org wrote:
>
> > Confirming we're now in a better state:
> >
> > * GPG signature and SHA512 of the artifact check out. I expected to also
> > see a signature for the checksum, but
> > https://www.apache.org/dev/release-distribution doesn't mention that,
> so I
> > think we're fine.
> > * Confirming base dir is now non-confusing :)
> > * Code in release matches code at commit 4c28076fd
> > * `./mvnw compile` succeeds (note: the license checker Maven plugin
> > complains for about a screenful about failing to find the latest git
> > commit, but this doesn't fail the build)
> >
> > However, I'm still -1:
> >
> > * `./mvnw package` fails both on my macOS and Windows Linux Subsystem
> > environments: io.zipkin.brave.itests.BraveTest fails with
> > java.lang.ClassNotFoundException for zipkin2.reporter.Sender. Gist of
> > relevant Maven output:
> > https://gist.github.com/abesto/632f7e7e515de2adb9b3ba04d7606659
> >
> > On Sun, Feb 10, 2019 at 4:10 AM Adrian Cole <adrian.f.cole@gmail.com>
> > wrote:
> >
> > > sorry I forgot to mention that GPG asc files weren't there because I
> > > used the old "release" profile not the "apache-release" one. I've
> > > removed the old profile to remove confusion as it is no longer used
> > > anyway
> > >
> > > On Sun, Feb 10, 2019 at 5:08 AM Adrian Cole <adrian.f.cole@gmail.com>
> > > wrote:
> > > >
> > > > OK all should be resolved now. The new git hash is
> > > > 4c28076fd617f4896cae77e773de7090bcebe6b4
> > > >
> > > > All other locations etc should be the same. Here is a summary of
> > > glitches fixed:
> > > >
> > > > * zip wasn't named correctly I formerly manually fixed it. Now that's
> > > automatic
> > > > * zip basedir wasn't intuitive. it is now brave-karaf-$version
> > > > * we accidentally published itests, now we don't
> > > > * dummy release notes didn't explain this was only a canary release
> > > >
> > > > There was no code change only build script stuff.
> > > >
> > > > -A
> > > >
> > > > On Sat, Feb 9, 2019 at 10:38 PM Jorge Quilcate <
> > quilcate.jorge@gmail.com>
> > > wrote:
> > > > >
> > > > > +1
> > > > >
> > > > > On 2/9/19 2:30 PM, Adrian Cole wrote:
> > > > > > agreed the release notes link is empty. I didn't go through
the
> > > formality
> > > > > > of making release notes for 0.1.2
> > > > > >
> > > > > > On Sat, Feb 9, 2019, 9:19 PM Brian Devins-Suresh <
> > badevins@gmail.com
> > > wrote:
> > > > > >
> > > > > >> +1
> > > > > >>
> > > > > >> Are release votes not supposed to include some synopsis
of the
> > > changes? I
> > > > > >> know this is a first release within the incubator but it
might
> be
> > > good to
> > > > > >> just call that out?
> > > > > >>
> > > > > >> On Sat, Feb 9, 2019 at 6:41 AM José Carlos Chávez <
> > > jcchavezs@gmail.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >>> +1
> > > > > >>>
> > > > > >>> Den lør. 9. feb. 2019, 11:36 skrev Adrian Cole <
> > > adrian.f.cole@gmail.com:
> > > > > >>>
> > > > > >>>>> I can't find the GPG signature for the artifact
and the
> > > checksum. I'm
> > > > > >>>>> looking at
> > > > > >>>>>
> > > > > >>
> > >
> >
> https://dist.apache.org/repos/dist/dev/incubator/zipkin/brave-karaf/0.1.2/
> > > > > >>>>> ,
> > > > > >>>>> and am expecting to see two .asc files, and
am not seeing
> any.
> > > Am I
> > > > > >>>> looking
> > > > > >>>>> in the wrong place?
> > > > > >>>>>
> > > > > >>>> no that is the right place. I must have missed something.
the
> > > stuff
> > > > > >> asked
> > > > > >>>> me for my GPG password so something must have gotten
lost.
> will
> > > report
> > > > > >>>> back.
> > > > > >>>>
> > > > > >>>> The folder contained in the source zip is called
> > > > > >>>>> "brave-karaf-parent-0.1.2". I'd expect it to
be just
> > > > > >>> "brave-karaf-0.1.2".
> > > > > >>>>> (Quite possible I'm just missing some Java ecosystem
> knowledge
> > > and
> > > > > >> this
> > > > > >>>> is
> > > > > >>>>> fine).
> > > > > >>>> I think this is also valid. Let me look into customizing
the
> > > artifact
> > > > > >>>> basedir. It is inheriting this from the aggregator
(base
> > pom.xml)
> > > which
> > > > > >>> we
> > > > > >>>> intentionally name different as often the actual
lib is called
> > > > > >> something
> > > > > >>>> like brave-karaf
> > > > > >>>>
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > 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
> > >
> > >
> >
>

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