Solutions for the PR load problem [Ports]

Prev: FreeBSD Port: devel/mercurial
Next: can somebody attend this PR???

From: Dominic Fandrey on 9 Jul 2010 12:15

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

From: Chris Rees on 9 Jul 2010 12:26

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

From: Chris Rees on 9 Jul 2010 12:26

From: Gary Jennejohn on 9 Jul 2010 12:50

On Fri, 09 Jul 2010 18:15:58 +0200
Dominic Fandrey <kamikaze(a)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).
>

Are you aware that the ports tree was in freeze/slush for the 8.1
release? This was just lifted.

Not much happens when that's the case.

--
Gary Jennejohn
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Dominic Fandrey on 9 Jul 2010 12:59

On 09/07/2010 18:50, Gary Jennejohn wrote:
> On Fri, 09 Jul 2010 18:15:58 +0200
> Dominic Fandrey <kamikaze(a)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).
>>
>
> Are you aware that the ports tree was in freeze/slush for the 8.1
> release? This was just lifted.
>
> Not much happens when that's the case.

I'm not sweeping talking about sweeping commits and the problem has
become apparent months ago.

And while the number of ports is steadily increasing, the number
of commits appears to be declining slightly.

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

| Next | Last
Pages: 1 2 3 4
Prev: FreeBSD Port: devel/mercurial
Next: can somebody attend this PR???