Date: Fri, 11 Jan 2008 19:35:41 +0100 From: Peter Schuller <peter.schuller@infidyne.com> To: freebsd-current@freebsd.org Cc: Mark Linimon <linimon@lonesome.com> Subject: Improving the handling of PR:s Message-ID: <200801111935.50821.peter.schuller@infidyne.com> In-Reply-To: <20080110003524.GB5188@soaustin.net> References: <478556AD.6090400@bsdforen.de> <20080110003524.GB5188@soaustin.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart9162351.RhgJZhdn8N Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =46rom the hideous flamewar-about-everything thread: > We clearly have a disconnect on PRs. More come in than we have any way > to handle. This is clearly most distressing when the PRs contain > patches and/or test cases. Again, I'm open to ideas on how to set up > something where more people can participate. Eric Anderson posted a suggestion that I read and won't comment on other th= an=20 to say that from the perspective of the non-committer it sounds like a good= =20 idea. I have another suggestion. The fundamental problem, I think everyone agrees, is that there is simply n= ot=20 enough commit bit developer time available to attend to all the PR:s. This = is=20 understandable. But understandable or not, the problem becomes particularly frustrating whe= n=20 it affects PR:s that contain patches. Such PR:s constitute direct=20 contributions to the project. In cases where such patches are correct/good= =20 enough, the non-application of those patches have what I believe to be=20 significant effects. The one perhaps lesser effect is that other people are bitten by the same b= ug=20 (which translates into loss of time on potential future contribotors) even= =20 though a fix is available. The second, possibly worse effect, is that the original submitter, I believ= e,=20 is less inclined to spend more time in the future contributing, if said=20 submitter feels the work is wasted because no one commits or even comments = on=20 the PR. In the case of PR:s with patches, why do they not get enough attention?=20 Obviously there is no technical reason why the application of the patch=20 itself should be a problem (that could be completely automated even). The=20 problem, presumably, will be that the time it takes to process the PR is mu= ch=20 more than the mechanical act of applying a patch because (and this list is= =20 probably not exhaustive): * The patch must be looked at and understood prior to application or even=20 testing. Does it comply with style guidelines? Does it break something else= =20 as a side-effect? What are other implications? And so on. * The committer may not have access to the hardware, or may not have a=20 software setup that allows for testing. This means doing such testing=20 suddenly requires a lot more effort. * The committer may not be familiar with the code and, even though the patc= h=20 looks good generally, it is felt that someone familiar with that part of th= e=20 system needs to have a look. This means the committer can either spend=20 additional time on understanding the surrounding codebase, or leave it for= =20 the subset of committers that have that understanding already. One observation is that there is no realistic way for the community of=20 non-committers to help effectively the committer in the sense of lessening= =20 the amount of work required to process the PR. What I suggest is a system where a group of non-committers systematically=20 pre-process PR:s, to provide feedback and additional quality assurance to t= he=20 committer that is to process the PR. This group of people could either be a self-proclaimed group of volunteers,= or=20 perhaps a group of people satisfying the criteria of "guy we kinda trust to= =20 do testing and provide a useful indication of sanity and correctness, but n= ot=20 with a commit bit". Given a fairly simple PR with a fairly simple patch, would not the work of = the=20 committer be greatly lessened if there was a track record of the=20 above "pre-processors" shows that <n> people have performed building and=20 testing of the patched version on architectures/environments, <x, y and z>,= =20 and that they generally like the patch (or that they don't)? One possible answer to this that I have gotten in the past with another=20 project, is that noone is stopping me from just grabbing a bunch of PR:s an= d=20 posting follow-ups saying I've tested something, or otherwise giving=20 feedback. The problem is that there is no real indication that this will cause anythi= ng=20 to happen other than generating more E-Mail traffic. What I suggest may make the difference is to have a *system* for this.=20 Preferably with software to support it. =46or example, patches with a high confidence of correctness due to many pe= ople=20 affirming that they have tested it could be automatically prioritized for=20 committers to deal with, and there will be a clear and systematic record of= =20 what testing was done, and by who. And the individual contributor (for=20 testing) can really feel that the time spent was worthwhile, because the=20 feedback was taken by the system and used for actual effect. When I talk about priority above, I do not mean to imply that any committer= =20 should work on things they do not want to work on. But I have to assume tha= t=20 a lot of patches get committed because a committer decided to go and pick a= =20 few PR:s to process, rather than the committer necessarily has a burning=20 interest in that particular patch. As such, if said committer could spend those <n> minutes closing five times= as=20 many PR:s because the up-front confidence in the correctness of the patch i= s=20 so much higher, perhaps it would help the system to "scale", moving some of= =20 the burden off the committers. Perhaps one can either go so far as to have "full committers" give their=20 blessing for a particular patch, possibly based on feedback such as above,= =20 but leave the act of actually commiting the patch and doing the actual smok= e=20 testing (that it builds etc) to someone who does have a commit bit and is=20 trusted with it, but is not allowed to make any commits that are not direct= ly=20 blessed by a "full" committer. There is some precedent for similar systems. Squeak had the concept=20 of "harvesters". They seem to have changed things a bit nowadays, but=20 seemingly use a similar approach still (I am no longer up to date): http://wiki.squeak.org/squeak/3152 (see the comment/review/vote period) =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart9162351.RhgJZhdn8N Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHh7cGDNor2+l1i30RAkZ6AJsEsFA8YIPJhofQ1NdsgdE7yuLsHACg4GKQ QFqwG58365226dPAFnTkCQc= =O2cn -----END PGP SIGNATURE----- --nextPart9162351.RhgJZhdn8N--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801111935.50821.peter.schuller>