Public SourceMage Discussion List

[Arwed von Merkatz <v.merkatz AT gmx.net>]

On Wed, Mar 07, 2007 at 01:34:58PM -0600, Jeremy Blosser wrote:
> 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?

I agree with you there, location changes that don't change anything
*functionally* shouldn't warrant a PATCHLEVEL update.

> > > > 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.

That sounds like a good idea to me. I would exclude non-functional
changes to spells from minor patchlevel too.
The "some" shouldn't be just some percentage of users but also some
amount of spells. E.g. a change required only to fix a single other
spell wouldn't warrant a major patchlevel change to me, especially if it
could be worked around using force_depends from that single spell.

-- 
Arwed v. Merkatz                              Source Mage GNU/Linux developer
                                                    http://www.sourcemage.org