Public SourceMage Discussion List

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

On Mar 07, Eric Sandall [eric AT sandall.us] wrote:
> On Wednesday 07 March 2007 09:16:03 Jeremy Blosser wrote:
> > On Mar 07, Eric Sandall [eric AT sandall.us] wrote:
> > > 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.
> >
> > I know you think it's a bad thing, but you aren't really addressing the
> > points about why the alternative can also be a bad thing.  Both approaches
> > have issues, the weight of the issues varies depending on the individual
> > environment.  It's a much bigger problem for me to have to rebuild glibc 3
> > extra times on every box because a man page moved or something than it is
> > to have to search bugzilla or ask a question when some side feature 
> > doesn't
> > work on first blush.  Expecting people to hit a knowledge base or bugzilla
> > when looking for solutions is not at all uncommon, and we expect people to
> > do that today for any fixes that haven't made it from test to stable yet.
> 
> That's very true, and I thought I had addressed it, but to make it clear, 
> in 
> my opinion, the extra compiling is worth it, for me. ;) Others, obviously 
> disagree (and do have valid reasons). I don't believe in expecting users to 
> peruse bugzilla in order to have a working box as being conducive to 
> encouraging more users to try out/stay with SMGL.

Forget that one for a minute -- we currently make them recompile for file
location changes that don't break anything, eg if a man page changes
location.  Assuming man could already find it, what is broken there that
needs fixing?

> > > 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.
> >
> > There are bugfixes that have nothing to do with security that absolutely
> > need to present themselves as critical updates.  The recent business of
> > apache2 moving its default files around is a prime example.  Yes, that was
> > a file move, but it was a file move that broke production systems because
> > it included things like the existing conf files and document roots being
> > ignored.
> 
> A corner case, I would say, but then, my firefox issue also is a corner 
> case.

How is it a corner case?  Every existing apache2 install that upgraded to
2.0.59, patchlevel 0, could not find its configs or documents.  If you mean
the bug itself was a corner case, I don't see it as more than general
brokeness like anything else we patch things to fix.

> Perhaps we should come up with a usage policy for PATCHLEVEL that pleases 
> the 
> both of us:
> * PATCHLEVEL will always be incremented if there is a change to the 
> location 
> of installed files
> * PATCHLEVEL will always be incremented if other packages always require 
> this 
> change to work
> * PATCHLEVEL may be incremented on a case-by-case bases for other uses 
> (such 
> as a new configuration option)

My understanding is this is essentially what we do now, and it's not good
for me without further definition of which file moves matter or which
packages require it.  This is why I suggested something like a major and
minor patchlevel.  The minor could go along with the things you listed
there, while the major would only be incremented if a spell is patched to
fix some level of brokeness for some percentage of users ("some" yet to be
defined in both cases).

Then people who want it all can use the regular queue, and people who don't
want minor stuff can use a queue-critical or something.

Attachment: pgpayeo0wTnOR.pgp
Description: PGP signature