Re: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Thu, Apr 28, 2011 at 07:16:47PM -0500, Mark Linimon wrote: On Thu, Apr 28, 2011 at 03:55:35PM -0400, Jerry wrote: Would you please rewrite it in basic English using proper sentence structure. Please note: although the primary language of the project is English, probably less than half of FreeBSD committers are native Enligsh speakers. See ports/xearth/files/freebsd.committers.markers. ports/astro/xearth/... Wow, that is cool! One problem with 23k ports is that a poor ignorant user (myself) sometimes doesn't know what is best for him/her. I was fretting about not having a native Google earth (I just don't like USE_LINUX=yes ports), yet here is another brilliant port. I just wonder why so few submitters on the list: BUZI wc /usr/local/lib/X11/xearth/freebsd.* 3352284 17912 /usr/local/lib/X11/xearth/freebsd.committers.markers 73 3863484 /usr/local/lib/X11/xearth/freebsd.ftp.markers 14 78 594 /usr/local/lib/X11/xearth/freebsd.submitters.markers 4222748 21990 total BUZI Mark, many thanks for the hint. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
Let's play let's pretend. Let's pretend I'n on the ports management team (true). Let's pretend I have enough influence to talk the rest of the ports management team into agreeing with me (very debatable, based on past performance.) Then, let's pretend that portmgr promotes a new policy, all PRs must be handled in a FIFO manner. So ... what will the committers say? Hey, no one asked me what I think, I didn't sign up for this, I think I'll find something else better to do. Wonder what's on TV? And what should the portmgrs do? Hold our breaths until we turn blue? Well. As pointed out above, portmgr can either: suspend someone's commit bit, or not. In general, we only suspend for a year of inactivity. (For maintainers, the timeout on PRs is 2 weeks; we can reset after 3 months of inactivity). Anything more aggressive than that, will simply discourage existing, and potential, volunteers: both maintainers, and commiters. IMVVHO. (And yes, behind the scenes portmgr does a lot of work with twisting arms nd asking are you sure you want to keep maintainership of port foo, since we have someone that seems willing to work on it? But that's not the same as adding a new requirement for committers, ex post facto.) mcl ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, 27 Apr 2011 16:42:26 -0700 Charlie Kester corky1...@comcast.net articulated: On Wed 27 Apr 2011 at 16:15:19 PDT Jerry wrote: Following through on that logic, only the highest priority items would ever get done. Since there is a never ending list of things that have to be done at any given time, the lowest priority ones would never get any attention. Which is as it should be, if it's true that we're faced with insufficient resources. I hope, no, I pray that one of your PR's falls into that category. I can't wait to see how long it takes your ass to get online bitching and moaning about the lack of attention given to your trivial submission. The problem is that we don't have any objective way to determine priorities. Instead we leave this up to the personal interests and whims of the people involved -- maintainers AND committers. If you had actually been paying attention rather than cherry picking assignments you would have noticed that this thread was about implementing a more effective protocol for handling submissions. The axiomatic statement, Lead, follow, or get out of the way. by Thomas Paine would seem apropos. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ You can lead a horse to water, but you can't stop him from running off into the desert and dying of thirst. ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
Am 28.04.2011 00:39, schrieb John Marino: I was working the assumption that he agrees to the port up front or voluntarily picks up the next task. However, if someone has a repeated history of refusals or only wants to do a very narrow set of tasks, then maybe commit bit removal isn't that dramatic. It will leave one frustrated committer who will likely turn his back to the project and leave altogether, and, that point was made before, leave his work undone -- and that means BOTH the work he didn't pick that you wanted to punish for, and the work he did do. And redistributing the latter is painful for all others. Given that committers aren't likely to inflict pain to themselves, such a system isn't going to be established. Let's for the sake of the argument assume that committers are neither deliberately brushing maintainers off, nor ignoring/neglecting them, nor bored. If you work with volunteers, you need incentive, not repression or threat. Robert suggested a who's who of committers, which might be helpful for some auto-assignment after a week or two. I for one am not against such auto-assignments, and I believe that there's some overhead in the status quo that causes this to NOT happen. Teaming up maintainers for a set of ports means setting up aliases or lists. Teaming up committers for a set of ports either happens through projects such as KDE or GNOME, or not at all. I for one am also open for teaming up and getting some ports in my areas of expertise auto-assigned to me, but I am not actively looking for them. Let's think a bit more about Robert's who's who list, what it could be used for (technical auto-assignment after timeouts, or a mere contacts list for maintainers were mentioned), and about incentive for committers. The cheapest incentive would be to make some process easier. Now, what to we want to make easier? For committers? For maintainers? How can we keep maintainers in a good mood and motivated even if their submissions linger for longer than they feel fair? ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
Am 28.04.2011 01:25, schrieb Jerry: On Thu, 28 Apr 2011 00:54:45 +0200 Olli Hauer oha...@freebsd.org articulated: Maybe you have some time to spend? Before I could reasonable be expected to set aside time, I would need a detailed job description, etcetera. Perhaps you can supply me with one? See, and that's what committers might think, too: 'before I do lots of paperwork, I get something else done.' Be that some PR filed by someone else than you, or reading a book rather than doing ports work. :-) Counting recreation into something else because it's also useful to make any headway sustainably. ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
Am 27.04.2011 13:54, schrieb Jerry: Personally, I believe that the current system, if not partially broken, is far from ideal. I would prefer to see a system where each submitted PR is assigned a specific number (I believe it is actually) and then assigned in numeric order to the next available committer. That committer would then be responsible for either committing the PR/Port/Whatever within a preset time frame, or informing the original submitter why the said article was not/could not be approved at the present time. Allowing a submitter to languish while pondering what has become of their document certainly does seem justified. Greetings, I know from the times when I wasn't a committer that it was sometimes frustrating if PRs were lingering for weeks. Your idea of assigning ports to committers rests upon the assumption that all port/update submissions were equal with respect to the sub-tasks to be performed by a committer, and/or the required skills. I for one am not knowledgeable about Ada or the related build systems such as GNAT ports, so I'd not usually pick up such a PR - Robert Huff mentioned something similar yesterday. Then there are many more non-trivial commits, with downstream dependencies, or dangerous to other ports, and these require more thorough testing, building downstream ports, possibly an experimental build of ALL ports, the so-called -exp run, documenting updating requirements and so on. These take time, and I've recently returned a port which, thankfully, mentioned -exp run advised or similar, that I couldn't tend to due to vacation, lack of time for holiday preparations, never having requested an -exp run before IOW I'd need to get acquainted with the procedures, and all that. I am sure that the old, But they are all volunteers, or some such tirade will erupt. It must be remembered that those who submit items for approval are also volunteers. They deserve at least as much respect as those who are actively working on those submitted items. True enough, but I think that committers are not disrespectful. I know that intent and feeling are different matters. I agree that transparency of the why hasn't my PR been addressed would be desirable to maintainers, but I don't see a technical solution to that, meaning that it requires manual action by committers. One idea might be to team up maintainers with committers somehow (I don't know how yet), so some kind of who-is-who list that Robert mentioned, might be useful. Providing it's up to date. But it requires setting up and maintenance, too. Again, I don't believe this kind of neglect is deliberate, as frustrating though it may be. Yes, we committers can do better, and it seems we're in some kind of unfreezing before a non-trivial change, and that thinking and talking about *how* to change our procedures has started and looks promising IMHO, and I've also skimmed Charlie-Hester's-stepping-down thread with pity (although I believe some misunderstanding, possibly across language boundaries, on both sides was a major part of that problem) It all will require some work before we will have changed though, procedural changes don't happen in a few days. Not with 2+ ports and established policies and procedures behind us anyways. So if we can abstract away from the frustration of individual ports not getting addressed to ideas HOW we can PRACTICALLY improve, we may actually achieve that desired improvement. I hope you can bear with us while we ponder the required changes. Best Matthias ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
Correct me if I'm wrong, but as I understand it committers have commit privilege for all ports. What if certain qualified port maintainers who aren't committers were nevertheless given commit access for only the leaf ports that they maintain? Wouldn't that speed up the overall process? -- .O. | Sterling (Chip) Camden | http://camdensoftware.com ..O | sterl...@camdensoftware.com | http://chipsquips.com OOO | 2048R/D6DBAF91 | http://chipstips.com pgpYGdRbkieYz.pgp Description: PGP signature
Re: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On 28 Apr 2011 20:08, Chip Camden sterl...@camdensoftware.com wrote: Correct me if I'm wrong, but as I understand it committers have commit privilege for all ports. What if certain qualified port maintainers who aren't committers were nevertheless given commit access for only the leaf ports that they maintain? Wouldn't that speed up the overall process? Search the archives for an answer or ten. Chris ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On 28 April 2011 20:23, Chris Rees utis...@gmail.com wrote: On 28 Apr 2011 20:08, Chip Camden sterl...@camdensoftware.com wrote: Correct me if I'm wrong, but as I understand it committers have commit privilege for all ports. What if certain qualified port maintainers who aren't committers were nevertheless given commit access for only the leaf ports that they maintain? Wouldn't that speed up the overall process? Search the archives for an answer or ten. Sorry for the terse response, touchscreen phones are horrible to email on. I've found one of the conversations I was thinking of [1] -- these often come up. It should probably be on some kind of FAQ list... Chris [1] http://www.mail-archive.com/freebsd-ports@freebsd.org/msg28399.html ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Thu, 28 Apr 2011 16:05:22 +0200 Matthias Andree mand...@freebsd.org articulated: Am 28.04.2011 01:25, schrieb Jerry: On Thu, 28 Apr 2011 00:54:45 +0200 Olli Hauer oha...@freebsd.org articulated: Maybe you have some time to spend? Before I could reasonable be expected to set aside time, I would need a detailed job description, etcetera. Perhaps you can supply me with one? See, and that's what committers might think, too: 'before I do lots of paperwork, I get something else done.' Be that some PR filed by someone else than you, or reading a book rather than doing ports work. :-) Counting recreation into something else because it's also useful to make any headway sustainably. No disrespect meant; however, I just showed your response to two other individuals who both concurred with me that your reply is nonsensical. Would you please rewrite it in basic English using proper sentence structure. Perhaps we should start at the beginning. Do you know what a Job Description http://en.wikipedia.org/wiki/Job_description actually is? -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
Jerry, I realize that you care deeply about this topic, however IMO your last few posts are a little more vitriolic than we we usually like to see on the FreeBSD lists. (And yes, I'm sure your response would be that this is not how they were intended, so I'll save you time writing it.) You need to realize that the FIFO PR assignment idea is not going to happen. Given that it's not going to happen, you might want to reconsider whether or not continuing to post on the topic will be helpful. Meanwhile, I would like to request (on a personal level, I'm not in charge of anything) that you take 24 hours off and refrain from posting altogether. Then if you still feel strongly that you have something to say (keeping in mind paragraph 2 above) the hope would be that with a little time to cool off you can say it with less emotion. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
Am 28.04.2011 21:55, schrieb Jerry: On Thu, 28 Apr 2011 16:05:22 +0200 Matthias Andree mand...@freebsd.org articulated: Am 28.04.2011 01:25, schrieb Jerry: On Thu, 28 Apr 2011 00:54:45 +0200 Olli Hauer oha...@freebsd.org articulated: Maybe you have some time to spend? Before I could reasonable be expected to set aside time, I would need a detailed job description, etcetera. Perhaps you can supply me with one? See, and that's what committers might think, too: 'before I do lots of paperwork, I get something else done.' Be that some PR filed by someone else than you, or reading a book rather than doing ports work. :-) Counting recreation into something else because it's also useful to make any headway sustainably. No disrespect meant; however, I just showed your response to two other individuals who both concurred with me that your reply is nonsensical. Would you please rewrite it in basic English using proper sentence structure. Perhaps we should start at the beginning. Do you know what a Job Description http://en.wikipedia.org/wiki/Job_description actually is? Neither did I mean disrespect. What I'm saying is: You expect a job description before committing more of your time and working power to volunteer work on FreeBSD ports. However, for a FreeBSD committer, I can fancy not all of them are interested in something that gets too formal -- which would be a consequence of PR FIFO assignments or similar. Their idea is to care about some set of ports they are interested in, have a need in, and also have some expertise on. A clear job description with strict fail to respond on stuff you hardly know and have no interest in X times in Y weeks and get all other work privileges removed is what I alluded to when writing paperwork. Personally, I would rather want to contribute to something where I can just work on some of the ports, rather than having someone else assign me PRs. I am fully aware that we cannot *guarantee* any service level this way. And I've myself been in situations when I had to accept that committers (or packagers for other projects) priorize (prioritize?, anyways, rank in their ordering of the tasks) my PR different than I'd hoped for. I may have found that unfair, but talking about starting at the beginning, not everybody's idea of fair will be the same. :-) Now I fail to see what incentive you'll provide to committers so that they actually adhere to an external PR assignment. While I'm only speaking on my behalf through the whole discussion, I read between other people's lines that I'm not alone with this opinion. I hope that is clearer now. ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
Am 28.04.2011 21:07, schrieb Chip Camden: Correct me if I'm wrong, but as I understand it committers have commit privilege for all ports. What if certain qualified port maintainers who aren't committers were nevertheless given commit access for only the leaf ports that they maintain? Wouldn't that speed up the overall process? It looks like you're asking for a technical solution to a non-technical problem. Chris Rees has posted an archive link, and my take is that we're already trying to ask such qualified port maintainers to become ports committers and not care too much about how fine-grained ports access is. ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
--On April 28, 2011 10:52:32 PM +0200 Matthias Andree mand...@freebsd.org wrote: Am 28.04.2011 21:07, schrieb Chip Camden: Correct me if I'm wrong, but as I understand it committers have commit privilege for all ports. What if certain qualified port maintainers who aren't committers were nevertheless given commit access for only the leaf ports that they maintain? Wouldn't that speed up the overall process? It looks like you're asking for a technical solution to a non-technical problem. Chris Rees has posted an archive link, and my take is that we're already trying to ask such qualified port maintainers to become ports committers and not care too much about how fine-grained ports access is. I personally think it's a bad idea for a port maintainer to be the committer for their own ports. Getting even minor changes committed to the tree should require two independent sets of eyes. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson There are some ideas so wrong that only a very intelligent person could believe in them. George Orwell ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Thu, Apr 28, 2011 at 03:55:35PM -0400, Jerry wrote: Would you please rewrite it in basic English using proper sentence structure. Please note: although the primary language of the project is English, probably less than half of FreeBSD committers are native Enligsh speakers. See ports/xearth/files/freebsd.committers.markers. mcl ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, Apr 27, 2011 at 08:05:43AM +0200, John Marino wrote: Since we're already in the mood to discuss FreeBSD ports issues, maybe somebody can clear something up for me. Several days ago, I submitted a patch for a port I maintain: ports/156541 [MAINTAINER] Upgrade lang/gnat-aux to release version and add C++ Nobody has touched it, but many other PRs after that submission have been assigned, etc. So I have two questions: 1) What's involved with processing a patch from a maintainer? Is it simply a committer commits it on behalf of the maintainer (iow very easy?). Or is it the other end of the spectrum where it has to go through Tinderbox? I would assume the maintainer is trusted and the patch is applied without testing. A committer is always responsible for his/her commits and so should do at least minimal testing of any patches even if it is from a maintainer. 2) I have very well aware that people dedicate their own time, etc, and I think that explains why the PRs are getting cherry picked. But seriously, shouldn't there be a policy to process these PRs in order? Not really, since some PRs might require a *lot* of work (and/or might be controversial) and thus could block other, far simpler, PRs if they were taken strictly in order. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, Apr 27, 2011 at 10:05 AM, John Marino freebs...@marino.st wrote: Several days ago, I submitted a patch for a port I maintain: ports/156541 [MAINTAINER] Upgrade lang/gnat-aux to release version and add C++ Nobody has touched it, but many other PRs after that submission have been assigned, etc. Ha, i've submitted mine about two months ago and still no luck. ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, 27 Apr 2011 11:57:47 +0400 arrowdodger 6year...@gmail.com articulated: On Wed, Apr 27, 2011 at 10:05 AM, John Marino freebs...@marino.st wrote: Several days ago, I submitted a patch for a port I maintain: ports/156541 [MAINTAINER] Upgrade lang/gnat-aux to release version and add C++ Nobody has touched it, but many other PRs after that submission have been assigned, etc. Ha, i've submitted mine about two months ago and still no luck. Personally, I believe that the current system, if not partially broken, is far from ideal. I would prefer to see a system where each submitted PR is assigned a specific number (I believe it is actually) and then assigned in numeric order to the next available committer. That committer would then be responsible for either committing the PR/Port/Whatever within a preset time frame, or informing the original submitter why the said article was not/could not be approved at the present time. Allowing a submitter to languish while pondering what has become of their document certainly does seem justified. I am sure that the old, But they are all volunteers, or some such tirade will erupt. It must be remembered that those who submit items for approval are also volunteers. They deserve at least as much respect as those who are actively working on those submitted items. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Every time you manage to close the door on Reality, it comes in through the window. ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On 27 Apr 2011 12:55, Jerry je...@seibercom.net wrote: On Wed, 27 Apr 2011 11:57:47 +0400 arrowdodger 6year...@gmail.com articulated: On Wed, Apr 27, 2011 at 10:05 AM, John Marino freebs...@marino.st wrote: Several days ago, I submitted a patch for a port I maintain: ports/156541 [MAINTAINER] Upgrade lang/gnat-aux to release version and add C++ Nobody has touched it, but many other PRs after that submission have been assigned, etc. Ha, i've submitted mine about two months ago and still no luck. Personally, I believe that the current system, if not partially broken, is far from ideal. I would prefer to see a system where each submitted PR is assigned a specific number (I believe it is actually) and then assigned in numeric order to the next available committer. That committer would then be responsible for either committing the PR/Port/Whatever within a preset time frame, or informing the original submitter why the said article was not/could not be approved at the present time. Allowing a submitter to languish while pondering what has become of their document certainly does seem justified. I am sure that the old, But they are all volunteers, or some such tirade will erupt. It must be remembered that those who submit items for approval are also volunteers. They deserve at least as much respect as those who are actively working on those submitted items. How do you define respect? I find the committers extremely respectful. Chris ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
Jerry writes: Ha, i've submitted mine about two months ago and still no luck. Personally, I believe that the current system, if not partially broken, is far from ideal. I would prefer to see a system where each submitted PR is assigned a specific number (I believe it is actually) and then assigned in numeric order to the next available committer. Not all committers are created equal. Asking Joe-the-fonts- guru to work on Mary's network monitoring application is probably not productive. Keeping a centralized list of who/what pairs - more importantly, keeping it useful - is another job on someone's desk. Are you that someone? I am sure that the old, But they are all volunteers, or some such tirade will erupt. Not a tirade, but ... guilty. It must be remembered that those who submit items for approval are also volunteers. They deserve at least as much respect as those who are actively working on those submitted items. Am I correct you are asking for a (far) higher level of dedication from the committers than from those who submit changes? Consider the port that goes untouched (in spite of substantial upstream changes) for months or even years; someone picks up the torch, and the poor committer gets N-thousend lines of new features, security patches, and dependency changes dumped on them to be checked in ... how long was that? Do I think there are flaws in the current system? Sure. But as long as we're faced with this particular choice of evils - slow updating versus lowered quality - I vote first, do no harm. Respectfully, Robert Huff ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, 27 Apr 2011 13:00:17 +0100 Chris Rees utis...@gmail.com articulated: How do you define respect? I find the committers extremely respectful. Allowing a submitter to languish for an indeterminate period without any notification of what is transpiring with his/her submission is not respectful, it is benign neglect. As I stated, each submitted item should be handled in a basic FIFO order unless there is a specific reason for not doing so. If such reason exists then the original submitter should be informed of this irregularity. Waiting for months while items submitted after the submitter's item are approved without notifying the submitter of why is certainly not friendly or respectful, unless of course you work for the motor vehicle or parking department in which case it is just business as usual. I have been at both extremes of the spectrum on this, having had items committed within days and conversely waiting for an extended period of time and finally asking specifically why an item was not committed before anything happened. The present system is broken, or at the very least poorly implemented, unless the goal is to keep a submitter in the dark. I reiterate, there is no logical reason to jump over one user's submission and proceed with another user's submission without formally notifying the submitter of the older item why his/her item is being bypassed. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
Personally, I believe that the current system, if not partially broken, is far from ideal. Speaking as a ports committer, I do agree with you that the current workflow that we have in place is less then ideal for the size of the ports tree as well as the number of patches that we receive. When the current workflow was first developed, the ports tree was much smaller and easier to work with. It has grown to over 23,000 ports and we are starting to see scaling issues. However, these issues have been known for quite some time. Behind the scenes, numerous ideas have been kicked around on how to better deal with contributions from independent developers, how to accept and review patches quicker and how to generally streamline our workflow. Unfortunately, the problem really becomes that unless we want to severely disrupt what we currently have in place for an extended period of time, we can really only make small gradual changes and hope that eventually we end up in a better position then when we started. I would prefer to see a system where each submitted PR is assigned a specific number (I believe it is actually) and then assigned in numeric order to the next available committer. That committer would then be responsible for either committing the PR/Port/Whatever within a preset time frame, or informing the original submitter why the said article was not/could not be approved at the present time. Allowing a submitter to languish while pondering what has become of their document certainly does seem justified. The problem with this system is that certain developers sometimes only work on a certain subset of the tree. Your fifo system does not take that into account For example, I maintain quite a few perl modules and often grab PRs for perl related things. This is mainly because I have an interest in keeping the perl stuff in good shape because I use it every day. I generally never deal with any PR that deals with ruby since I don't use ruby. As a result, I am not familiar with the ruby specific knobs in the ports tree. I would rather let another developer who is familiar with those and has an interest in keeping ruby well maintained deal with those PRs. Unfortunately, from time to time, the person who deals with the ruby stuff could be swamped with work or family issues and is unable to attend to it as quickly as I may have been able to. Would you prefer to wait a little while longer for that person to grab the PR, or would you rather have me commit the patch and possibly break your application running in production? Also, with your fifo system, what would happen if I don't commit an update within the allotted time frame? Perhaps the happy medium is that if you submit a PR and it doesn't get assigned for a few days, maybe ask in #bsdports on irc if someone could take a look at the PR. If you submit a patch and it does get assigned but a few days goes by and it doesn't get committed, we could update the PR to let you know that we haven't had a chance to look at it but hope to have a little bit of time in the next few days to take care of it. ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, 27 Apr 2011 08:50:52 -0400 Robert Huff roberth...@rcn.com articulated: Jerry writes: Ha, i've submitted mine about two months ago and still no luck. Personally, I believe that the current system, if not partially broken, is far from ideal. I would prefer to see a system where each submitted PR is assigned a specific number (I believe it is actually) and then assigned in numeric order to the next available committer. Not all committers are created equal. Asking Joe-the-fonts- guru to work on Mary's network monitoring application is probably not productive. Keeping a centralized list of who/what pairs - more importantly, keeping it useful - is another job on someone's desk. Are you that someone? I am sure that the old, But they are all volunteers, or some such tirade will erupt. Not a tirade, but ... guilty. It must be remembered that those who submit items for approval are also volunteers. They deserve at least as much respect as those who are actively working on those submitted items. Am I correct you are asking for a (far) higher level of dedication from the committers than from those who submit changes? Consider the port that goes untouched (in spite of substantial upstream changes) for months or even years; someone picks up the torch, and the poor committer gets N-thousend lines of new features, security patches, and dependency changes dumped on them to be checked in ... how long was that? Do I think there are flaws in the current system? Sure. But as long as we're faced with this particular choice of evils - slow updating versus lowered quality - I vote first, do no harm. I am not sure how the Hippocratic Oath got involved here. In any case, I see no reason why the slow and lowered qualities cannot find happiness together. Please reread what I posted. I stated that if a submitter's item was to be delayed for an extended period or bypassed in favor of a later submission by another submitter then the submitter of the older item should be notified as to why and if possible given an approximate commit date. I fail to see why that would cause undo stress or an unbearable burden on the committer(s). The committer(s) could create a boiler plate document to handle just such cases. However, I do find troubling you statement regarding a large update to an older port or even a new port submission for that matter. I see no logical reason for a committer to bypass an item simple based on its size or the amount of work involved in getting it committed. After all, consider that the original submitter invested a large amount of his/her time in that same item. The only honest and fair way to handle ports request is on a FIFO basis unless a bona fied excuse can be shown to deviate from that procedure. To simplify the system, a two week limit, or whatever reasonable time frame can be agreed upon, should be put into effect. Any submitted item that cannot be committed within that time frame would require the committer to notify the submitter of such and if possible a reasonable date to complete the commit. I do not believe that, that is by any stretch of the imagination excessive. Many government and private organizations work under those same basic constraints without undo harm. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ The great nations have always acted like gangsters and the small nations like prostitutes. Stanley Kubrick ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, 27 Apr 2011 09:17:46 -0400 Steven Kreuzer skreu...@freebsd.org articulated: Personally, I believe that the current system, if not partially broken, is far from ideal. Speaking as a ports committer, I do agree with you that the current workflow that we have in place is less then ideal for the size of the ports tree as well as the number of patches that we receive. When the current workflow was first developed, the ports tree was much smaller and easier to work with. It has grown to over 23,000 ports and we are starting to see scaling issues. However, these issues have been known for quite some time. Behind the scenes, numerous ideas have been kicked around on how to better deal with contributions from independent developers, how to accept and review patches quicker and how to generally streamline our workflow. Unfortunately, the problem really becomes that unless we want to severely disrupt what we currently have in place for an extended period of time, we can really only make small gradual changes and hope that eventually we end up in a better position then when we started. I would prefer to see a system where each submitted PR is assigned a specific number (I believe it is actually) and then assigned in numeric order to the next available committer. That committer would then be responsible for either committing the PR/Port/Whatever within a preset time frame, or informing the original submitter why the said article was not/could not be approved at the present time. Allowing a submitter to languish while pondering what has become of their document certainly does seem justified. The problem with this system is that certain developers sometimes only work on a certain subset of the tree. Your fifo system does not take that into account For example, I maintain quite a few perl modules and often grab PRs for perl related things. This is mainly because I have an interest in keeping the perl stuff in good shape because I use it every day. I generally never deal with any PR that deals with ruby since I don't use ruby. As a result, I am not familiar with the ruby specific knobs in the ports tree. I would rather let another developer who is familiar with those and has an interest in keeping ruby well maintained deal with those PRs. Unfortunately, from time to time, the person who deals with the ruby stuff could be swamped with work or family issues and is unable to attend to it as quickly as I may have been able to. Would you prefer to wait a little while longer for that person to grab the PR, or would you rather have me commit the patch and possibly break your application running in production? Also, with your fifo system, what would happen if I don't commit an update within the allotted time frame? Perhaps the happy medium is that if you submit a PR and it doesn't get assigned for a few days, maybe ask in #bsdports on irc if someone could take a look at the PR. If you submit a patch and it does get assigned but a few days goes by and it doesn't get committed, we could update the PR to let you know that we haven't had a chance to look at it but hope to have a little bit of time in the next few days to take care of it. Thank you. A well thought out reply and one that I can agree with in most aspects. I think that 'UPDATING' the PR to let the submitter know that he/she has not been forgotten and to keep them aware of any problems with the PR is certainly a welcome suggestion. Unfortunately, that is rarely presently done. Certainly, we should all be able to come to some consensus as to what constitutes a reasonable time frame. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, Apr 27, 2011 at 09:32:58AM -0400, Jerry wrote: On Wed, 27 Apr 2011 08:50:52 -0400 However, I do find troubling you statement regarding a large update to an older port or even a new port submission for that matter. I see no logical reason for a committer to bypass an item simple based on its size or the amount of work involved in getting it committed. After all, consider that the original submitter invested a large amount of his/her time in that same item. Very simple. A particular committer during one particular period of time maybe only 45 minutes of free time to spend on handling PRs. If the committer estimates that one large submitted PR would take at least two hours to review, test, and commit, while another, smaller, PR would only take 30 minutes to handle. Then the committer in question would have two choices: Don't handle either submission, or handling the smaller submission, while skipping the large one and hoping that some other committer with more free time will pick up that one. I see no reason to prefer the first of these choices. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, 27 Apr 2011 15:48:36 +0200 Erik Trulsson ertr1...@student.uu.se articulated: On Wed, Apr 27, 2011 at 09:32:58AM -0400, Jerry wrote: On Wed, 27 Apr 2011 08:50:52 -0400 However, I do find troubling you statement regarding a large update to an older port or even a new port submission for that matter. I see no logical reason for a committer to bypass an item simple based on its size or the amount of work involved in getting it committed. After all, consider that the original submitter invested a large amount of his/her time in that same item. Very simple. A particular committer during one particular period of time maybe only 45 minutes of free time to spend on handling PRs. If the committer estimates that one large submitted PR would take at least two hours to review, test, and commit, while another, smaller, PR would only take 30 minutes to handle. Then the committer in question would have two choices: Don't handle either submission, or handling the smaller submission, while skipping the large one and hoping that some other committer with more free time will pick up that one. I see no reason to prefer the first of these choices. If the committer cannot finish the project in their allotted time frame they simply stop and pick up from that point in their next session. I have literally hundreds of projects that I cannot complete in one day; however, I don't simply shrug them off. If I did nothing would ever get accomplished, or at best only the easiest assignments. One of the basic fallacies in your analysis is that someone else will pick up the slack. Unfortunately, our society has become over run by those who are always ready to blame others or expect others to do our job for us. Quite honestly, I find that pathetic. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On 4/27/2011 4:12 PM, Jerry wrote: On Wed, 27 Apr 2011 15:48:36 +0200 Erik Trulssonertr1...@student.uu.se articulated: On Wed, Apr 27, 2011 at 09:32:58AM -0400, Jerry wrote: Very simple. A particular committer during one particular period of time maybe only 45 minutes of free time to spend on handling PRs. If the committer estimates that one large submitted PR would take at least two hours to review, test, and commit, while another, smaller, PR would only take 30 minutes to handle. Then the committer in question would have two choices: Don't handle either submission, or handling the smaller submission, while skipping the large one and hoping that some other committer with more free time will pick up that one. I see no reason to prefer the first of these choices. If the committer cannot finish the project in their allotted time frame they simply stop and pick up from that point in their next session. I have literally hundreds of projects that I cannot complete in one day; however, I don't simply shrug them off. If I did nothing would ever get accomplished, or at best only the easiest assignments. One of the basic fallacies in your analysis is that someone else will pick up the slack. Unfortunately, our society has become over run by those who are always ready to blame others or expect others to do our job for us. Quite honestly, I find that pathetic. I seemed to have kicked off quite a dialog! First of all, I want to thank Frederic Culot for committing my patch today. Basically, I'm in complete agreement with Jerry with regards to FIFO. The proposal was made that given a short amount a time, a committer should choose the simpler project and bypass the first one simply based on time/complexity. I couldn't disagree more. As soon as it's possible to skip valid ports, then that's what is going to happen. If people can physically cherry-pick, then they'll exercise their ability to do that and immediately you sink into the current situation. Unfortunately, a FIFO setup requires that all the requests go through a single entity who then assigns them. I don't really buy the joe-the-font-guy with mary-the-network-gal mismatch. Nobody said the PRs have to be assigned as round-robin. And then that changes the dynamic since the PR is assigned rather than chosen. This entity can't just assign a PR without knowing the committer's timeline, availability, etc, so there are clearly implementation details to work out. Maybe a compromise would be to keep the current system in place with the addition of having somebody do these assignments if the new PRs are unclaimed for more than 3-7 days. Yes, it means a new job for someone, but if one believes that FIFO is the fair and respectful approach, the extra effort should be worth it. -- John ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On 27 April 2011 13:54, Jerry je...@seibercom.net wrote: On Wed, 27 Apr 2011 13:00:17 +0100 Chris Rees utis...@gmail.com articulated: How do you define respect? I find the committers extremely respectful. Allowing a submitter to languish for an indeterminate period without any notification of what is transpiring with his/her submission is not respectful, it is benign neglect. As I stated, each submitted item should be handled in a basic FIFO order unless there is a specific reason for not doing so. If such reason exists then the original submitter should be informed of this irregularity. Waiting for months while items submitted after the submitter's item are approved without notifying the submitter of why is certainly not friendly or respectful, unless of course you work for the motor vehicle or parking department in which case it is just business as usual. I have been at both extremes of the spectrum on this, having had items committed within days and conversely waiting for an extended period of time and finally asking specifically why an item was not committed before anything happened. The present system is broken, or at the very least poorly implemented, unless the goal is to keep a submitter in the dark. I reiterate, there is no logical reason to jump over one user's submission and proceed with another user's submission without formally notifying the submitter of the older item why his/her item is being bypassed. I believe the standard protocol is to jump on IRC and ask for advice -- it could be something very little -- or it's been lost in the swarm (less likely). I honestly don't think that there's much wrong with the system as it is; once you get better at making submissions, taking time to read the Porter's Handbook your patches become committed more and more quickly. Chris ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On 04/27/2011 06:45, Jerry wrote: I think that 'UPDATING' the PR to let the submitter know that he/she has not been forgotten and to keep them aware of any problems with the PR is certainly a welcome suggestion. Unfortunately, that is rarely presently done. If the PR is still open, it has not been forgotten. Committers have limited time available, would you rather have them spend time to make meaningless changes to open PRs, or would you rather have them spend that time working on closing some? Certainly, we should all be able to come to some consensus as to what constitutes a reasonable time frame. I hear you (and others) saying that they current system does not seem to be fair. I can certainly understand why you would feel that way. Unfortunately, there literally are not any other answers we can provide. This topic has come up periodically for all the years I've been involved in FreeBSD (contrary to what someone else said about it having been easier in the old days when the ports tree was smaller) and no one has come up with an answer for it yet. We try to identify and train new committers on a fairly aggressive pace, but that is also a volunteer effort. To summarize, we hear your frustration, and we ask you to be patient. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On 4/27/2011 8:55 PM, Chris Rees wrote: I honestly don't think that there's much wrong with the system as it is; once you get better at making submissions, taking time to read the Porter's Handbook your patches become committed more and more quickly. Chris Come on. There's no relationship between quality of the patch and when it's picked up by a commiter. I ran my patch through tinderbox until was right, and it's not like that made a difference. There is no way to tell the quality without taking a real look. There's plenty wrong with the current system. The real question is what's the most practical way to address it. John ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, Apr 27, 2011 at 08:54:05PM +0200, John Marino wrote: On 4/27/2011 4:12 PM, Jerry wrote: On Wed, 27 Apr 2011 15:48:36 +0200 Erik Trulssonertr1...@student.uu.se articulated: On Wed, Apr 27, 2011 at 09:32:58AM -0400, Jerry wrote: Very simple. A particular committer during one particular period of time maybe only 45 minutes of free time to spend on handling PRs. If the committer estimates that one large submitted PR would take at least two hours to review, test, and commit, while another, smaller, PR would only take 30 minutes to handle. Then the committer in question would have two choices: Don't handle either submission, or handling the smaller submission, while skipping the large one and hoping that some other committer with more free time will pick up that one. I see no reason to prefer the first of these choices. If the committer cannot finish the project in their allotted time frame they simply stop and pick up from that point in their next session. I have literally hundreds of projects that I cannot complete in one day; however, I don't simply shrug them off. If I did nothing would ever get accomplished, or at best only the easiest assignments. One of the basic fallacies in your analysis is that someone else will pick up the slack. Unfortunately, our society has become over run by those who are always ready to blame others or expect others to do our job for us. Quite honestly, I find that pathetic. I seemed to have kicked off quite a dialog! First of all, I want to thank Frederic Culot for committing my patch today. Basically, I'm in complete agreement with Jerry with regards to FIFO. The proposal was made that given a short amount a time, a committer should choose the simpler project and bypass the first one simply based on time/complexity. I couldn't disagree more. As soon as it's possible to skip valid ports, then that's what is going to happen. If people can physically cherry-pick, then they'll exercise their ability to do that and immediately you sink into the current situation. And if the committers can't choose what they are going to work on, you are likely going find yourself with a lot fewer committers fairly soon. Unfortunately, a FIFO setup requires that all the requests go through a single entity who then assigns them. And who is going to do all that extra work? You volunteering? I don't really buy the joe-the-font-guy with mary-the-network-gal mismatch. Nobody said the PRs have to be assigned as round-robin. And then that changes the dynamic since the PR is assigned rather than chosen. This entity can't just assign a PR without knowing the committer's timeline, availability, etc, so there are clearly implementation details to work out. Details indeed, and the devil is in the details as the saying goes. First of all there is no entity that knows about the timeline, availability, etc. of the various committers. The only way to get that information would be if committers were to report it at regular intervals which they don't have any reason to do. There is also the question of what to do if a committer doesn't like all the proposed extra rules and bureacracy and simply ignores a PR he has been assigned. There isn't really any way force a given committer to work on something he doesn't want to work on. The only sanction available is to remove the commit bit at which point you have one committer less, and that work still isn't done. Maybe a compromise would be to keep the current system in place with the addition of having somebody do these assignments if the new PRs are unclaimed for more than 3-7 days. Yes, it means a new job for someone, but if one believes that FIFO is the fair and respectful approach, the extra effort should be worth it. Worth it for who? Hardly to the guy who is going to do the extra work. As for fair you haven't convinced me why it should be a requirement. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed, Apr 27, 2011 at 10:12:57AM -0400, Jerry wrote: On Wed, 27 Apr 2011 15:48:36 +0200 Erik Trulsson ertr1...@student.uu.se articulated: On Wed, Apr 27, 2011 at 09:32:58AM -0400, Jerry wrote: On Wed, 27 Apr 2011 08:50:52 -0400 However, I do find troubling you statement regarding a large update to an older port or even a new port submission for that matter. I see no logical reason for a committer to bypass an item simple based on its size or the amount of work involved in getting it committed. After all, consider that the original submitter invested a large amount of his/her time in that same item. Very simple. A particular committer during one particular period of time maybe only 45 minutes of free time to spend on handling PRs. If the committer estimates that one large submitted PR would take at least two hours to review, test, and commit, while another, smaller, PR would only take 30 minutes to handle. Then the committer in question would have two choices: Don't handle either submission, or handling the smaller submission, while skipping the large one and hoping that some other committer with more free time will pick up that one. I see no reason to prefer the first of these choices. If the committer cannot finish the project in their allotted time frame they simply stop and pick up from that point in their next session. Or they can take a look at that project, decide that they are not interested in doing that particular project, and say Screw this, I have better things do with my free time and go off and read a book instead. I have literally hundreds of projects that I cannot complete in one day; however, I don't simply shrug them off. If I did nothing would ever get accomplished, or at best only the easiest assignments. Hundreds? Sounds a bit excessive if you were to ask me. If you have that many things to do then FIFO is a downright stupid way to approach them unless you know you have enough time to do *all* of them. (And it is rare that there is that much time available.) With that many things to do one needs to prioritize. First one should do the important stuff, and if there is any time left after having done that one might as well pick the fun projects, because there just isn't much point in doing boring, unimportant stuff. One of the basic fallacies in your analysis is that someone else will pick up the slack. Unfortunately, our society has become over run by those who are always ready to blame others or expect others to do our job for us. Quite honestly, I find that pathetic. And yet you are so quick at blaming committers for not doing things the way you think they should be done. Pot. Kettle. Black. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On 4/28/2011 12:18 AM, Erik Trulsson wrote: And if the committers can't choose what they are going to work on, you are likely going find yourself with a lot fewer committers fairly soon. As you notice, I never said they are limited what they work on. The order of the work is the focus. And who is going to do all that extra work? You volunteering? If finding a volunteer is the only thing holding a reform back, then we have nothing to worry about. Details indeed, and the devil is in the details as the saying goes. First of all there is no entity that knows about the timeline, availability, etc. of the various committers. The only way to get that information would be if committers were to report it at regular intervals which they don't have any reason to do. I thought it was clear that I was saying that wouldn't work. There is also the question of what to do if a committer doesn't like all the proposed extra rules and bureacracy and simply ignores a PR he has been assigned. There isn't really any way force a given committer to work on something he doesn't want to work on. The only sanction available is to remove the commit bit at which point you have one committer less, and that work still isn't done. I was working the assumption that he agrees to the port up front or voluntarily picks up the next task. However, if someone has a repeated history of refusals or only wants to do a very narrow set of tasks, then maybe commit bit removal isn't that dramatic. Worth it for who? Hardly to the guy who is going to do the extra work. As for fair you haven't convinced me why it should be a requirement. I don't consider it extra work. I consider it doing the job correctly. And if I need to convince you that fair is correct, then basically I just wasted 5 minutes answering this post. Jerry pretty much outlined why it's correct to process these things in order, or at some semblance of order. Look, your mind is made up. You like the status quo. Everything is fine and no effort should be made to improve. I'm not interested in a long, drawn out discussion. I just wanted to give my opinion which I did, so I'm done. John ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On 2011-04-27 16:12, Jerry wrote: On Wed, 27 Apr 2011 15:48:36 +0200 Erik Trulsson ertr1...@student.uu.se articulated: On Wed, Apr 27, 2011 at 09:32:58AM -0400, Jerry wrote: On Wed, 27 Apr 2011 08:50:52 -0400 However, I do find troubling you statement regarding a large update to an older port or even a new port submission for that matter. I see no logical reason for a committer to bypass an item simple based on its size or the amount of work involved in getting it committed. After all, consider that the original submitter invested a large amount of his/her time in that same item. Very simple. A particular committer during one particular period of time maybe only 45 minutes of free time to spend on handling PRs. If the committer estimates that one large submitted PR would take at least two hours to review, test, and commit, while another, smaller, PR would only take 30 minutes to handle. Then the committer in question would have two choices: Don't handle either submission, or handling the smaller submission, while skipping the large one and hoping that some other committer with more free time will pick up that one. I see no reason to prefer the first of these choices. If the committer cannot finish the project in their allotted time frame they simply stop and pick up from that point in their next session. I have literally hundreds of projects that I cannot complete in one day; however, I don't simply shrug them off. If I did nothing would ever get accomplished, or at best only the easiest assignments. One of the basic fallacies in your analysis is that someone else will pick up the slack. Unfortunately, our society has become over run by those who are always ready to blame others or expect others to do our job for us. Quite honestly, I find that pathetic. Maybe you have some time to spend? If my quick lookup was not totally wrong I cannot find one PR opened by you. http://www.freebsd.org/cgi/query-pr-summary.cgi?originator=seibercomclosedtoo=on ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On 04/27/2011 15:39, John Marino wrote: As you notice, I never said they are limited what they work on. The order of the work is the focus. John, You (and others) seem to be very focused on the idea of what's fair. Specifically you seem to believe that FreeBSD committers have a duty to handle PRs in a FIFO order, because that is what is most fair to the PR submitters. Short answer, that view is unrealistic, and will not be implemented. Longer answer. I understand your frustration. Those are not just empty words, I may be a committer for FreeBSD but I'm also an individual contributor for other projects, and I have to sit around and wait until someone looks at the bugs and/or patches that I contribute to those projects just like people contributing to FreeBSD do. It's really annoying to put a lot of work into a submission and then have it wallow in the queue. No one is denying that. However, and I realize that many of you don't like this answer, but it's the truth. This *is* a volunteer project. If we tried to require committers to do what you suggest, we'd lost most of them. Let me give you a very real, concrete example. Recently I picked up a new task, and needed a tool to do that task. We had a version of the tool in the ports collection but it was out of date. Before embarking on updating it myself, I looked in the PR db, and there was exactly what I needed, a patch to update the port to the latest version. Now let's assume that we adopted your rule. At that point I would have 2 options. Either commit all the patches between it and the one I needed, or leave the patch uncommitted. I'm a busy guy, I have a lot of demands on my time. (And don't forget, I got here because I have an actual project that needs to be finished.) Is it fair to me to require me to do all of that unrelated work just so I can get this one patch into the tree? Is it fair to the submitter of the patch that I _not_ commit it because I don't have the time to do all that other work? Let's look at it another way. Let's suppose we implement your idea, but in order to make it more practical we implement a companion policy that before you can _submit_ a patch you have to go through all the other patches in the queue ahead of yours and test them, then submit your findings. (We're going to do this because that way when a committer gets around to a patch they will have a very good idea of whether it's suitable or not.) Is that fair to you? How many patches do you think we'd get from individual contributors if we required that amount of work before you could even submit a patch? hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Thu, 28 Apr 2011 00:33:05 +0200 Erik Trulsson ertr1...@student.uu.se articulated: On Wed, Apr 27, 2011 at 10:12:57AM -0400, Jerry wrote: On Wed, 27 Apr 2011 15:48:36 +0200 Erik Trulsson ertr1...@student.uu.se articulated: On Wed, Apr 27, 2011 at 09:32:58AM -0400, Jerry wrote: On Wed, 27 Apr 2011 08:50:52 -0400 However, I do find troubling you statement regarding a large update to an older port or even a new port submission for that matter. I see no logical reason for a committer to bypass an item simple based on its size or the amount of work involved in getting it committed. After all, consider that the original submitter invested a large amount of his/her time in that same item. Very simple. A particular committer during one particular period of time maybe only 45 minutes of free time to spend on handling PRs. If the committer estimates that one large submitted PR would take at least two hours to review, test, and commit, while another, smaller, PR would only take 30 minutes to handle. Then the committer in question would have two choices: Don't handle either submission, or handling the smaller submission, while skipping the large one and hoping that some other committer with more free time will pick up that one. I see no reason to prefer the first of these choices. If the committer cannot finish the project in their allotted time frame they simply stop and pick up from that point in their next session. Or they can take a look at that project, decide that they are not interested in doing that particular project, and say Screw this, I have better things do with my free time and go off and read a book instead. They might do that anyway. Seriously though, once you start cherry picking through assignments you have started down a slippery slope. I have literally hundreds of projects that I cannot complete in one day; however, I don't simply shrug them off. If I did nothing would ever get accomplished, or at best only the easiest assignments. Hundreds? Sounds a bit excessive if you were to ask me. If you have that many things to do then FIFO is a downright stupid way to approach them unless you know you have enough time to do *all* of them. (And it is rare that there is that much time available.) With that many things to do one needs to prioritize. First one should do the important stuff, and if there is any time left after having done that one might as well pick the fun projects, because there just isn't much point in doing boring, unimportant stuff. Following through on that logic, only the highest priority items would ever get done. Since there is a never ending list of things that have to be done at any given time, the lowest priority ones would never get any attention. Do you work for the government by any chance? One of the basic fallacies in your analysis is that someone else will pick up the slack. Unfortunately, our society has become over run by those who are always ready to blame others or expect others to do our job for us. Quite honestly, I find that pathetic. And yet you are so quick at blaming committers for not doing things the way you think they should be done. Pot. Kettle. Black. It is not the committers per se that I am questioning, but rather the overall protocol used for assigning each project and seeing it through to completion. I have all ready had a few who either are more knowledgeable about the present situation or at least are better equipped to converse about it than yourself, post regarding the present situation. By the way, is your reference to Black a race reference? And what could you possibly have against a defenseless Kettle? Personally, I think you have been spending too much time with the Pot. You are becoming increasingly paranoid. Perhaps you should, as you so eloquently stated, pick the fun projects, because there just isn't much point in doing boring, unimportant stuff. Lets leave those other projects for those who actually take pride in their work and don't just choose the easy way out. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Grief can take care of itself; but to get the full value of a joy you must have somebody to divide it with. Mark Twain ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Thu, 28 Apr 2011 00:54:45 +0200 Olli Hauer oha...@freebsd.org articulated: Maybe you have some time to spend? Before I could reasonable be expected to set aside time, I would need a detailed job description, etcetera. Perhaps you can supply me with one? If my quick lookup was not totally wrong I cannot find one PR opened by you. http://www.freebsd.org/cgi/query-pr-summary.cgi?originator=seibercomclosedtoo=on And you won't either. The ports I maintain, and there are only a few, are under a different alias. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ nohup rm -fr / ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Wed 27 Apr 2011 at 16:15:19 PDT Jerry wrote: Following through on that logic, only the highest priority items would ever get done. Since there is a never ending list of things that have to be done at any given time, the lowest priority ones would never get any attention. Which is as it should be, if it's true that we're faced with insufficient resources. The problem is that we don't have any objective way to determine priorities. Instead we leave this up to the personal interests and whims of the people involved -- maintainers AND committers. ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On Thu, Apr 28, 2011 at 12:39:52AM +0200, John Marino wrote: On 4/28/2011 12:18 AM, Erik Trulsson wrote: And if the committers can't choose what they are going to work on, you are likely going find yourself with a lot fewer committers fairly soon. As you notice, I never said they are limited what they work on. The order of the work is the focus. But if they are forced to do certain tasks first, there might well not be time over to do other things later. I.e. they are limited in what they work on. And who is going to do all that extra work? You volunteering? If finding a volunteer is the only thing holding a reform back, then we have nothing to worry about. Hardly the only thing, merely one of the things. There is also the question of what to do if a committer doesn't like all the proposed extra rules and bureacracy and simply ignores a PR he has been assigned. There isn't really any way force a given committer to work on something he doesn't want to work on. The only sanction available is to remove the commit bit at which point you have one committer less, and that work still isn't done. I was working the assumption that he agrees to the port up front or voluntarily picks up the next task. However, if someone has a repeated history of refusals or only wants to do a very narrow set of tasks, then maybe commit bit removal isn't that dramatic. I didn't say anything about dramatic. My point is that removing that persons commit bit would not serve any useful purpose, and is not enough punishment that the threat of it is likely to convince any committer to do anything he doesn't fell like doing. Worth it for who? Hardly to the guy who is going to do the extra work. As for fair you haven't convinced me why it should be a requirement. I don't consider it extra work. I consider it doing the job correctly. And if I need to convince you that fair is correct, then basically I just wasted 5 minutes answering this post. Jerry pretty much outlined why it's correct to process these things in order, or at some semblance of order. Only under certain assumptions that are far from obviously correct. Look, your mind is made up. You like the status quo. Everything is fine and no effort should be made to improve. I'm not interested in a long, drawn out discussion. I just wanted to give my opinion which I did, so I'm done. Oh, I am not saying that the current situation is ideal. It isn't. Far from it. What I am saying is that your proposed solution is a bad idea that is more likely to cause problems than to solve them. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ 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
