ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

classic Classic list List threaded Threaded
99 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Karl Denninger
This is not cool folks.

Anyone know what I have to roll back to - and what files I have to roll back -
to stop this cluster-##@kery?

      tty             ad4              ad6            twed0             cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
 224  453  0.61   0  0.00  120.16 427 50.06   0.61   0  0.00   2  0  4  2 92

See that?  There's nothing really running.  What I tried to do was
"gmirror insert b500 ad4s1"

The command took, but NO IO WAS TAKEN TO THE TARGET DRIVE FOR REBUILDING; the
SOURCE disk was locked in a 100% I/O run, and after stopping the rebuild THE
I/O INFINITE LOOP IS STILL GOING ON!

I had a PRODUCTION MACHINE go down on my last night over this when it
attempted to run its backup process and wedged due to process table overflow;
the first attempt apparently never finished the day before and the second, to
a SECOND backup disk (I have a rolling disk backup system using GMIRROR's
resync) caused the system to wedge in an I/O wait.

This was also not cleanly restartable, as the root partition had multiple
error on it that fsck -p couldn't fix.

This is a SEVERE emergency in that anyone who has a disk that has to be
rebuilt under -STABLE right now (sources as of 7 September) is screwed, blued
and tattooed.

That PRODUCTION machine is running UNPROTECTED right now (no mirroring) as a
consequence of this, and I can neither back it up using the usual mirror NOR
restore its redundancy!

I see only one comment about GMIRROR changes in the commitlogs since 9/1, and
it claims to be (mostly) cosmetic.

Obviously not!

--
--
Karl Denninger ([hidden email]) Internet Consultant & Kids Rights Activist
http://www.denninger.net        My home on the net - links to everything I do!
http://scubaforum.org                Your UNCENSORED place to talk about DIVING!
http://genesis3.blogspot.com        Musings Of A Sentient Mind


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Patrick M. Hausen
Hi!

On Sat, Sep 09, 2006 at 12:38:13PM -0500, Karl Denninger wrote:
> This is not cool folks.
> ...

I experienced the same problem - luckily on a lab machine.

As much as I understand your anger, -stable is not guaranteed
bug free.

And to answer your question: RELENG_6_1 doesn't show this problem.
I recommend running RELENG_X_Y instead of RELENG_X for
recent values of X and Y on production systems, anyway.

HTH,

Patrick M. Hausen
Leiter Netzwerke und Sicherheit
--
punkt.de GmbH         Internet - Dienstleistungen - Beratung
Vorholzstr. 25        Tel. 0721 9109 -0 Fax: -100
76137 Karlsruhe       http://punkt.de
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Max Laier
In reply to this post by Karl Denninger
On Saturday 09 September 2006 19:38, Karl Denninger wrote:
> This is not cool folks.

Want a refund?

--
/"\  Best regards,                      | [hidden email]
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Karl Denninger
Yeah, -STABLE is what you should run if you want stable code, right?

C'mon guys.  This sort of thing belies a total lack of concern when changes
are MFC'd into production branches of the code.  This kind of thing is
expected if you're running -CURRENT, but not -STABLE.

How long would it have taken to actually test the change and detect this once
it was put in?  All of 30 seconds?

--
--
Karl Denninger ([hidden email]) Internet Consultant & Kids Rights Activist
http://www.denninger.net        My home on the net - links to everything I do!
http://scubaforum.org                Your UNCENSORED place to talk about DIVING!
http://genesis3.blogspot.com        Musings Of A Sentient Mind

On Sat, Sep 09, 2006 at 08:23:10PM +0200, Max Laier wrote:

> On Saturday 09 September 2006 19:38, Karl Denninger wrote:
> > This is not cool folks.
>
> Want a refund?
>
> --
> /"\  Best regards,                      | [hidden email]
> \ /  Max Laier                          | ICQ #67774661
>  X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
> / \  ASCII Ribbon Campaign              | Against HTML Mail and News




_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Kris Kennaway
On Sat, Sep 09, 2006 at 01:28:31PM -0500, Karl Denninger wrote:
> Yeah, -STABLE is what you should run if you want stable code, right?
>
> C'mon guys.  This sort of thing belies a total lack of concern when changes
> are MFC'd into production branches of the code.  This kind of thing is
> expected if you're running -CURRENT, but not -STABLE.
>
> How long would it have taken to actually test the change and detect this once
> it was put in?  All of 30 seconds?

Please try to calm down, getting angry on the mailing list is only
going to make everyone else angry too.

Kris

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Marc G. Fournier-4
In reply to this post by Karl Denninger
On Sat, 9 Sep 2006, Karl Denninger wrote:

> Yeah, -STABLE is what you should run if you want stable code, right?
>
> C'mon guys.  This sort of thing belies a total lack of concern when
> changes are MFC'd into production branches of the code.  This kind of
> thing is expected if you're running -CURRENT, but not -STABLE.
>
> How long would it have taken to actually test the change and detect this
> once it was put in?  All of 30 seconds?

In this case, I don't know ... but I *do* know that I do hit a fair
number of "bugs" that a simple 30 second test won't uncover ... a
production box *can* and *will* tend to hit bugs that a test box won't,
just because of the randomness of what is running on it ... trust me, I've
had my share of headaches over the years, but it doesn't (and won't) deter
me from running -STABLE, for the simple fact that if I don't, there is a
good chance that those bugs that I do get "lucky" enough to hit won't get
hit by anyone else and *someone* had to get it ;)

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . [hidden email]                              MSN . [hidden email]
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Karl Denninger
On Sat, Sep 09, 2006 at 04:04:40PM -0300, Marc G. Fournier wrote:

> On Sat, 9 Sep 2006, Karl Denninger wrote:
>
> >Yeah, -STABLE is what you should run if you want stable code, right?
> >
> >C'mon guys.  This sort of thing belies a total lack of concern when
> >changes are MFC'd into production branches of the code.  This kind of
> >thing is expected if you're running -CURRENT, but not -STABLE.
> >
> >How long would it have taken to actually test the change and detect this
> >once it was put in?  All of 30 seconds?
>
> In this case, I don't know ... but I *do* know that I do hit a fair
> number of "bugs" that a simple 30 second test won't uncover ... a
> production box *can* and *will* tend to hit bugs that a test box won't,
> just because of the randomness of what is running on it ... trust me, I've
> had my share of headaches over the years, but it doesn't (and won't) deter
> me from running -STABLE, for the simple fact that if I don't, there is a
> good chance that those bugs that I do get "lucky" enough to hit won't get
> hit by anyone else and *someone* had to get it ;)

Well sure, if its one of those "corner cases" I understand.  This is the price
of not doing FULL regression testing, and expecting that from a free project
is unreasonable.  Hell, you don't get that from Micro$oft, why would anyone
think you'd get it here?

But in this situation its not a corner case.  I've got a (different) open issue
on 6.x where it appears that SELECT on serial lines is badly screwed; this may
be specific to the ROCKETPORT cards and it may not - not real sure yet.  I
reported that one recently too, and its giving me a 5-alarm migrane at the
moment trying to find a workaround that actually functions.  I can't find
anything in the commit logs that would lead me to believe that the ttyio
code has changed in a way that should have caused this, and the driver
hasn't been updated either.  That's a head-scratcher for a whole host
of reasons with the first one being that I don't have the first clue
where to look for the source of trouble (to use a pun.)

Its not as simple as "serial I/O doesn't work at all"; it appears to be
specific to using VMIN, non-blocking I/O and select() to handle multiple
sources of input coming into a single thread.  Now how often do people do
this?  I dunno..... but what I do know is that the common "single thread"
application works fine on the same port....

This is different.  We're talking about the very basic functionality of
the gmirror system - to be able to rebuild a disk that is out of sync.

In this case my "notice" of the problem came in the form of a production
machine that went down overnight - apparently, it would seem, during an
attempt to back itself up using that functionality.  It went down HARD
and corrupted the root partition directory structure badly enough to prevent
fsck from being able to rebuild it on an automated restart attempt, and what
was worse, the bug caused the system to block in I/O permanently as of course
when it came back up from the crash it tried to resync the out-of-date
providers, making the reboot hang!  So what I had was a production machine
that couldn't be brought back up without significant "wizardry" at the
physical console, and frankly, what it LOOKED LIKE at first blush was a
<double> disk failure - one of those "that's not supposed to happen" things.

I was very close to putting the day-old backup disk online - I'm darn glad I
didn't, because the bug would have likely trashed THAT one too, and then I'd
be both a day back on the data AND have an unstable system!

Not good, especially when the commit log on the last delta to the gmirror code
was basically "removed uses of the F-word in comments; we're nice people".

Uh, obviously not.

The obvious question is how does the protocol for committing changes to
-STABLE work if the committer isn't required to first test the basic function
set of the module he/she modifies, on -STABLE, before those changes are MFC'd
back into the -STABLE tree?

I see that the (actual) code changes were backed out (apparently yesterday)
and I've rebuilt the kernel with those, which has put the immediate fire out,
but this is one of those instances where the usual "check and balance" process
that is <ADVERTISED> as being present in -STABLE failed badly, and it failed
simply due to a lack of checking at all!

--
--
Karl Denninger ([hidden email]) Internet Consultant & Kids Rights Activist
http://www.denninger.net        My home on the net - links to everything I do!
http://scubaforum.org                Your UNCENSORED place to talk about DIVING!
http://genesis3.blogspot.com        Musings Of A Sentient Mind


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Mark Andrews
In reply to this post by Karl Denninger

> Yeah, -STABLE is what you should run if you want stable code, right?

        No. STABLE means STABLE API.

        If you want stable code you run releases.  Between releases
        stable can become unstable.  Think of stable as permanent
        BETA code.  Changes have passed the first level of testing
        in current which is permanent ALPHA code.

        Most of the time beta code is perfectly fine to run but
        occasionally things will go wrong.  The point of BETA code
        is to catch those errors that escape detection in the ALPHA
        stage before they make it into a release.  That is done by
        having a wider diversity of clients run the BETA code.

        Occasionally you have bugs that make it through both the ALPHA
        and BETA stages.

  Mark
--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [hidden email].
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [hidden email]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Marc G. Fournier-4

This should be documented somewhere clearly then, as my understanding was
that -STABLE meant that anything MFCd back to it *was* tested and deemed
stable ... and yes, I do run stable, and yes, I do expect to hit the
occasional 'oopses', but "blantant and obvious bugs due to insufficient
testing", IMHO, doesn't classify as an 'oops' ....



On Sun, 10 Sep 2006, Mark Andrews wrote:

>
>> Yeah, -STABLE is what you should run if you want stable code, right?
>
> No. STABLE means STABLE API.
>
> If you want stable code you run releases.  Between releases
> stable can become unstable.  Think of stable as permanent
> BETA code.  Changes have passed the first level of testing
> in current which is permanent ALPHA code.
>
> Most of the time beta code is perfectly fine to run but
> occasionally things will go wrong.  The point of BETA code
> is to catch those errors that escape detection in the ALPHA
> stage before they make it into a release.  That is done by
> having a wider diversity of clients run the BETA code.
>
> Occasionally you have bugs that make it through both the ALPHA
> and BETA stages.
>
> Mark
> --
> ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
> covering topics from DNS to DHCP.  Email [hidden email].
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [hidden email]
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[hidden email]"
>

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . [hidden email]                              MSN . [hidden email]
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Mark Linimon-2
On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote:
> This should be documented somewhere clearly then, as my understanding was
> that -STABLE meant that anything MFCd back to it *was* tested and deemed
> stable ...

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/version-guide/decision-points.html

> but "blantant and obvious bugs due to insufficient testing", IMHO, doesn't
> classify as an 'oops' ....

You've already made this point -- 3 times.  What would you like us to do
now, punish the committer?

Simply reiterating your criticism and unhappiness isn't going to do anything
to fix this problem (for which, of course, a fix has already been made), or
the next one(s) either.

It was an error, it's been fixed, may I suggest we move on to the next bug?

mcl
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Kris Kennaway
In reply to this post by Marc G. Fournier-4
On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote:
>
> This should be documented somewhere clearly then, as my understanding was
> that -STABLE meant that anything MFCd back to it *was* tested and deemed
> stable ...

You mean like in the FreeBSD handbook?  It's not anyone else's fault
if you haven't read the documentation.

  http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html

Kris

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Marc G. Fournier-4
In reply to this post by Mark Linimon-2
On Sat, 9 Sep 2006, Mark Linimon wrote:

> On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote:
>> This should be documented somewhere clearly then, as my understanding was
>> that -STABLE meant that anything MFCd back to it *was* tested and deemed
>> stable ...
>
> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/version-guide/decision-points.html
>
>> but "blantant and obvious bugs due to insufficient testing", IMHO, doesn't
>> classify as an 'oops' ....
>
> You've already made this point -- 3 times.  What would you like us to do
> now, punish the committer?

Huh?  My first post on this thread was in defense of MFCng into STABLE and
acknowledging that 'mistakes happen', and then this one ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . [hidden email]                              MSN . [hidden email]
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Marc G. Fournier-4
In reply to this post by Kris Kennaway
On Sat, 9 Sep 2006, Kris Kennaway wrote:

> On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote:
>>
>> This should be documented somewhere clearly then, as my understanding was
>> that -STABLE meant that anything MFCd back to it *was* tested and deemed
>> stable ...
>
> You mean like in the FreeBSD handbook?  It's not anyone else's fault
> if you haven't read the documentation.
>
>  http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html

I swear, the last time I searched for a definition of STABLE vs
CURRENT/HEAD, that wsan't there ... but, granted, that was a very very
long time ago ...


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . [hidden email]                              MSN . [hidden email]
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Kris Kennaway
On Sun, Sep 10, 2006 at 12:55:42AM -0300, Marc G. Fournier wrote:

> On Sat, 9 Sep 2006, Kris Kennaway wrote:
>
> >On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote:
> >>
> >>This should be documented somewhere clearly then, as my understanding was
> >>that -STABLE meant that anything MFCd back to it *was* tested and deemed
> >>stable ...
> >
> >You mean like in the FreeBSD handbook?  It's not anyone else's fault
> >if you haven't read the documentation.
> >
> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html
>
> I swear, the last time I searched for a definition of STABLE vs
> CURRENT/HEAD, that wsan't there ... but, granted, that was a very very
> long time ago ...
Well, now you know.  Might be a good idea to reread the handbook and
other documentation to bring yourself up to date on anything else you
might have missed too.

Kris

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Karl Denninger
In reply to this post by Mark Andrews
On Sun, Sep 10, 2006 at 11:59:10AM +1000, Mark Andrews wrote:

>
> > Yeah, -STABLE is what you should run if you want stable code, right?
>
> No. STABLE means STABLE API.
>
> If you want stable code you run releases.  Between releases
> stable can become unstable.  Think of stable as permanent
> BETA code.  Changes have passed the first level of testing
> in current which is permanent ALPHA code.
>
> Most of the time beta code is perfectly fine to run but
> occasionally things will go wrong.  The point of BETA code
> is to catch those errors that escape detection in the ALPHA
> stage before they make it into a release.  That is done by
> having a wider diversity of clients run the BETA code.
>
> Occasionally you have bugs that make it through both the ALPHA
> and BETA stages.

Of course this assumes that -RELEASE is actually stable and fully suitable
for production use.

As soon as you find a bug that you can't live with in -RELEASE, you have darn
few options other than to updade to -STABLE, especially if there's a commit in
the tree that appears to fix the bug in -STABLE.

Once the -RELEASE branch is taken, code updates there <STOP>.

Not even Microsoft expects people to live from release to release without bug
fixes!

In the 10 years I've been running FreeBSD in a production environment I've yet
to find a -RELEASE branch that is actually suitable for production use for the
duration between -RELEASEs; inevitably a bug that I can't live with requires
that I update the source, and what does one update to in this instance?

-STABLE.

If the project wishes to have -RELEASE be "the stable point" then bug
fixes (once FULLY tested) must be back-ported to -RELEASE - otherwise the
appearance of a bug you can't live with gives you no other real option than to
run the -STABLE track.

--
--
Karl Denninger ([hidden email]) Internet Consultant & Kids Rights Activist
http://www.denninger.net        My home on the net - links to everything I do!
http://scubaforum.org                Your UNCENSORED place to talk about DIVING!
http://genesis3.blogspot.com        Musings Of A Sentient Mind


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Patrick Okui-2
On Sun, 10 Sep 2006, Karl Denninger wrote:

>
> Once the -RELEASE branch is taken, code updates there <STOP>.
>

I take it you haven't read the text in the handbook that has been
linked to by a few posters.

You can track changes to a particular release - say by using
RELENG_6_1 rather than RELENG_6. In which case, would you still
say you are tracking STABLE?

--
patrick
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Christopher Schulte
In reply to this post by Karl Denninger
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Patrick J Okui
> Sent: Sunday, September 10, 2006 10:22 AM
> To: Karl Denninger
> Cc: [hidden email]
> Subject: Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
>
> You can track changes to a particular release - say by using
> RELENG_6_1 rather than RELENG_6. In which case, would you
> still say you are tracking STABLE?

Well, that depends.

For security and "critical fixes" (as the handbook phrases it) you can
track RELENG_6_1 (in the case of 6.1-RELEASE) and be happy.

But what happens if the needed fix isn't security or "critical" in the
minds of the FreeBSD developers?  At that point you either need to wait
for the next RELEASE, manually merge fixes into your production source
(which depending on the fix(s) could be non-trivial) or cross your
fingers and follow -STABLE.

This problem isn't specific to FreeBSD (or unix in general) by Any
means, of course.

Sure, we could broaden the scope of RELENG_X_Y.  Or introduce a new
branch that's closer to -STABLE yet tuned for something like, "security,
critical and major fixes" for production systems.  I'm not sure either
of those options are preferable, would be effective in alleviating the
problem, or even workable in the first place.

Personally, I've been served quite well for many years with the current
configuration.  Since I don't track -STABLE on anything important (or
more accurately have yet NEEDED to do so), I've never been hit by any of
these transient issues that crop up from time to time and can elicit
loud complaints.

--Chris
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Karl Denninger
In reply to this post by Patrick Okui-2
On Sun, Sep 10, 2006 at 03:21:33PM +0000, Patrick J Okui wrote:

> On Sun, 10 Sep 2006, Karl Denninger wrote:
>
> >
> >Once the -RELEASE branch is taken, code updates there <STOP>.
> >
>
> I take it you haven't read the text in the handbook that has been
> linked to by a few posters.
>
> You can track changes to a particular release - say by using
> RELENG_6_1 rather than RELENG_6. In which case, would you still
> say you are tracking STABLE?

Yes.

If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition
tracking -STABLE.

Indeed, the current tag on my CVS tree is TRELENG_6!

--
--
Karl Denninger ([hidden email]) Internet Consultant & Kids Rights Activist
http://www.denninger.net        My home on the net - links to everything I do!
http://scubaforum.org                Your UNCENSORED place to talk about DIVING!
http://genesis3.blogspot.com        Musings Of A Sentient Mind


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Kris Kennaway
On Sun, Sep 10, 2006 at 01:13:31PM -0500, Karl Denninger wrote:

> On Sun, Sep 10, 2006 at 03:21:33PM +0000, Patrick J Okui wrote:
> > On Sun, 10 Sep 2006, Karl Denninger wrote:
> >
> > >
> > >Once the -RELEASE branch is taken, code updates there <STOP>.
> > >
> >
> > I take it you haven't read the text in the handbook that has been
> > linked to by a few posters.
> >
> > You can track changes to a particular release - say by using
> > RELENG_6_1 rather than RELENG_6. In which case, would you still
> > say you are tracking STABLE?
>
> Yes.
>
> If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition
> tracking -STABLE.
>
> Indeed, the current tag on my CVS tree is TRELENG_6!
Not the question he asked, please re-read.

Kris

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

Karl Denninger
On Sun, Sep 10, 2006 at 02:36:31PM -0400, Kris Kennaway wrote:

> On Sun, Sep 10, 2006 at 01:13:31PM -0500, Karl Denninger wrote:
> > On Sun, Sep 10, 2006 at 03:21:33PM +0000, Patrick J Okui wrote:
> > > On Sun, 10 Sep 2006, Karl Denninger wrote:
> > >
> > > >
> > > >Once the -RELEASE branch is taken, code updates there <STOP>.
> > > >
> > >
> > > I take it you haven't read the text in the handbook that has been
> > > linked to by a few posters.
> > >
> > > You can track changes to a particular release - say by using
> > > RELENG_6_1 rather than RELENG_6. In which case, would you still
> > > say you are tracking STABLE?
> >
> > Yes.
> >
> > If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition
> > tracking -STABLE.
> >
> > Indeed, the current tag on my CVS tree is TRELENG_6!
>
> Not the question he asked, please re-read.
>
> Kris

Yes it is, in the general case; in any event if you track RELENG_6_1 you will
get no bug fixes in general - security related items to filter back down but
in general bug reports posted against a -RELEASE are, if addressed, put into
-STABLE.

--
--
Karl Denninger ([hidden email]) Internet Consultant & Kids Rights Activist
http://www.denninger.net        My home on the net - links to everything I do!
http://scubaforum.org                Your UNCENSORED place to talk about DIVING!
http://genesis3.blogspot.com        Musings Of A Sentient Mind


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
12345