Public SourceMage Discussion List

[Jeremy Blosser <jblosser-smgl AT firinn.org>]

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.

Attachment: pgpsY4SnZlnJS.pgp
Description: PGP signature