aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Farner <>
Subject [PROPOSAL] Source releases vs artifact releases
Date Mon, 27 Jul 2015 22:40:20 GMT
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.




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!


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message