Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] patchlevel policy

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Arwed von Merkatz <v.merkatz AT gmx.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] patchlevel policy
  • Date: Wed, 7 Mar 2007 20:48:48 +0100

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




Archive powered by MHonArc 2.6.24.

Top of Page