Date: Sun, 24 May 1998 19:00:29 +0200 From: Eivind Eklund <eivind@yes.no> To: Niall Smart <njs3@doc.ic.ac.uk> Cc: 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: <19980524190029.29308@follo.net> In-Reply-To: <E0yddWk-0004Cc-00@oak66.doc.ic.ac.uk>; from Niall Smart on Sun, May 24, 1998 at 05:21:38PM %2B0100 References: <eivind@yes.no> <E0yddWk-0004Cc-00@oak66.doc.ic.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 24, 1998 at 05:21:38PM +0100, Niall Smart wrote: > > 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, This effort is _not_ duplicated if the merge is done from source. Effort mighthave to be duplicated if the change is committed directly to -current and -stable - any subsequent style-fixes (and we're not perfect, so comments on the style of code we commit _do_ come). > if the original PR reviewer can commit a patch to -current and > -stable simultaneously then that is what should happen. Agreed, for really trivial changes where the committer at least have the ability to do a compile-test. > 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. The only effect of this is that we have a new category were some of the changes that should be merged to -stable are, along with some changes that have been merged. This is will not be of much help unless somebody take the time to go through this category and keep it correct (ie, at least periodically go through it and remove changes that already have been committed), and some committers take responsibility for making sure that the changes are merged correctly. Frankly, I'm not certain that a pass through this base will be significantly less work than doing a merge-run - you have to do more-or-less the equivalent of a merge-run for those areas of the source touched, anyway. The advantage is that somebody without commit privileges could keep the log clean. Eivind. 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?19980524190029.29308>