Re: Improving the handling of PR:s

1 msg	Sun's virtualization
2 msg	[PATCH] Add 'label' to rescue/geom
2 msg	strange message from ciss: ciss0: SENDING NOP M...

Improving the handling of PR:s
\ Peter Schuller (11 Jan 2008)
. \ (Mark Linimon) (11 Jan 2008)
. . \ 韓家標 Bill Hacker (11 Jan 2008)
. . \ Matthew Seaman (12 Jan 2008)
. . . \ (Mark Linimon) (13 Jan 2008)
. . \ Peter Schuller (12 Jan 2008)
. \ Bernd Walter (11 Jan 2008)
. . \ Igor Mozolevsky (11 Jan 2008)
. . . \ Bernd Walter (12 Jan 2008)
. . . . \ Igor Mozolevsky (12 Jan 2008)
. . . . \ Igor Mozolevsky (12 Jan 2008)
. \ Dominic Fandrey (12 Jan 2008)
. . \ Peter Jeremy (12 Jan 2008)
. . . \ (Mark Linimon) (13 Jan 2008)
. . . . \ Jeremie Le Hen (13 Jan 2008)
. . \ Kostik Belousov (12 Jan 2008)
. . . \ Igor Mozolevsky (12 Jan 2008)
. . . . \ (Mark Linimon) (13 Jan 2008)
. \ Daniel Rucci (12 Jan 2008)
. \ (Mark Linimon) (13 Jan 2008)

1 msg	7.0 RC1 dump hangs - sometimes
1 msg	RC1 dump hangs - sometimes
2 msg	Truncated capability record buffer returned
29 msg	[Call for testers] 'BSD ar'
2 msg	SAN for FreeBSD?
15 msg	strace broken in 7.0?
10 msg	Why the FreeBSD license will not be changing
4 msg	Regular bge watchdog timeouts on 7.0-PRERELEASE
1 msg	kgdb not loading symbols?
1 msg	Errors burning CD-RW's with RELENG_7
143 msg	FreeBSD's problems as seen by the BSDForen.de c...
2 msg	zpool cannot be imported into opensolaris
4 msg	Small patch to fix top in large NIS environments
3 msg	[PATCH] lockmgr and VFS plans
6 msg	IEEE488 (lack of) future in FreeBSD
2 msg	Re: Asus Eee PC

Subject:	Re: Improving the handling of PR:s
Group:	Freebsd-current
From:	Jeremie Le Hen
Date:	13 Jan 2008

Hi,

On Sat, Jan 12, 2008 at 10:16:22PM -0600, Mark Linimon wrote:
> On Sat, Jan 12, 2008 at 10:56:24PM +1100, Peter Jeremy wrote:
> > This PR brings up an issue that has been mentioned elsewhere in this
> > thread: Even where a PR contains a patch, a committer may be unwilling
> > to commit the change because they are unable to verify the patch
> > themselves.
>
> We need to generate some kind of way for people to volunteer to test
> some of these patches. e.g. "I am willing to test patches affecting
> the USB subsystem, and I have the following list of parts: ..."

I've just read the very interesting sub-thread started by Peter Schuller
two days ago.

As you guys have just said, it seems a major problem with PR relating to
drivers is that committers don't own the exact same hardware so are not
able to verify the patch correctness. On the other hand, I'm pretty
confident there is a non-marginal number of people (read,
non-committers) are willing to help handling PR: I'm not talking of any
official hat here, but those people could contribute to a database with
the hardware they own (think, pciconf(8)) so that they can be contacted
back if a patch affects the hardware they are using. I think that a
fair amount of folks running -CURRENT can and will help for this, why
would they be running it otherwise?

This practice is a step toward Peter Schuller's proposition of having a
group of self-proclaimed non-committers giving feed back to the PR.

Regards,
--
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >
_______________________________________________
freebsd-current mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe"