Solutions for the PR load problem

[Dominic Fandrey]

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?