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 <[email protected]>:
On Thu, Jan 17, 2013 at 11:00 AM, Lebbeous Fogle-Weekley <
[email protected]> wrote:
On Wed, Jan 16, 2013 at 11:43 PM, Dan Scott <[email protected]> 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: [email protected]
| web: http://esilibrary.com
| Equinox Software, Inc. / Your Library's Guide to Open Source
