[OPEN-ILS-DEV] Cutting releases

[Thomas Berezansky]

For note, I believe we started packaging the binaries intentionally  
when we were having issues with Mozilla removing the downloads too  
often, preventing staff client builds from happening at all.

Thomas Berezansky
Merrimack Valley Library Consortium


Quoting Bill Erickson <berick at esilibrary.com>:

> On Thu, Jan 17, 2013 at 11:00 AM, Lebbeous Fogle-Weekley <
> lebbeous at esilibrary.com> wrote:
>
>> On Wed, Jan 16, 2013 at 11:43 PM, Dan Scott <dan at coffeecode.net> wrote:
>>
>>>
>>> [...]
>
>>
>> I thought the outcome of one of the last meetings was that we were going
>>> to adopt a more open security process, one that would enable community
>>> members to contribute towards testing?
>>>
>>>
>> Security releases seem to invoke our lizard brains, and we just act to get
>> these releases out fast.  We need to change that, and if we concretized
>> those ideas from the recent meeting, let's bring that document out front
>> and center to remind ourselves.
>>
>
> And more importantly to remind the community.  It occurred to me (after the
> fact) that we didn't do this yesterday because there was no way to explain
> to people why we were exposing sensitive security information without
> simultaneously providing a packaged fix.  Naturally, there is a lot of
> apprehension about this.  Let's get it into the doc [1] before next time so
> we can go forth with impunity.
>
> [1] http://evergreen-ils.org/dokuwiki/doku.php?id=dev:security
>
>
>
>>
>> Perhaps due to the lack of QA, our 2.2 and 2.3 tarballs once again
>>> contain the full xulrunner binary packages for both win32 and
>>> linux-i686, bloating their sizes by tens of megabytes. Bloat aside,
>>> for legal reasons it's generally not advisable to ship binaries
>>> from other projects if you can avoid it.
>>>
>>
>> By "once again" I can tell there has been a conversation about this
>> before, which I must have missed, but I was not aware of this problem at
>> all.  I agree, let's avoid packaging these binaries going forward.
>>
>
> Sounds like another make_release patch.
>
>
>>
>>
>>>
>>> I think our release processes need some work.
>>>
>>> Exhibit A: Even for a security release, we should be able to prep a
>>> git branch over in the security repo, cut a tarball from it, and
>>> then when the release is announced, just "git push origin
>>> security/rel_2_1_5:rel_2_1"
>>> so that the upstream release branch is a perfect replica of what went
>>> into the tarball.
>>>
>> Instead, at least for the rel_2_1 branch, two times today
>>> commits went into the rel_2_1 branch despite my having painstakingly
>>> prepped a complete branch over in the security repo last night (which
>>> also included commits from rel_2_1_4 that were missing from rel_2_1). I
>>> found that pretty frustrating, although I certainly overreacted today
>>> (probably due to staying up until 2:00 AM to prep the materials for the
>>> release and not getting enough sleep to act like a decent human being).
>>>
>>
>> Neither Bill nor I were aware of the importance of the perfect replica.
>>  We weren't trying to wreck your work, we just didn't understand that was a
>> thing.  We probably need further discussions, in IRC perhaps, to make sure
>> we understand the most correct way of structuring the tags in relation to
>> the release branch.  I'm also unclear on how we deal with the generated
>> ChangeLog that goes into releases, but presumably shouldn't go into the
>> rel_2_n branch.
>>
>
> Let's also not forget that we have the power to delay releases if some
> members of the release team will not be available.  I don't see any reason
> why RMs should be forced to cut releases at 2am.  Security releases are bad
> enough. Last minute dog piling and hungry hippo task grabbing is bound to
> get messy.
>
> -b
>
> --
> Bill Erickson
> | Senior Software Developer
> | phone: 877-OPEN-ILS (673-6457)
> | email: berick at esilibrary.com
> | web: http://esilibrary.com
> | Equinox Software, Inc. / Your Library's Guide to Open Source
>