Date: Fri, 09 Jul 2010 22:51:01 +0200 From: Dominic Fandrey <kamikaze@bsdforen.de> To: Shaun Amott <shaun@FreeBSD.org> Cc: freebsd-ports@freebsd.org Subject: Re: Solutions for the PR load problem Message-ID: <4C378BB5.2080206@bsdforen.de> In-Reply-To: <20100709200016.GA23404@charon.picobyte.net> References: <4C374B3E.90704@bsdforen.de> <20100709172503.GA22795@charon.picobyte.net> <4C375E47.9020307@bsdforen.de> <20100709200016.GA23404@charon.picobyte.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/07/2010 22:00, Shaun Amott wrote: > On Fri, Jul 09, 2010 at 07:37:11PM +0200, Dominic Fandrey wrote: >> >> On 09/07/2010 19:25, Shaun Amott wrote: >>> On Fri, Jul 09, 2010 at 06:15:58PM +0200, Dominic Fandrey wrote: >>>> >>>> To solve this problem with the current organization, my guess is >>>> that between 15 and 30 new active committers are required. >>>> Because I don't think this is easily achieved I want to suggest >>>> a different approach. And I expect many others also have their >>>> own ideas how this can be solved. >>>> >>>> Proposal: >>>> My idea is that experienced Maintainers get commit permission >>>> for their own ports. I don't even think such a thing needs to >>>> be enforced technically, after all who'd want to risk his >>>> experienced maintainer bit, however this is possible (and people >>>> would probably sleep better). >>>> > > (apologies for my dodgy quoting...) > >>> >>> The whole VCS debate has been had over and over; I think that for the >>> time being it is more constructive to look at changes we can make to our >>> existing processes. Anything that requires switching from CVS isn't >>> going to happen any time soon. >> >> You can also do this with CVS. > > Ok - but how do we define "experienced"? Someone who has submitted 100 > PORTVERSION++ PRs? I'm not convinced we have enough contributors who are > experienced enough to be given commit rights, but not contributing > enough to be offered full access. Well, I don't see a mass recruiting plan in action and the typical response time for a ports PR has dropped from a couple of hours to something around a month following a singular event everyone here probably already knows about. Though there are a lot of committers, there aren't many active committers. The need seems obvious to me and I figured it would be obvious to create some middle ground where the demands from both sides are less. > Cases where other ports need touching (e.g., library bumps), or an > update depends on another port/PR elsewhere could prove to be > problematic. Those are the kind of maintainers that have the commit bit anyway. People who do the major stuff like Xorg, KDE, gnome, autobreak ... I think those are also the people who carry the main burden of Maintainer PRs. They really shouldn't have to, they've got more than enough work. >>> One thing that is sorely missed -- by me, at least -- is the ports >>> tinderbox mini-cluster we had previously (graciously provided by simon >>> and erwin). The major bottleneck in the review/commit process is the >>> testing part (again, I speak for myself). A set of tinderbox machines >>> representing the tier-1 architectures, to which we could grant >>> contributors access, would reduce the burden on committers (if a >>> patch/PR arrives with an accompanying log file). >> >> What needs to be done? (I.e. money, work hours) > > Machine(s), rack-space, someone to maintain said machines to a decent > standard. Possibly money could solve these issues. :-) > > I'm not sure how many non-committers were aware of / given access to tb3 > and tb4 when they were around, but if tinderbox were used as a matter of > course, it would, I believe go some way to speeding things up. > So if I set up a private tinderbox and provide amd64 and i386 6-/7-/8-stable logs with every PR I submit it would hasten the processing of my PRs? If that is so, I'll get me a small quad-core with ~16GB RAM and a huge hard disk just for this purpose (my largest hard disk is the one in my notebook, not sufficient for all the distfiles and packages). Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C378BB5.2080206>