In order to make this repeatable it might be good to split this off entirely into its own aurora-packaging repo. If its still in the main repo then when we create the release branch the packaging source will still be in the new release branch, but the packaging code would not necessarily line up with that given branched release (like we have currently for the 0.9.0 branch). For people checking out the release branch and not the source distribution this would be more confusing.
To eliminate this potential guessing game and expanding on Bill's proposal I would advocate for us to make the packaging its own repo, aurora-packaging, and add a set of docker files so we can automate the build of the given release deb/rpm's and script the process for creating tags for each 0.9.0-1.rpm or 0.9.0-2.deb ... -Jake On Mon, Jul 27, 2015 at 6: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 >
