zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <willem.ji...@gmail.com>
Subject Re: [VOTE] Release Apache Zipkin Brave Karaf (incubating) version 0.1.2
Date Mon, 11 Feb 2019 03:41:42 GMT
It's always good to have checklist to help others to verify the kits.
But it could save us some time if we have a script to do the most of
the job automatically, specially we have bunch of projects need to go
through this kind of process.


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Feb 11, 2019 at 10:24 AM Adrian Cole <adrian.f.cole@gmail.com> wrote:
>
> I don't think you are being a pain, rather I think we should be clear
> about where to maintain our build instructions. I think we should
> emulate projects like dubbo or zipkin which have a place for all the
> steps (not just how to execute mvn test). This is better IMHO than
> placing things in each repo individually then having to sync those.
> Right now, borrowing dubbo's is fine and bear in mind many projects
> haven't even documented a step-by-step at all. As long as we are able
> to do our work, we are good.
>
> Frankly, we have no reason to have to now start documenting how to use
> maven even for ourselves. We only need 3 people to +1 something. We
> have a community large enough that we have far more than 3 people who
> know how to use maven. That said, it is a convenience in Dubbo's
> step-by-step to list literally the command. you'll notice they are
> also extremely verbose in instructions even saying how to use the sha
> command! We need to find our place and I don't think it is required or
> advisable for us to push requirements further than status quo
> especially on our first release and while we are in the incubator.
>
> On Mon, Feb 11, 2019 at 3:18 AM Tommy Ludwig
> <tommy.ludwig.csjf@gmail.com> wrote:
> >
> > In short: Until/unless someone in an official capacity (mentor/IPMC) says
> > we need build instructions in source, I'm fine to proceed without. I think
> > it would be nice to be self-documenting and unambiguous even for our own
> > sake, but I also fully agree we don't want to make a support burden for
> > ourselves, which we have seen happen in the past by too many people trying
> > to build from source.
> >
> > In long:
> > I don't want to support anyone trying to build from sources when they don't
> > need to be (i.e. they aren't trying to contribute code changes). However, I
> > question whether that's an acceptable position to take given the current
> > state of Apache, which only recognizes source releases as official
> > releases. There is no such thing as an official binary release; there are
> > only convenience binary releases made from official source releases. Yes, I
> > want consumers of our projects to only use already packaged/distributed
> > artifacts, and I want the build/source to be a detail left to
> > maintainers/contributors. As mentioned in other threads on general@incubator,
> > this kind of issue keeps coming up since the rules and what projects
> > practically want to do seem to be at odds.
> >
> > Even so, each binding voter that casts a vote in any release is required
> > [0] to download the sources, "compile as provided, and test the result on
> > their own platform." So even just for us, we need to make sure everyone is
> > on the same page about what to actually do once downloading the sources for
> > a release before voting. If everyone (current and future PPMC members) know
> > what standard Maven commands that correlates to and we make all projects
> > work with the same standard commands, then it is probably fine without
> > explicit instructions. That seems like a lot of ifs to me, though.
> >
> > I'd also note that Dubbo's blog post [1] previously shared includes
> > specific commands to run under the section "Verify Release Candidates",
> > like `mvn clean test`. I've also seen for Maven release verification, they
> > go so far as to run manual integration tests by using the binary they built
> > from release candidate sources to build various Maven projects. I'd rather
> > automate such testing as much as we can, but we need to understand and
> > agree on what the requirement "test the result on their own platform" means
> > for Zipkin projects.
> >
> > Sorry if I'm being a pain with all this. I'm just trying to make sure we
> > follow the rules as I understand them, even if I also think they're due for
> > some overhaul. Especially since this is our first release. If we get all
> > the things figured out with this one, I think the rest should be very
> > smooth.
> >
> > [0] http://www.apache.org/legal/release-policy.html#release-approval
> > [1]
> > https://dubbo.incubator.apache.org/en-us/blog/prepare-an-apache-release.html
> >
> > On Mon, Feb 11, 2019 at 9:22 AM Adrian Cole <adrian.f.cole@gmail.com> wrote:
> >
> > > TL;DR; ./mvnw test is probably all we need to do in order to verify
> > > the release from a process POV (same as Dubbo). I don't think that
> > > warrants a special additional file. In fact the reason I re-did the
> > > release last night was to make sure it wouldn't :P
> > >
> > >
> > > The reason I'm hesitant on adding another instruction file is that "no
> > > good deed goes unpunished". What I mean by this is that promoting that
> > > this is the official source does not imply we should lead people into
> > > using that directly. I'm concerned that adding an additional file,
> > > something that isn't commonly included at least in projects I've been
> > > involved with, will set a precedent of yet another support burden. For
> > > example.. I tried to run your build to do X and Y happened. Then, we
> > > get to figure out if someone monkeyed with the code or not.
> > >
> > > Instead, I think we should promote the official binary releases and
> > > those things derived from them (ex in the case here there is nothing,
> > > but in zipkin itself, the server would be a great example). Having a
> > > special instruction file and only referencing how to build from
> > > source, in other words.. seems destined to land on others, maybe
> > > people not in this mail thread yet (future maintainers). That's why I
> > > prefer (even if we weren't talking about brave-karaf) to leave it out.
> > >
> > > When I mentioned the commands that Zoltan used, I was mentioning them
> > > for completeness. I don't think people in normal circumstances will
> > > want to download our source dist for the sole purpose of building the
> > > source dist from within it :P This is a verification step I'm not even
> > > sure other apache projects do. It isn't listed on the few READMEs I've
> > > seen.
> > >
> > > Does this make sense?
> > >
> > > -A
> > >
> > > On Mon, Feb 11, 2019 at 12:30 AM Adrian Cole <adrian.f.cole@gmail.com>
> > > wrote:
> > > >
> > > > Do you know an example of any apache project that has a second variant
> > > of a README for this purpose?
> > > >
> > > > I still think we shouldn't be adding more steps than others are doing.
> > > There is absolutely nothing unique about using maven compile or package
> > > goal. it is default.
> > > >
> > > > On Sun, Feb 10, 2019, 10:46 PM Tommy Ludwig <tommy.ludwig.csjf@gmail.com
> > > wrote:
> > > >>
> > > >> I think it would be best if we have a README file in the source that
> > > >> includes instructions on how to build. Someone downloading the source
> > > >> release should ideally be able to learn how to build that release
from
> > > the
> > > >> included sources, IMO. At least this is my interpretation of the Apache
> > > >> way. It would ensure that if the instructions for how to build the
> > > project
> > > >> change, we don't need to keep a history separately (e.g. in a Wiki)
> > > since
> > > >> the instructions included in the release should always be correct
for
> > > that
> > > >> release and would be tested by the PMC during release voting.
> > > >>
> > > >> On Sun, Feb 10, 2019 at 11:09 PM Adrian Cole <adrian.f.cole@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > OK all: the new git SHA is 31545805a55dbe5e495403d84172fc865a4935e0
> > > >> >
> > > >> > Lesson learned is that we should be specific about how precisely
to
> > > >> > test things, and that RMs (me in this case) should attempt those
> > > >> > things in a completely clean env (ex nuking all the caches).
> > > >> >
> > > >> > Towards that end, beyond the usual apache stuff. If you want
to test
> > > >> > the contents themselves, execute basically the same stuff as
dubbo
> > > >> > mentions in their "Verify Release Candidates" section. We have
the
> > > >> > same requirements as they do, but they already have a TODO list.
We
> > > >> > can make one like this later I guess.
> > > >> >
> > > >> >
> > > >> >
> > > https://dubbo.incubator.apache.org/en-us/blog/prepare-an-apache-release.html
> > > >> >
> > > >> > I don't know if we restart the 3 days now or not.. it doesn't
really
> > > >> > matter as no-one is blocking on this 0.1 release. Anyway, appreciate
> > > >> > in advance those who are up to practicing verifying a release!
> > > >> > -A
> > > >> >
> > > >> > On Sun, Feb 10, 2019 at 2:13 PM Adrian Cole <adrian.f.cole@gmail.com>
> > > >> > wrote:
> > > >> > >
> > > >> > > Thanks for understanding, Zoltan. FWIW, the test in question
had the
> > > >> > > incorrect naming convention for an integration test. Tommy
noticed
> > > >> > > that it should have never run in the package phase anyway.
This
> > > >> > > corrects that:
> > > >> > https://github.com/apache/incubator-zipkin-brave-karaf/pull/28
> > > >> > >
> > > >> > > On Sun, Feb 10, 2019 at 1:35 PM Zoltán Nagy <abesto@apache.org>
> > > wrote:
> > > >> > > >
> > > >> > > > Vote: +1
> > > >> > > >
> > > >> > > > Yeah in general I'd say trust that CI has already verified
we're
> > > OK,
> > > >> > and
> > > >> > > > don't run integration tests on package / install in
the released
> > > >> > artifacts.
> > > >> > > > Good point about Docker as well. I've just tried `./mvnw
package`
> > > on a
> > > >> > > > clone from git - first run passed, then the second
one failed
> > > with the
> > > >> > same
> > > >> > > > error as the source release. I'm ready to let this
go as "finicky
> > > >> > > > integration tests".
> > > >> > > >
> > > >> > > > The release is Good Enough (TM) as is IMHO, assuming
we provide
> > > some
> > > >> > > > command-line to package it up without running the integration
> > > tests. Of
> > > >> > > > course it'd be even nicer if users didn't even have
to do _that_,
> > > but
> > > >> > let's
> > > >> > > > not block the release on this.
> > > >> > > >
> > > >> > > > Note on stripping itests from the source release: ideally
that'd
> > > be
> > > >> > done
> > > >> > > > without modifying the code-base, since one of the steps
pre-vote
> > > is
> > > >> > > > verifying that the code in the release is actually
the code in the
> > > >> > cited
> > > >> > > > commit hash - release-time code modification makes
that harder
> > > (though
> > > >> > not
> > > >> > > > impossible, the difference should be trivial in any
case). I
> > > _guess_
> > > >> > that'd
> > > >> > > > mean making package / install / whatever not run itests,
and
> > > adding
> > > >> > itests
> > > >> > > > to CI explicitly, but as it's been proven several times,
I only
> > > have
> > > >> > > > superficial knowledge of Maven, so I'll stop trying
to guess here.
> > > >> > > >
> > > >> > > > On Sun, Feb 10, 2019 at 12:13 PM Adrian Cole <
> > > adrian.f.cole@gmail.com>
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > > FWIW the build worked on my laptop. it might be
an environment
> > > >> > nuance.
> > > >> > > > > Karaf itests are sensitive, and so for example
end users
> > > shouldn't
> > > >> > > > > require anything delicate. For example, would
you fail a build
> > > >> > because
> > > >> > > > > a user can't install docker that's a prereq? We
are only
> > > vetting code
> > > >> > > > > I think we should step back from signing ourselves
up to make
> > > every
> > > >> > > > > potential user able to run all the myriad of integration
tests
> > > >> > > > > possible in our environments.
> > > >> > > > >
> > > >> > > > > On Sun, Feb 10, 2019 at 1:09 PM Zoltán Nagy <abesto@apache.org>
> > > >> > wrote:
> > > >> > > > > >
> > > >> > > > > > > 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
> > > >> > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > >
> > > >> > > > > > >
> > > >> > > > >
> > > >> > > > >
> > > ---------------------------------------------------------------------
> > > >> > > > > 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
> > >
> > >
>
> ---------------------------------------------------------------------
> 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
View raw message