Date: Sun, 24 May 1998 17:21:38 +0100 From: njs3@doc.ic.ac.uk (Niall Smart) To: Eivind Eklund <eivind@yes.no>, Niall Smart <njs3@doc.ic.ac.uk>, "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Studded <Studded@san.rr.com>, ac199@hwcn.org, Ruslan Ermilov <ru@ucb.crimea.ua>, nick@foobar.org, freebsd-bugs@FreeBSD.ORG Subject: Re: Problem reports closed by Poul-Henning Kamp [was: Re: misc/6712] Message-ID: <E0yddWk-0004Cc-00@oak66.doc.ic.ac.uk> In-Reply-To: Eivind Eklund <eivind@yes.no> "Re: Problem reports closed by Poul-Henning Kamp [was: Re: misc/6712]" (May 24, 6:08pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On May 24, 6:08pm, Eivind Eklund wrote: } Subject: Re: Problem reports closed by Poul-Henning Kamp [was: Re: misc/67 > On Sun, May 24, 1998 at 02:13:03PM +0100, Niall Smart wrote: > > 1) If they aren't committed to -stable then someone is going to have > > to trawl through a list of PR's with patches which are appropriate > > for both stable and current, but which have only been brought into > > current. This involves reviewing (again) the correctness of the > > patch, contacting the submitter (again) etc etc, all of which is a > > waste of resources. > > The above isn't the way things work. If they don't get committed to > -stable, one of three things happen: > > (1) The committer does what he's supposed to: Notes down which patches > he's supposed to merge to -stable and merge them after an > appropriate stay in -current. If this was happening I wouldn't be complaining. The patches I'm talking about involve near zero-risk to -stable anyway. > (2) The change is merged to -stable as a part of a merge-run (mostly > before a release, and mostly done by Jordan. This is too bad) This is exactly the type of waste of resources I'm talking about. If a trivial patch is supplied, then apply it to both tree's and get it out of the way, or don't touch it at all, leaving things inbetween just complicates things. > (3) (Usually only if the change is too large to be merged, or is in > the kernel) The change is left in -current only. Sure, this is an understandable and predicatable consequence of having two source trees. > This does _not_ involve a re-handling of the PR - it _only_ involve > handling of the code. A patch is most often not appropriate to commit > verbatim; style fixes etc is done before it is committed. It would > not be efficient to handle this from the PR. Style fixes are exactly the type of duplication of effort I'm talking about, if the original PR reviewer can commit a patch to -current and -stable simultaneously then that is what should happen. If he doesn't have time to do both, or if the patch requires a cooling off period in -current then the PR should be shunted into a new category instead of doing it in -current only and then closing it. Regards, Niall. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0yddWk-0004Cc-00>