Prev: FreeBSD Port: devel/mercurial
Next: can somebody attend this PR???
From: Dominic Fandrey on 9 Jul 2010 13:26
On 09/07/2010 18:26, Chris Rees wrote:
> I think the people you describe as 'experienced' maintainers tend to be made
> committers anyway, or that's as far as I know.

What gives you that impression? ~180 committers that have been
active within the last 12 months (as in at least one commit), are
currently pitted against 915 open PRs. ~80 committers perform
more than 1 commit per week.

Of 440 committers the top 20 do more than 60% of the work.

The ports tree currently has more than 1700 maintainers. A small
number considering that they maintain almost 22000 ports, but
still there ought to be some potential to lift some of that burden
from the committers.

Sources:
http://people.freebsd.org/~peter/ports.window.txt
/usr/ports
FreeBSD bugtracking system

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: Shaun Amott on 9 Jul 2010 13:25
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).
>

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.

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

Shaun

--
Shaun Amott // PGP: 0x6B387A9A
"A foolish consistency is the hobgoblin
of little minds." - Ralph Waldo Emerson
_______________________________________________
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 13:37
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).
>>
>
> 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.

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


--
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: Shaun Amott on 9 Jul 2010 16:00
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.

Cases where other ports need touching (e.g., library bumps), or an
update depends on another port/PR elsewhere could prove to be
problematic.

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

--
Shaun Amott // PGP: 0x6B387A9A
"A foolish consistency is the hobgoblin
of little minds." - Ralph Waldo Emerson
_______________________________________________
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 16:51
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?
_______________________________________________
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"

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