aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sweeney <kevi...@apache.org>
Subject Re: [PROPOSAL] Source releases vs artifact releases
Date Mon, 27 Jul 2015 23:28:03 GMT
+1

On Mon, Jul 27, 2015 at 3:40 PM, Bill Farner <wfarner@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
>

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