Also +1
> On Jul 27, 2015, at 4:28 PM, Kevin Sweeney <kevi...@apache.org> wrote:
>
> +1
>
> On Mon, Jul 27, 2015 at 3: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
>>
