zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mick Semb Wever <>
Subject Re: Infrastructure setup / CI
Date Fri, 07 Sep 2018 06:23:16 GMT
Hi Zoltán,
 I'll do my best to answer your questions, inline.

>    - *Git repository hosting*. OpenZipkin people AFAIK would prefer staying
>    on GitHub if at all possible. This would imply setting up syncing to ASF
>    git hosting. seems to be a solution to this
>    whole can of worms, though I didn't look too deeply yet.

ASF hosts git repositories in two different ways:
 - gitbox
 - asf git repositories

The latter are only sync'd to github, ie you can't push to the github repo.
An example of this is Cassandra.

Gitbox maintains two repositories in sync, and you can push to either. One exists at ASF,
the other at GitHub under the apache organisation.
For example:

Zipkin will want the GitBox approach. And the proposal implies this under
> "Required Resources ––> Git Repositories"

This means that Zipkin's existing github repositories will need to be moved to
and with repository names that are prefixed with "incubator-"

See SkyWalking's equivalent ticket: SkyWalking:

More info at

>    - Release automation may need to be extended for the required *voting
>    process* – or maybe just leave it up to human process, don't change the
>    automation.

First up, there's a terminology mismatch on what "release" means to Zipkin and what it means
to the ASF.

Zipkin's releases are frequent and automatic. The are not what ASF means as releases. A closer
concept would be nightly builds.

ASF releases are more formal releases. These are carefully constructed and tested cut releases,
that provide the community a few days to test, and then a few days to vote upon. All legalities
(digest, gpg signatures, etc) are sound, etc etc.

The Apache Incubator expects to the community make such formal releases, but like once a month
or so, not anywhere near the current Zipkin release cycle.

As far as I've understood from conversations with Adrian, the best approach forward we presume
is to make Zipkin's current releases into something more akin to nightly builds (and stop
referring to them as releases), and to every now and again when there's a build that the community
deems should be announced formally to the world go through the formal ASF release process.

>    - We'll need to set up *automated notification e-mails* about commits,
>    releases, that kind of stuff. For commits, it should come out of the box
>    with the Git setup, and should be easy to add to the release automation.
>    This is probably best done with a separate notifications@ list.

I believe that all happens automatically.
If not, make a request to INFRA (by opening an INFRA jira ticket).

> Now for the hard part: *CI*. Travis seems to be supported by ASF, but
> CircleCI is not, and various OpenZipkin projects currently use one, the
> other, or even both. ASF apparently also has a hosted Jenkins server (which
> I can't find ATM).

The ASF provides a dedicated CI at
This is jenkins.

Whether you want to use this or not is optional.
We're free to use CircleCI or Travis.

My opinion is the more the merrier. As Adrian mentions some of these can be flakey at times,
so there's an advantage to using multiple despite the cost.

The ASF can be really useful for longer running integration tests.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message