Re: Solutions for the PR load problem
On 09/07/2010 23:56, Shaun Amott wrote: On Fri, Jul 09, 2010 at 10:51:01PM +0200, Dominic Fandrey wrote: 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). Sure, I would be more likely to look at / commit your patches in a timely fashion if you've done part of the work for me. I'm pretty sure it helped back when I was submitting lots of ports PRs. I ordered the machine last weekend. It won't run 24/7 or be remotely accessible, but when I get comfortable with the process, I can start testing other PRs and attach links to the test logs. I think this is about as helpful as I can afford get at the moment. On a side note, I only bought 8GB RAM, because of the ridiculous pricing. I'll have to pay as much as I paid a couple of months ago for the same amount for my notebook. 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Solutions for the PR load problem
On Fri, Jul 09, 2010 at 10:51:01PM +0200, Dominic Fandrey wrote: On 09/07/2010 22:00, Shaun Amott wrote: 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? The more complex a port is and the more dependencies it has the more work a committer has to check if the PR is error-free. Having TB-Logs would prove that the port builds fine, and the PR is more likely to be taken. It's also better for the submitter as he can see if he has made any errors. pgpbNcxPoIbT4.pgp Description: PGP signature
Re: Solutions for the PR load problem
On Fri, 09 Jul 2010 18:15:58 +0200 Dominic Fandrey kamik...@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Solutions for the PR load problem
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Solutions for the PR load problem
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Solutions for the PR load problem
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Solutions for the PR load problem
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Solutions for the PR load problem
On Fri, Jul 09, 2010 at 10:51:01PM +0200, Dominic Fandrey wrote: 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. Indeed, part of the problem is burn-out. We recruit committers, and then their activity tapers off (I'm guilty of this myself). Part of this, I believe, is down to the effort involved in maintaining a useful (up-to-date) testing environment -- hence my advocacy of a centralised tinderbox resource. The machines I used to use are out-of-date and probably inadequate now. I don't disagree in principle with the idea of having a middle ground, just not sure (how) it would work in practice. 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). Sure, I would be more likely to look at / commit your patches in a timely fashion if you've done part of the work for me. I'm pretty sure it helped back when I was submitting lots of ports PRs. -- Shaun Amott // PGP: 0x6B387A9A A foolish consistency is the hobgoblin of little minds. - Ralph Waldo Emerson ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
