Hey folks, So great to send a mail to a list whose address includes both Zipkin and Apache :) Watch out, wall of text incoming. There's a lot of context here.
After reading the previous mail threads (still before the list), and some discussion with Andrew (whom Adrian introduced, and was a great help, are you here, Andrew?), I'm starting to have an outline of infrastructure-y things that need to happen. Most of these are pretty straightforward, and I'll try to capture existing stated preferences – do shout if I'm telling a lie. - *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. - 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. - 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. 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). *A question to mentors*: what other CI options are available under the ASF umbrella? Links to the various solutions or documentation for them would be especially appreciated, so we can evaluate them properly. *A question to OpenZipkin folks*: what's your current take on our CI setup? Here too, let me share the perspectives I've heard so far, call out any mistakes I make: - Travis sometimes has stability problems (more often than “rarely”, but more rarely than “often”, and more often than Circle) - Circle is somewhat more featureful and stable, but is severely limited in the number of free executors (and again, is not currently ASF-approved) - The less we need to care about CI, the better – that includes ongoing maintenance, mental / process overhead when making changes, and cost of any migration - This one's mostly from me: there's a lot of duplication between the build definitions of our various projects, not to mention the overhead of “supporting” both Travis and Circle. For example, I know Jenkins has standard tools to deduplicate parts of build definitions (namely, shared libraries for pipelines); I don't know of similar solutions for Travis (and am happy to be pointed at some / do more research). I'd say using a single CI system is more of a “when”, rather than a “whether” type of question. It then boils down to a trade-off between the cost of migration, and the perceived value of the new system. Some possible scenarios: - We decide to minimize the cost of migration, and move Circle builds to Travis. Later on, we might look into deduplicating build logic between jobs. - We push for ASF to accept CircleCI (note, with no guarantee of success at this point), including funding for more executors if needed (or try to start a collaboration with Circle so that ASF projects get more executors), and migrate Travis jobs to Circle. - We decide to maximize perceived value, by choosing a third option (non-Travis, non-Circle) that helps DRY our build definitions, while also keeping it easy to make per-project changes as needed. I'd recommend leading a project like this with a PoC and evaluating the results there, before migrating all N>10 projects and pouring effort into finalizing the shared abstraction layer. EOF wall of text. To recap, I'm super interested in what other CI options are available under ASF (so that we know what to even think about), any other recommendations our beloved mentors might have given all this, and preferences / arguments / corrections from Zipkin folks. Cheers! -- Zoltán Nagy https://abesto.net
