Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

On Tuesday 06 March 2007 18:49:15 Jeremy Blosser wrote:
> Moving this to -discuss...
>
> On Mar 06, Eric Sandall [eric AT sandall.us] wrote:
> > 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:
> > > > > 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.
> >
> > 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.
>
> I disagree.  It's not at all unusual for people to hear they need to apply
> a patch or upgrade to get a fix for a problem they encounter, and people
> don't mind it, especially for things that aren't universal problems.  If we
> were a distro of hand-holding I'd see an argument that it's imperative we
> push updates more aggressively than everyone else, but we quite
> categorically aren't such a distro.
>
> There is a balance point between "make it work for people" and "don't push
> excessive updates at people that don't need them".  Usually you have to
> weigh the relative sizes of the groups affected.  No doubt this particular
> firefox fix was needed for anyone that wanted to use mplayer-plugin, but do
> the majority of our firefox users use mplayer-plugin?  Firefox is a beast
> of a compile, as are some other things we are aggressive about pushing
> PATCHLEVEL for, and it's feasible we hit a point somewhere where we're
> asking users at a certain hardware spec to be compiling things around the
> clock to keep their queue empty.  People have a hard enough time keeping up
> with patching on binary distros; as much as a source distro stretches the
> patch application time out, we need to be aware of this and careful with
> it.  It will not do to start burning our users out of applying updates
> because there are too many of them.  If we do that then I promise you we'll
> be seeing people getting "recast" as an answer anyway.
>
> This is all the more relevant now that we're doing more frequent stable
> releases.  I already have boxes on stable that are compiling nearly
> non-stop to keep up, and I know I'm not going to be able to maintain that.
> This is a "good problem to have" and there are ways to help mitigate it but
> I'd rather we not aggravate it more than we need to.
>
> As for defining "unnecessary" -- I'm not trying to dictate policy or
> anything.  The Grimoire Lead needs to set these policies with the input of
> the other developers and users.  I think the current policy such as it is
> needs revising to consider different types of users, that's all.  If I
> didn't include "stable grimoire integration policy" in my list of questions
> for the GL candidates I should have, and this one can be added as a related
> question.
>
> There's no question there are different kinds of users with different needs
> here.  Some are running workstations that want to have the latest and
> greatest of all spells.  Some have production systems they can only patch a
> few times a year (and yearly probably isn't out of the question).
> Maintaining user choice here may well mean we need more queue and
> PATCHLEVEL granularity, I don't know.  One idea might be a major.minor
> numbering scheme for PATCHLEVEL, with every spell change bumping the minor
> number and only certain types of updates (defined by policy) bumping the
> major number, and a queue-criticalpatches or the like to support it.

Jeremy,
While you do have a good point, I still believe my point is valid. While we 
do 
not hand-hold our users with configurations and setups, we *do* lead them to 
expect spells to cast with the defaults, and for fixes in spells to be 
applied so that future casts work (hence the implementation of 
UPDATED/PATCHLEVEL in Sorcery). I view it as a Bad Thing (TM) for us to be 
telling users to recast a package to obtain a fix as they should *never* have 
to come into IRC, the forums, or our mailing lists asking why something 
doesn't work when we have the fix and failed to have the fix applied to their 
system.

For people with slow systems (who should already know that they're going to 
be 
spending a lot of time compiling) and people who check every update, we have 
`sorcery queue-security`. There is no reason not to use PATCHLEVEL to force 
packages to be queued when that'd fix a current or future problem.

-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: pgp4V_yLoHtwA.pgp
Description: PGP signature