Moin Joerch,
> The new patches on the main ftpserver have
> all the date 24.8.06, the patches themself
> contain different dates, like 9.8.06
I assume you are referring to the times when the fixes
were committed to 3.9-stable:
+++ gnu/usr.sbin/sendmail/sendmail/main.c
8 Aug 2006 20:20:42 -0000 1.21.8.1
+++ usr.sbin/dhcpd/memory.c
10 Aug 2006 01:51:15 -0000 1.10.6.1
+++ sys/kern/sysv_sem.c
11 Aug 2006 04:08:45 -0000 1.32.8.1
+++ sbin/isakmpd/ipsec.c
19 Aug 2006 20:23:28 -0000 1.122.2.1
> and if i browse the cvstree on the web i see
> another different revision number than in
> the patches and the revnumber of the patches.
Well, the developers are usually working on -current (which
currently happens to be 4.0-beta, see /usr/src/sys/conf/newvers.sh
in the CVS repository). For that reason, -current is nearly
always fixed first when any bug is found.
In this case, for example, moritz@ committed sendmail/main.c
rev. 1.23 to branch MAIN (= -current) on Aug 7 15:41 - based on a
patch by Claus Assmann and after talking to thib@ and [EMAIL PROTECTED]
After that, somebody needs to notice that the fix does not introduce
a new feature and is important enough to be committed to -stable.
If the fix is very critical, this is usually done very quickly.
If it is not that important, it may take some time, even one or two
weeks, in some cases. In this case, brad@ found time to commit the
sendmail fix to -stable the next day: rev. 1.21.8.1 to branch
OPENBSD_3_9 on Aug 8 20:20, rev. 1.21.6.1 to branch OPENBSD_3_8
on Aug 8 20:33.
Not everything that is committed to -stable warrants an errata
entry. So the developers need to make up their minds whether
the fix at hand does or does not - and if it does, someone has
to do the work. Once more, if it is critical, then this is done
very quickly, if not, it may take some time.
In this case, my impression is that on Thursday or Friday, brad@
took the time to prepare four errata entries, processing - one
right after another while he was about it - the four most important
fixes to -stable, committed during the last fortnight or so.
Like this, using the errata page and the CVS web interface,
you can usually roughly sort out what happened even if you are
not a developer.
> If i follow stable i am a lot faster in
> keeping my system up to date,
Yes, sometimes. But that will hardly matter.
Critical fixes won't show long delays.
> but i must check more often to see if it really makes
> sense to build everything new, right or wrong ?
You *can* (not must) check more often - that is your choice.
Following -stable or using errata is mostly a matter of taste.
In fact, if you follow -current, you get fixes even quicker.
But then, you will (quite rarely) encounter problems due to
bugs introduced by new features that were not committed to
-stable. Clearly, you should *not* track -current just because
bug fixes are first committed to -current!
> Do i get all information on the /usr/src tree
> if i am not blind or dump ?
Well, "all information" is a great word - but you will
certainly find more information in the CVS than you need
to keep your system patched and safe.
> I am starting browsing the tree, but there is a
> lot of information ;)
People often say that browsing the CVS is a good idea if you
want to get some feeling what is currently being done.
Yours,
Ingo
