aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Smith <>
Subject Re: [PROPOSAL] Source releases vs artifact releases
Date Mon, 27 Jul 2015 23:56:20 GMT
Also +1

> On Jul 27, 2015, at 4:28 PM, Kevin Sweeney <> wrote:
> +1
> On Mon, Jul 27, 2015 at 3:40 PM, Bill Farner <> 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]
>> 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
>>> 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

View raw message