Wouldn't a separate repo make it even more difficult to associate build script changes to source code changes?
-=Bill On Mon, Jul 27, 2015 at 8:22 PM, Jake Farrell <jfarr...@apache.org> wrote: > 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 > > >
