From owner-freebsd-current Sat Jul 3 5: 4: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id B9AE814E27 for ; Sat, 3 Jul 1999 05:03:55 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 82F0B64; Sat, 3 Jul 1999 20:03:53 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: mjacob@feral.com Cc: Greg Lehey , current@FreeBSD.ORG Subject: Re: Fixing other people's code (was: world broken in vinum (PATCH)) In-reply-to: Your message of "Fri, 02 Jul 1999 17:33:11 MST." Date: Sat, 03 Jul 1999 20:03:53 +0800 From: Peter Wemm Message-Id: <19990703120353.82F0B64@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > > Let me add to this: > > opinion: > > > > If it's really blocking folks because things don't compile, it is always > > acceptable to do what you need to do- the tree should always compile even > > if -current. If the system doesn't boot because of change, then that's an > > obvious one too. If things work differently or not as well, but things > > are more or less working, it's not an emergency, so leave it for the > > author to fix.... > > ...always modulo a short delay (call it a couple of hours) after reporting > the problem... after all, you don't *know* that the update isn't finished > and that other things are coming down the pipe... but a couple of hours > leaves really the most reasonable time for an integration to complete and > the author to have had lunch in between. I'd like to chime in here.. It really does depend on the situation and requires the people involved to make a judgement call as to whether they think it's worth bypassing an offline maintainer or owner or whatever. If you feel you can justify (if needed) bypassing normal channels and you are confident that you're not going to screw something up then I'd be suggesting it's OK to go ahead - but be prepared to back it out or have it replaced if the maintainer disagrees. If doing this, be sure to label something as a temporary fix, or workaround or whatever so that it's clear what's going on. Personally, for something like vinum where you can strand people if you let a broken /sbin/vinum get installed, I'd be thinking more along the lines of disconnecting it from the Makefiles rather than jumping in. That would get world running again, and leave people with known good /sbin/vinum and /modules/vinum.ko etc. It all comes down to making a judgement call after considering the consequences of *possibly* making things worse, versus the inconvenience of having something broken. Inconvenience to the normal maintainer should be a consideration but isn't a huge deal since it is quite easy to back a commit out... Anyway, That's my 2 cents worth on the subject. :-) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message