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: Eric Sandall <eric AT sandall.us>
  • To: sm-commit AT lists.ibiblio.org
  • Subject: Re: [SM-Commit] GIT changes to master grimoire by George Sherwood (292a7f9e7d77105c79938a66282c13e69f097bb0)
  • Date: Tue, 6 Mar 2007 17:32:41 -0800

On Monday 05 March 2007 20:34:29 Jeremy Blosser wrote:
> 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.

Please define "unnecesary" then. mplayerplug-in would not build on my box
without this fix, and I assume on other people's as well (since it also broke
someone else's). In my opinion, all spells should be installed and working
for any case we know about and can fix. To put it simply, the user should
*never* have to do any work other than `cast SPELL` and accept the defaults
to have a spell installed. I *never* want to hear, or have as a 'normal'
procedure, developers or users telling someone to recast a package to get the
fix. This should already have been taken care of for the user.

-sandalle

--
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/ | http://counter.li.org/ #196285

Attachment: pgpG_P06OIGv6.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page