Date: Sun, 24 May 1998 18:15:31 +0100 From: njs3@doc.ic.ac.uk (Niall Smart) To: Eivind Eklund <eivind@yes.no>, 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: <E0ydeMt-0004Ix-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, 7:00pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On May 24, 7:00pm, Eivind Eklund wrote: } Subject: Re: Problem reports closed by Poul-Henning Kamp [was: Re: misc/67 > > > 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. Yes, I presume by "changes that should be merged to -stable" you mean "changes that should be merged to -stable after a suitable cooling off period in -current" and not "changes that should be merged to -stable when someone who cares about merging stuff to -stable gets a chance meanwhile I'll merge it to -current" > 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. Well, I think in general PR's with patches available should get priority. It also provides an reminder to those who intended to test a fix in -current to bring it back into -stable, the amount of entries in this list may be small enough to post regularly as a reminder. > 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. Well, one advantage is that someone with nothing to do some Sunday has a ready source of fairly easy to close PR's so hopefully the queue will remain relatively small; you're also less likely to miss things this way, it provides a more structured way to implement the cooling off in -current approach. And secondly it provides an easy way for people who have invested time in producing a patch to go along with their PR to monitor its progress. 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?E0ydeMt-0004Ix-00>