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. https://gitbox.apache.org/ 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: - https://gitbox.apache.org/repos/asf?p=incubator-skywalking.git - https://github.com/apache/incubator-skywalking 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 https://github.com/apache/ and with repository names that are prefixed with "incubator-" See SkyWalking's equivalent ticket: SkyWalking: https://issues.apache.org/jira/browse/INFRA-15649 More info at https://reference.apache.org/committer/github > - 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 builds.apache.org 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 builds.apache.org can be really useful for longer running integration tests. regards, Mick --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
