Solutions for the PR load problem

[Chris Rees]

I think the people you describe as 'experienced' maintainers tend to be made
committers anyway, or that's as far as I know. There's little to be gained
by putting another rank of responsibility in, especially when a commit to
any port can cause huge wreckage; INDEX building, circular dependencies etc.

This is why only committers have commit access, as I see it.

--------

Sorry for top-posting, Android won't let me quote. There's a bug report on
it!

On 9 Jul 2010 17:16, "Dominic Fandrey" <kamikaze at bsdforen.de> wrote:

Currently the PR load is obviously too high for the committer team
to deal with. From a maintainer perspective this is rather painful,
I have currently stopped updating all my ports, because I want
pending updates committed first and also want to avoid running into
PR dependencies (ioquake3, openarena and iourbanterror are
examples in my case).

Also it adds the burden of adjusting your patches every time the
PORTREVISION is bumped, because of a library update, thus producing
additional workload without benefit to anyone.

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).

Technical Approach:
One, though not the only, technical approach is to switch to SVN
and use path based access control. A pretty primitive shell script,
probably less than 10 lines could generate the SVN path
configuration, from just a list of users. It need not even be
run on the server and wouldn't have to be run often.

There also exist solutions that add similar features to CVS, but
I do prefer SVN.

Pros:
- Less Maintainer-Update PRs
- Maintainers can deal with third party patches directly instead
 of just providing feedback, so the actual ports committers
 would only have to close the PRs
- Path based access control can be turned off during ports freezes

Cons:
- Higher server load
- Additional user management
- Testing guidlines in the Porters' Handbook need to be extended
- Experienced Maintainers have to be defined

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?
_______________________________________________
freebsd-ports at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"