> On Sun, Oct 08, 2000 at 12:53:16AM -0700, a little birdie told me
> that Dima Dorfman remarked
> >
> > Why not just use a date? I do this on most of my systems. My `uname
> > -r` reads:
> >
> > 4.1-20000916-STABLE
> >
> > I started doing this for the exact same reason you described above--to
> > know when I updated the system. It does clutter the `uname -a` output
> > a bit, so it could be done similar to the way you suggested with the
> > flag: "4.1-STABLE 20000916".
> >
> > Just a thought.
>
> And a good way of doing it too, if we were already.
> My thought was 'as long as we're changing it already, might as well make
> it foolproof'. With a date, you still have a little uncertainty because
> of lags between CVSup servers, what time of the day the fix was
> committed,
That's true. I wasn't concerned with that because I know that I have
cvsup set up to always run at 01:00 local time, and the most it can
deviate from that is by ten or twenty minutes if the cvsup server is
busy.
> etc. It's maybe 90% sure, but you just *KNOW* someone is gonna try to
> sue us or raise holy hell over that 10% when it happens to them. With
> tags per-fix in the version, we're pretty much 100% certain that the fix
> is or isn't in that specific system, outside of people muddying
> things
Again, you're right. Now it just needs to be decided when these tags
should be advanced (for example, what is a showstopper bug for one
environment may be irrelevant to another), and get somebody to
implement it. The technical part of putting it in shouldn't be so
hard (I'm willing to help work on that), but getting commiters to
start using them may be somewhat difficult.
--
Dima Dorfman <[EMAIL PROTECTED]>
Finger [EMAIL PROTECTED] for my public PGP key.
I've used up all my sick days so I'm calling in dead!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
