+1 On Mon, Jul 27, 2015 at 3:40 PM, Bill Farner <wfar...@apache.org> wrote:
> Hi folks, > > An issue that we have not yet officially addressed is release management as > it pertains to binary artifacts we produce of Aurora. Today, when we cut a > release, say 0.9.0, we essentially take a snapshot of (most of) our > repository as a basis for voting and eventual distribution. > > An outstanding question thus far has been how a release is affected when we > need to change scripts and configurations for binary distributions [1] to > produce a working binary artifact. By some standards, a bug fix to an RPM > spec might require another official source release/vote. > > I've had several useful discussions with Jake Farrell about this, and we > brought the discussion to the asfinfra hipchat room to hopefully get some > quick guidance from someone on the ASF board. Please see the quote below > if you would like to see the transcript. > > The summary is that the board allows us to produce binaries as we see fit, > as the ASF does not consider them official releases. As such, i propose > that we treat build-support/packaging as distinct from the sources we vote > on for a source release. I further propose that we omit > build-support/packaging from our source distributions. This will make it > clear that they are not part of what we are voting on when we cut a > release. > > With this distinction, i would like for us to adopt the practice of > considering binary distributions 'downstream' from source distributions, > and bug fixes to packaging do not require a new source distribution > release. > > > Cheers, > > Bill > > > [1] > > https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=tree;f=build-support/packaging;h=c77d9b8ab2d8e6ecea2d8028bcdb250239240ffe;hb=HEAD > > Jake Farrell 12:03 PM > > question for the greater audience about packaging, we just cut and rc and > > voted on it, successfully passed. as part of the src release was code to > > create deb and rpm packages. went to cut the rpm's to vote on bin > artifacts > > and there is a bug in the rpm spec > > > > Daniel Gruno (Humbedooh) 12:04 PM > > burn and reroll? :) > > > > Jake Farrell 12:05 PM > > would the recommendation be to cut a new rc or would having the deb/rpm > > packaging code in separate repo on its own release be more in line. i.e., > > package 0.1.0-2.rpm in packaging land > > > > Daniel Gruno (Humbedooh) 12:07 PM > > you could cut a new release and bypass the 72h rule > > > > Bill Farner 12:09 PM > > a goal i'm seeking with this is to decouple source release from binary > > releases, if possible. that way we don't have things like releases for N > > distros that are no-ops because we fixed something in 1. it also means > that > > we don't have source releases that have no binary releases because of a > > packaging spec bug > > we're currently in the latter situation - we have a perfectly fine 0.9.0 > > src release. however, it turns out there's trivial cruft in packaging > specs > > requiring a post-0.9.0 commit to generate working binaries (key detail - > > commit that does not touch the source) > > > > Daniel Gruno (Humbedooh) 12:12 PM > > aren't binaries still viewed as "unofficial convenience"? > > iow you can do what you like to it, 'cause it ain't ours > > > > Tony Stevenson ( pctony ) 12:13 PM > > AIUI, yes > > but $AOO etc > > > > Daniel Gruno (Humbedooh) 12:13 PM > > @rbowen you're a board pony, what say you? > > > > Tony Stevenson ( pctony ) 12:13 PM > > neeeighhhhh > > > > Daniel Gruno (Humbedooh) 12:13 PM > > apart from neigh, that is > > > > Rich Bowen 12:13 PM > > Hmm. What? > > > > Daniel Gruno (Humbedooh) 12:14 PM > > bill has a question on ASF binary release policy > > > > Bill Farner 12:14 PM > > details in scrollback, let me know if i've worded poorly :-) > > + Jake's context a few messages before > > concrete example: this line in our rpm spec is incorrect > > > https://github.com/apache/aurora/blob/master/build-support/packaging/rpm/aurora.spec#L188 > > fixing it does not alter what i'd consider the source code of the > project, > > just the tooling to assemble those sources > > > > Daniel Gruno (Humbedooh) 12:18 PM > > personally, I would favor burning the release and cutting a new with a > > speed vote > > so that people building from source can generate rpms as well > > > > Rich Bowen 12:19 PM > > I'm not certain what the policy would be in this specific case, since > > binary releases aren't official releases for anybody but OO, but I would > > say that if there's a question, you cut another release and fasttrack the > > vote to put it out there, and eliminate any question. > > Which ... appears to be what @Humbedooh just said. > > > > Daniel Gruno (Humbedooh) 12:20 PM > > 72 hour rule can be voided (under pain of Greg's fists if you do > something > > bad) > > > > Bill Farner 12:20 PM > > so for the end-user, that seems to mean people on different distros could > > have identical software, but be many releases apart if we had to iterate > on > > one distro's packaging > > if so, that scenario seems unfortunate for users > > (or they could be on the same distro for that matter) > > > > Daniel Gruno (Humbedooh) 12:21 PM > > in the end, you can pick whichever solution you want. As @rbowen said, > > binaries are not officially ours, but yours > > > > Bill Farner 12:24 PM > > that's good to hear. it's probably best that we remove our rpm/deb > tooling > > from our source distributions to make the separation more clear > > thanks for the insight! > > > > -=Bill >
