so you want to run current?

[Ted U <grendel@heorot.stanford.edu>]

Forwarding this on to misc@ because I think it might be more relevant
there, and because I think it's one of the best essays yet written on the
topic.  Thanks!

--
If you ever would give them a helping hand,
You can be sure they'll chop off the arm.
Never, ever, never trust a Klingon; you will always regret it.

---------- Forwarded message ----------
Date: Sun, 9 Jun 2002 17:46:03 -0400 (EDT)
From: Woodchuck <djv@bedford.net>
To: tech@openbsd.org
Subject: Re: err on re-build

On Sun, 9 Jun 2002, Philipp Buehler wrote:

> On 09/06/2002, Theo de Raadt <deraadt@cvs.openbsd.org> wrote Cc tech@openbsd.org:
> > It is an unfortunate thing that came out of it when the upgrade-minifaq
> > was made more visible:
> >
> >     People who cannot read between the lines started acting stupid.

Sigh. Yup.

> People tend to ignore 'Warnings' even if you make a javascript:alert
> popup, and use <font size=+20><blink>DO NOT</blink></font> for it.

Sigh. Yup.  Those are for "somebody else".

> I quote my own signature here: #1 (dereference on your own)
>
> *Maybe* a weekly posting about well-known-fuckups to misc@
> would help a *bit*. But basically this is against the first
> paragraph I wrote.

Notes from a tech-lurker: (Directed to those who simply *must* track
-current without sufficient "clue").

*) -current is not the latest and greatest.  It is just the latest.
The greatest is called -stable.  You do not get "points" for running
-current, you get bugs. Big Hint: THAT'S WHAT IT'S FOR!

*) Track and read daily the synopsis available from the list at
squish.net.  I do this, and *I* track -stable.  When I saw the
authpf group non-bug, I immediately recognized what had happened.

That's because, even though I am not interested in authpf, I
recognized that changes in this area of pf have been underway. (from
squish.net updates -- no further hint about how to get these should
be necessary.) Although I do not use Kerberos, from recent updates
I am aware that a new version of Kerberos is being hacked in as we
speak.  If on Tuesday, someone can't find, say, "group kerberboyz"
or somesuch, I will have a real good idea why.

*) An error message from building -current is, in itself, and
by itself, probably non-reportable.

He who sees such an error should track down *what it means*.  In
this case, evidently a group needs to be defined.  This means a
change to the near sacred /etc/group file, in a directory that "make
build" leaves almost completely untouched. [It installs /etc/magic,
for one].  So how are such changes introduced? (one would ask).  No
clue?  then sit back and watch output from "cd /usr/src && find .
-type f | xargs grep authpf" and clues will come streaming by,
including a handy little memory jogger from /usr/src/etc/group.
The "duh" reflex, a sharp forehead slap, should take over then.

If there's a compilation error from an include file not being found,
say, figure out why.  Gasp, suppose there's a C syntax error in
some file.  Figure OUT WHY!  Are the committers so lame they don't
compile their changes before loosing them on an innocent world?
Not usually, life is not so frenzied.  Look at the line of code!
Why is it barfing?!?  Usually it means a struct has changed, or a
macro has changed, or the prototype for some extern has changed.
Ask yourself, how are such changes wrought?  With include files.
So figure out which include file is being falsely included, then
*figure out* what *systematic* (not "hackish") thing one should
have done to cause the right include file to be in the right place.
99/100 times, reviewing the upgrade instructions will, after the
fact, cause one to nod.  "Yes.  It's another case of *that*. Should
have checked *that*." Finding bugs (not their symptoms, but their
glossy little six-legged persons) is fun.  Those not considering
tracking bugs -- especially other people's -- Good Clean Fun, have
no Good Clean Reason to mess around in -current.

*) Consider tracking not today's -current, but *last week's* -current.
(Use the "-D date" argument in cvs(1)).  Then when an error in build
occcurs, assume it has already been fixed in *this week's*.  I mean,
really, the people doing commits are doing builds too. If, after
having found out *why* the error exists, update cautiously (perhaps
even peaking ahead in the cvsweb material at
http://www.openbsd.org/cgi-bin/cvsweb/ to see what (if any) fixes
have been made since last week) to "today's -current" and see if
that fixes the bug.  If you've tracked down the bug, you will have
a good idea where to look in the week's intervening commits to see
if it has been stomped. If, after having looked over the intervening
week's commits, and you still see the bug, and it is a *real bug*,
report it, its symptoms, its fix, and earn Real Points.

Or just watch, *sigh*, misc or tech and let someone else take the
flames.  If you haven't seen anyone else taking heat for the
bug, and intervening commits have not "fixed" it, it's really-really
time to scratch head, because it's very likely *your* fault. It's
very likely that you will be (rightly) flamed for it, especially
on this list.  There are fora where you can come, lay down your
shame, and not be flamed if you're willing to take instruction.
(openbsd-newbies@sfobug.org is a recent addition).  THIS ISN'T
ONE OF THEM.  I am in fact debating whether to post this very
advice.  Damme, it's so likely that those needing it won't see it.

*) Realize that when you do a cvs update, you are *taking a fixed
image* of the repository.  You are shooting at a moving target.
Chances are you are running cvs at an arbitrary time.  Do you
really believe that the committers, all around the world, stand
poised over the "return" key, awaiting the sounding of a gong
and simultaneously press it, having determined (through some magical
process) that that set of commits creates a stable system?  Why
yes, sometimes, in effect, they do: they're called "releases" when
that happens.  At other times, things called "snapshots" are made,
which are believed (but not with the certainty of a release) to
be self-consistent and stable systems, subject to the general
*announced and assumed* potential flakiness of -current.

Well, this is windy enough.  My fond yet faint hope is that it will
be found and read in the future and forestall some of these obvious
problems.

Dave