Skip to Content.
Sympa Menu

sm-commit - Re: [SM-Commit] GIT changes to master grimoire by George Sherwood (292a7f9e7d77105c79938a66282c13e69f097bb0)

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-commit AT lists.ibiblio.org
  • Subject: Re: [SM-Commit] GIT changes to master grimoire by George Sherwood (292a7f9e7d77105c79938a66282c13e69f097bb0)
  • Date: Mon, 5 Mar 2007 22:34:29 -0600

On Mar 05, Arwed von Merkatz [v.merkatz AT gmx.net] wrote:
> On Mon, Mar 05, 2007 at 12:00:58PM -0800, Eric Sandall wrote:
> > Quoting George Sherwood <pilot AT beernabeer.com>:
> > <snip>
> > > I know, I just wasn't sure if it was worth it. I only saw the problem
> > > reported one time and I have never seen it myself when using firefox as
> > > a GECKO provider. Guess no good answer, I can see it both ways.
> >
> > Currently I'm trying the fix on my stable grimoire box as
> > mplayerplug-in could not find firefox-plugin (nor seamonkey-plugin or
> > xulrunner-plugin, but I do not have the latter two installed). I
> > assume that the sedit fixes this problem, but will report back on
> > whether it does or not.
>
> It probably does, only firefox 2.0.x has this nspr requirement in that
> pkgconfig file, all others use $GECKO-xpcom, which in turn has the
> (sedited) correct requirement for mozilla-nspr.
>
> > Even if it doesn't, changes to installed files or changes to their
> > locations should use a PATCHLEVEL, IMO. ;)
>
> Agreed. Those of us with really slow boxes usually check for why an
> update to big stuff is required before blindly running the update anyway
> ;)

I really would ask that we think this over again in light of people who are
running smgl not just on a workstation or one or two servers. In small
setups it's feasible to know what's waiting in your queue and why you're
waiting on some things, but the more boxes you have the less doable that
is, especially if the list starts to differ between boxes.

I have a couple dozen boxes on SMGL, in at least 5 locations. Manageable
updates on those means automating them. I currently do this by having a
tiered structure where master update servers in different locations pull
down the grimoires, then other boxes in that location get them from the
masters. Every day any boxes that have updates queued complain to me about
it. This isn't ideal, but it's what I have until I get things to the point
where each box just uses my own vetted grimoire and casts updates from this
as soon as it gets them.

Regardless, *every time* new updates show up, I have to go out and
test-cast them on at least 2 pre-production boxes, make sure nothing
breaks, then start pushing them out to other nodes. The more often things
show up, the harder it is to have the time to verify them and get them out
there, and the more likely things are to get skipped.

Of course I'm fine asking for recompiles on upstream version updates or
security updates or for things that are significant and just plain broken;
this is how it goes. But pushing for unnecessary recompiles to fit some
definition of "clean build" that we happen to have, or for things that may
be broken in some (documented) minority of cases is annoying to people that
have large install bases. Assuming we want to promote people having large
install bases, we need to consider this.

Note: it's not a response to say "just skip the small updates". A large
update queue is a large update queue, and I can't ignore it because I'm
likely to miss something important if I just get used to ignoring it. And
I can't just trust an update claimed to be trivial in impact is safe to
push without testing; I have to do my job and verify them. The only "just
skip it" option I could entertain would be something that let me
queue-critical or queue-nontrivial or something, but that begs the question
of why trivial things really have to force an update.

Also, this isn't the only update issue we have for production environments,
many of which will only even consider pushing non-critical patches to
production once a quarter or once every 6 months. But it's currently one
of the more visible.

Attachment: pgpiRYB8wwjM0.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page