Hey Zoltan, I'm willing to help you strategize here, I think largely what we have won't need to change much. But see value from the formal release standpoint of making our process more Apache-esch. Please feel free to email me directly or start a doc of some kind (Google docs aren't available in China, which is why we haven't been using them). We have this repo https://github.com/openzipkin/zipkin-release if you'd like to prototype/discuss there?
Brian On Sun, Sep 9, 2018 at 5:39 PM Zoltán Nagy <[email protected]> wrote: > Thanks for the explanation and links. It indeed looks like we have homework > to do :) > > Is anyone already looking into all this? Please share your thoughts if you > are. Feels like there's more complexity here than what lends itself well to > ironing out over e-mail. Are we OK using GDocs to hammer out a proposal > (where there's real-time collaboration)? Or would we need to do that on > {c,} > wiki.apache.org? > > > It's worth noting that the incubator wants to see us doing the formal ASF > releases soon > How soon is “soon”? :) > I'm thinking it might make sense to do just enough research and planning to > get out a fully manual ASF release without messing up the opportunity to > “do things right” in the future. > My impression is we'd be focusing on getting out a proper ASF release now, > while figuring out the long-term release setup we want, and not doing any > more old-style releases – please correct me if I'm wrong on that. > > > On Fri, Sep 7, 2018 at 11:49 AM Mick Semb Wever <[email protected]> wrote: > > > > > > Re. releases: do you think it's necessary to gate the current “release” > > > automation behind code that somehow enforces community verification? > > > > No. My opinion is that the current automated releases of zipkin become > > something akin to nightlies, and the formal ASF releases come in addition > > when desired. > > > > > > > And > > > perhaps more importantly: current “releases” (let's start calling them > > > nightlies then) are uploaded to Bintray and Maven Central as stable > > > versions, and Docker images are built with them. > > > > This is a good question. > > > > AFAIK the main way of differentiating the formal ASF releases from the > > nightlies is what's announced publicly, ie on the zipkin.io website on > > its downloaded page. This is what's available to download from > > https://dist.apache.org/repos/dist/release/ > > > > We can't distribute nightlies via that url, as it is the formal apache > > downloads distribution space. > > > > But you can distribute dev/nightly artefacts from > > https://dist.apache.org/repos/dist/dev/ > > without going through the ASF release process. > > > > For maven one option could be to make the nightlies only accessible from > > the apache snapshots maven repository at > > https://repository.apache.org/content/repositories/snapshots/ > > > > Tiles took this approach, providing the following documentation to users: > > https://tiles.apache.org/framework/dev/snapshots.html > > > > And I don't think you are restricted to only publishing -SNAPSHOT > versions > > here, they could be timestamped snapshots, or normal semantic versioning. > > There's also terms like: alpha, beta, rc; that can be used. This is in a > > similar manner to how staging artefacts are made available, but don't > come > > with the offical seal of approval from the ASF and the Zipkin PMC. > > > > For more info on how maven is to be used at ASF see > > https://www.apache.org/dev/publishing-maven-artifacts.html > > > > I suspect we need to do a little homework, look at which other ASF > > projects are doing similar nightlies and how they do it. And then figure > > out what's best for Zipkin. > > > > It's worth noting that the incubator wants to see us doing the formal ASF > > releases soon, as it takes a few attempts for most podlings to get it > > right, and we should avoid giving the false impression that nightlies are > > being done to avoid the formal releases. > > > > More information on the formal ASF releases that we need to become > > familiar with: > > https://www.apache.org/dev/release-distribution > > https://www.apache.org/dev/release-publishing.html > > https://www.apache.org/legal/release-policy.html > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
