Re: Call for Testers: VirtualBox 4.0.6
On Fri, Apr 22, 2011 at 6:01 AM, Bernhard Froehlich wrote: > It's about two months since the last call for testers and a lot of > bugfixing has happened since then. Not all of the reported problems were > FreeBSD related which is a good indication that we're not too far behind > the stability of the other hosts. So let's get it one once again. > Probably not a FreeBSD specific issue, but my legacy XP VM had an issue. When viewing the Settings screen, a warning came up saying invalid VM name. Checking that field revealed a blank name. Reentering the correct one allowed me to proceed with settings changes, but after closing and reopening the main Vbox GUI, then Settings tab again the VM name was again blank. I then created a new XP VM with an identical name which took. At first this seemed odd, but I see Virtualbox changed it's configuration directory location to perhaps a more Windows friendly. I ended up deleting the old configuration and it seems to be working correctly with the new one. Thanks for the work, -- Adam Vande More ___ 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. -- 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 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, 28 Apr 2011 00:54:45 +0200 Olli Hauer 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=seibercom&closedtoo=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: saving a few ports from death
On 04/27/2011 13:54, Eitan Adler wrote: Which is a*major* drain of resources. One of the reasons for ceasing the building of packages for broken/completely obsolete is to avoid draining the computer time building said packages. ... and in addition to CPU cycles there is also storage on the dozens of mirrors for packages, distfiles, cvs, etc. Almost all of those mirrors are provided by organizations that donate their resources to help the FreeBSD community. Many of them are already stretched thin. I don't think the view that "we don't provide a warranty" is realistic. If you took 100 FreeBSD users and asked them, "Would you be surprised to find a known-bad version of something in the ports tree?" I think 99 of them would say, "yes!" Those who want to keep EOL stuff around also seem to be ignoring that in FreeBSD the model is generally "maintainer knows best." To take apache13 as a specific example, the maintainers of that port have said pretty clearly, "it's a bad idea to keep using this, and we want to get rid of it ASAP." At least one of those maintainers is part of the ASF, so I tend to take his word on such things. Finally, as someone else pointed out, if you decide for yourself that you really really need something that's been removed from the ports tree, you can always dig it out of CVS. Yes, I realize that's extra work on your part, but that's part of the "price" of "free" software. 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 articulated: > On Wed, Apr 27, 2011 at 10:12:57AM -0400, Jerry wrote: > > On Wed, 27 Apr 2011 15:48:36 +0200 > > Erik Trulsson 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 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 2011-04-27 16:12, Jerry wrote: > On Wed, 27 Apr 2011 15:48:36 +0200 > Erik Trulsson 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=seibercom&closedtoo=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: saving a few ports from death
On 2011-04-27 17:59, Mikhail T. wrote: > On -10.01.-28163 14:59, Robert Huff wrote: >> It is also possible it is only important to a fairly small >> number ... but to those it is absolutely crucial. > Or the port might become useful/essential/critical to somebody in the > future... > > What is not broken -- just old, like databases/db2 or www/apache13*, for > example -- should be left alone (until it becomes both broken and > unmaintained). > And even then, the removal should not be mass-scale/automatic... What are you missing in the db2 implementation of FreeBSD which is in the OS and maintained by the OS developers? For myself I see the apache13 EOL with a whining and a laughing eye, and can understand if users don't want to upgrade to 22/24 because of complex and working configurations. But I also look at the future development of the OS and environment where such old dinosaur should see a ice time to make room for new live. Within the apache13/20 deprecation also other ports will go since they are not compatible with newer apache version. For anyone interested I've done a quick grep over my local build logs to get a list of ports which depends on apache13/20 http://people.freebsd.org/~ohauer/diffs/apache_ports/apache13_ports.log http://people.freebsd.org/~ohauer/diffs/apache_ports/apache20_ports.log Most of the ports have equivalents for apache22. http://people.freebsd.org/~ohauer/diffs/apache_ports/apache22_ports.log All those ports where build with the following setting in bsd.apache.mk DEFAULT_APACHE_VERSION= 22 APACHE_SUPPORTED_VERSION= 22 13 20 -- olli ___ 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 Wed, Apr 27, 2011 at 10:12:57AM -0400, Jerry wrote: > On Wed, 27 Apr 2011 15:48:36 +0200 > Erik Trulsson 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. -- 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 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 Trulsson 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. -- 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: saving a few ports from death
On Wed, Apr 27, 2011 at 05:05:57PM -0400, Eitan Adler wrote: > >> apache13 is EOL upstream. We should not have ports for EOL software. > > > > Why not, exactly?.. > > What happens if a security hole or a bug is found? Are we the ones to > fix it? If yes are we to host the patches? Where should the bug > reports go to - our bug tracker? What if our implementation ceases to > match established documentation? Should we host the docs too? "We"? Who is this "we" you keep talking about here? If a port has a security hole then it is up to the maintainer to find a fix for it - if this fix is a patch he/she comes up with or a switch to a newer upstream version is irrelevant. If there is no maintainer and nobody else provides a fix either, it is time to mark the port as FORBIDDEN and DEPRECATED and remove it after the deprecation period expires, just like how other broken ports are handled. > > The ports collection is one of *third party* software (with a couple > of small exceptions). If the third party says "this program is done, > has bugs which won't be fixed, etc" we should no longer support it. Depends on what you mean by "support", but removing a port just because upstream development has ceased is just plain silly. -- 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: saving a few ports from death
Eitan, you are entitled to your opinions, but not to your own facts. My factual corrections are inline below. Arguing about opinions and policy is useless until the facts are accepted as such by all participants: On 27.04.2011 16:54, Eitan Adler wrote: The upstream maintainer already called it "end of life". FreeBSD does not and will not ever take over the development of dead upstream ports (and in this case there is a upstream version) I never suggested, we undertake /development/ of upstream software -- EOLed or not. Fact 1. The same entity(ies), that currently busy themselves marking things>"deprecated". The ports marked "broken with no one to fix them" (shortened to 'deprecated') take a significant amount of time and energy to fix. db2 was not broken. Neither is apache13... Fact 2. Which is a *major* drain of resources. "Major"? Didn't you say earlier, that the most recent sweep -- only deleted about 3% of the ports? I'd say, this is Fact 3, but, maybe, even 3% qualifies as "major" in your view... And was not this sweep the largest in our history? What you fail to understand is that we are NOT marking ports as 'obsolete' or 'bad' or 'there exists a better program' but as broken and unmaintained. I can only repeat the example of db2. It was never broken, but deleted nonetheless... The same is about to happen to apache13... -mi ___ 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: saving a few ports from death
Quoth Ade Lovett on Wednesday, 27 April 2011:
> On Apr 27, 2011, at 13:46 , Chip Camden wrote:
> >
> > Modifying the script that was posted earlier, we can list out all
> > installed ports that are currently deprecated, and why:
>
> Won't work -- need to handle slave ports etc, where the DEPRECATED may be in
> the MASTER_PORT.
>
> Try this:
>
> #!/bin/sh
> #
> PORTSDIR=${1-"/usr/ports"}
> for port in $(pkg_info -oa | grep /)
> do
> dep=$(make -C ${PORTSDIR}/${port} -V DEPRECATED)
> [ -n "${dep}" ] && echo "${port}: ${dep}"
> done
>
>
> -aDe
>
> ___
> 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"
Nice, thanks!
--
.O. | Sterling (Chip) Camden | http://camdensoftware.com
..O | sterl...@camdensoftware.com | http://chipsquips.com
OOO | 2048R/D6DBAF91 | http://chipstips.com
pgp5qYJQh9YGn.pgp
Description: PGP signature
Re: saving a few ports from death
On Wed 27 Apr 2011 at 14:05:57 PDT Eitan Adler wrote: apache13 is EOL upstream. We should not have ports for EOL software. Why not, exactly?.. What happens if a security hole or a bug is found? Are we the ones to fix it? No. The rule of caveat emptor should apply. We don't warranty anything else in the portstree, why would you think that there's an implied warranty in this scenario? If yes are we to host the patches? The question is moot, given a negative answer to the preceding one. Where should the bug reports go to - our bug tracker? If they do get submitted there, they should be immediately closed as "Won't Fix". What if our implementation ceases to match established documentation? Should we host the docs too? Same answers as above. The ports collection is one of *third party* software (with a couple of small exceptions). If the third party says "this program is done, has bugs which won't be fixed, etc" we should no longer support it. Keeping it in the tree != obligation to provide support, i.e., bugfixes for anything except the port Makefile and other port-related files. As long as there's a maintainer willing to do the work to keep it running (warts and all) on the currently-supported FreeBSD releases, I don't see any reason why it can't be kept in the tree. If upstream says it's dead, who are we to keep it alive? We are a major Operating System project, which maintains ports of third-party applications for the convenience of our users. An EOL-declaration by the authors does not mean, the users must stop using it immediately -- it simply says, the authors will not be releasing updates/bug-fixes. Correct. However (a) if the third party gave an upgrade path we should encourage our users to use it and (b) if there *are* known bugs and especially security holes we should cease to make it available through our tree. Agree with (a) but maybe not (b). That's a decision that should be left to the users. If a user says "I found an issue with X and it is EOL upstream" the correct response is to "upgrade to a supported version". See above. However this discussion is different to the one that we started with (namely that of deprecated ports) so lets try and get back on track :-) Actually, it's a closely related question. ___ 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: saving a few ports from death
>> apache13 is EOL upstream. We should not have ports for EOL software. > > Why not, exactly?.. What happens if a security hole or a bug is found? Are we the ones to fix it? If yes are we to host the patches? Where should the bug reports go to - our bug tracker? What if our implementation ceases to match established documentation? Should we host the docs too? The ports collection is one of *third party* software (with a couple of small exceptions). If the third party says "this program is done, has bugs which won't be fixed, etc" we should no longer support it. >> >> If upstream says it's dead, who are we to keep it alive? > > We are a major Operating System project, which maintains ports of > third-party applications for the convenience of our users. An > EOL-declaration by the authors does not mean, the users must stop using it > immediately -- it simply says, the authors will not be releasing > updates/bug-fixes. Correct. However (a) if the third party gave an upgrade path we should encourage our users to use it and (b) if there *are* known bugs and especially security holes we should cease to make it available through our tree. If a user says "I found an issue with X and it is EOL upstream" the correct response is to "upgrade to a supported version". However this discussion is different to the one that we started with (namely that of deprecated ports) so lets try and get back on track :-) -- Eitan Adler ___ 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: saving a few ports from death
On 27.04.2011 16:47, Wesley Shields wrote: apache13 is EOL upstream. We should not have ports for EOL software. Why not, exactly?.. If upstream says it's dead, who are we to keep it alive? We are a major Operating System project, which maintains ports of third-party applications for the convenience of our users. An EOL-declaration by the authors does not mean, the users must stop using it immediately -- it simply says, the authors will not be releasing updates/bug-fixes. -mi ___ 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: saving a few ports from death
>dougb is anxious to delete apache13 as well instead of simply disowning it... The upstream maintainer already called it "end of life". FreeBSD does not and will not ever take over the development of dead upstream ports (and in this case there is a upstream version) >The same entity(ies), that currently busy themselves marking things >>"deprecated". The ports marked "broken with no one to fix them" (shortened to 'deprecated') take a significant amount of time and energy to fix. Think of the warning as a "call to fix" for those parts. If you feel > No, not easily. It requires the CVS tree, which is not automatically > installed. /usr/ports/obsoleted, on the other hand, would be rolled out > together with the rest of the ports-tree. And for those who want to use old, and likely broken ports, they can take that effort to install the tree. > And, under my proposal, the > packages for the "obsolete" stuff will continue building. Which is a *major* drain of resources. One of the reasons for ceasing the building of packages for broken/completely obsolete is to avoid draining the computer time building said packages. Take a guess how long it takes to build from start to completion a complete set of packages. I'll bet you get it wrong. Furthermore in order to continue building packages the ports have to *work* which most of them presently do not. What you fail to understand is that we are NOT marking ports as 'obsolete' or 'bad' or 'there exists a better program' but as broken and unmaintained. What we ARE saying is that "this port does not presently work and no one took up the mantle to (a) fix it (b) maintain it (c) continue to the maintain it in the future. There are hundreds if not thousands of obsolete ports in the tree. This is because someone decided to MAINTAIN the ports. We can not support BROKEN ports unless someone does the work. [snip] > Same goes for apache13 -- last change was an upgrade to 1.3.42 (February > 2010) -- it does not seem to require much work. Apache 1.3 is DEAD and been supplanted upstream. If you wish to fork apache 1.3 and make a new project we will GLADY host a port for it (if someone decided to maintain it) I strongly doubt that you have any idea of the amount of work it takes to support 23,000 ports. Furthermore it seems that your proposals fail to consider the amount of infrastructure work that must be delayed or even prevented due to sheer number of broken and unmaintained ports. -- Eitan Adler ___ 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: saving a few ports from death
On Wed, Apr 27, 2011 at 04:03:58PM -0400, Mikhail T. wrote: > On 27.04.2011 14:16, Eitan Adler wrote: > > Then bapt@ marked the ports*deprecated* which does not mean deleted. It > > was a warning that people who were interested should step up and take up > > the work. If after N amount of time no one does so they will be > > individually deleted. > The ports I listed -- db2 and apache13* family -- are/were not broken. What > "work" are you talking about? > > Yet, mandree deleted db2 on April 12th and dougb is anxious to delete > apache13 as well instead of simply disowning it... apache13 is EOL upstream. We should not have ports for EOL software. I don't care if it works perfectly fine and someone wants to hand-roll patches back to it. If upstream says it's dead, who are we to keep it alive? -- WXS ___ 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: Call for Testers: VirtualBox 4.0.6 (PBIs now available)
On Wed, 27 Apr 2011 15:28:11 -0400, Ryan Stone wrote:
> (Sorry for the noise earlier about the PBIs not working under PC-BSD;
> I'm not sure how I missed that had been already reported).
>
> I tried the new amd64 PBI and I am able to successfully start VMs now.
> I had one VM(running some relatively recent version of amd64 HEAD)
> boot up fine, but a second one (also running amd64 HEAD, but maybe a
> different svn revision) gets a Guru Meditation during startup. I'm
> not sure what is causing the crash. In their original configurations
> the working VM booted off of an emulated IDE disk while the broken VM
> booted of an emulated SATA disk, however I just tried changing the
> SATA disk to instead be an IDE disk and it doesn't seems to have
> resolved the problem.
>
> I'm not getting a corefile for the crash(or I'm unable to find it). I
> do have kern.sugid_coredump=1 and I'm running the PBI. Is this
> expected for a Guru Meditation, or should it be putting a core
> somewhere? I've put the VBox.log for the most recent crash here:
No, that looks fine.
> http://people.freebsd.org/~rstone/vbox-4.0.6/VBox.log
>
> This seems to be easy to reproduce so let me know if there's any more
> information that I can gather.
I've added it to the Todo list for 4.0.6 and will report it to the vbox
developers tomorrow. Sorry, don't have a clue what is going wrong there
- but i'm sure they know.
http://wiki.freebsd.org/VirtualBox/ToDo
> Also, the working VM was emulating uniprocessor machine. I tried
> adding a second CPU and that VM started crashing, too. I tried
> changing the broken VM to have only one core but it still crashes.
> I'm not sure if it's related to the first crash or not.
Look at the relevant parts of VBox.log and see if they look about the
same.
00:00:08.374 VERR_VMX_INVALID_VMCS_PTR: CPU0 Current pointer
vs 84362000
00:00:08.374 VERR_VMX_INVALID_VMCS_PTR: CPU0 Current VMCS version e
00:00:08.374 VERR_VMX_INVALID_VMCS_PTR: CPU0 Entered Cpu 3
00:00:08.374 VERR_VMX_INVALID_VMCS_PTR: CPU0 Current Cpu 2
00:00:08.374 VERR_VMX_INVALID_VMCS_PTR: CPU1 Current pointer
vs 84365000
00:00:08.374 VERR_VMX_INVALID_VMCS_PTR: CPU1 Current VMCS version 0
00:00:08.374 VERR_VMX_INVALID_VMCS_PTR: CPU1 Entered Cpu 0
00:00:08.374 VERR_VMX_INVALID_VMCS_PTR: CPU1 Current Cpu 0
00:00:08.374
!!
00:00:08.374 !!
00:00:08.374 !! Guru Meditation -4001
(VERR_VMX_INVALID_VMCS_PTR)
00:00:08.374 !!
00:00:08.374 !!
00:00:08.374 !! {mappings, }
00:00:08.374 !!
--
Bernhard Froehlich
http://www.bluelife.at/
___
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: saving a few ports from death
On 27.04.2011 14:16, Eitan Adler wrote: Then bapt@ marked the ports*deprecated* which does not mean deleted. It was a warning that people who were interested should step up and take up the work. If after N amount of time no one does so they will be individually deleted. The ports I listed -- db2 and apache13* family -- are/were not broken. What "work" are you talking about? Yet, mandree deleted db2 on April 12th and dougb is anxious to delete apache13 as well instead of simply disowning it... > Maybe, for cleanliness and neatness, we should have a separate directory > (and category): "obsolete" -- where ports can go to die peacefully. But it > should not be cvs' "Attic"... Who will be the ones to deal with that category, ensuring new infrastructure works, etc? The port maintainer? oh wait! The same entity(ies), that currently busy themselves marking things "deprecated". But it was just a proposal -- for those, who don't like to see "obsolete" software mixed with the latest and greatest. I'm perfectly satisfied with not touching "obsolete" things at all. Certainly not until they break -- and stay broken for "too long". cvs's Attic can be easily restored if people take up the slack. I see no reason to change this policy No, not easily. It requires the CVS tree, which is not automatically installed. /usr/ports/obsoleted, on the other hand, would be rolled out together with the rest of the ports-tree. And, under my proposal, the packages for the "obsolete" stuff will continue building. The "if people take up the slack" seems to imply need to continuously work on the software. But the db2 needed no serious changes since 2004 and the last meaningful change was in 2008... The only reason to kill it was "too old"... Now all current users of db2 have to move onto later dbX, which means not only patching up the API-calls in their source-code (if the source code is even available!), but recreating their databases too -- because Berkeley DB files are not backwards-compatible. And for what reason?.. Same goes for apache13 -- last change was an upgrade to 1.3.42 (February 2010) -- it does not seem to require much work. There may well be good reasons to hate it, but somebody with a custom module, for example, may be perfectly satisfied with it... I happen to know one such site, for example. There may be more. If apache@ does not want it, they can drop maintainership. But deletion is not called for. Upgrading the OS should not /require/ upgrading (and replacing!) the applications. Yours, -mi ___ 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: Call for Testers: VirtualBox 4.0.6 (PBIs now available)
(Sorry for the noise earlier about the PBIs not working under PC-BSD; I'm not sure how I missed that had been already reported). I tried the new amd64 PBI and I am able to successfully start VMs now. I had one VM(running some relatively recent version of amd64 HEAD) boot up fine, but a second one (also running amd64 HEAD, but maybe a different svn revision) gets a Guru Meditation during startup. I'm not sure what is causing the crash. In their original configurations the working VM booted off of an emulated IDE disk while the broken VM booted of an emulated SATA disk, however I just tried changing the SATA disk to instead be an IDE disk and it doesn't seems to have resolved the problem. I'm not getting a corefile for the crash(or I'm unable to find it). I do have kern.sugid_coredump=1 and I'm running the PBI. Is this expected for a Guru Meditation, or should it be putting a core somewhere? I've put the VBox.log for the most recent crash here: http://people.freebsd.org/~rstone/vbox-4.0.6/VBox.log This seems to be easy to reproduce so let me know if there's any more information that I can gather. Also, the working VM was emulating uniprocessor machine. I tried adding a second CPU and that VM started crashing, too. I tried changing the broken VM to have only one core but it still crashes. I'm not sure if it's related to the first crash or not. ___ 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: saving a few ports from death
On Apr 27, 2011, at 13:46 , Chip Camden wrote:
>
> Modifying the script that was posted earlier, we can list out all
> installed ports that are currently deprecated, and why:
Won't work -- need to handle slave ports etc, where the DEPRECATED may be in
the MASTER_PORT.
Try this:
#!/bin/sh
#
PORTSDIR=${1-"/usr/ports"}
for port in $(pkg_info -oa | grep /)
do
dep=$(make -C ${PORTSDIR}/${port} -V DEPRECATED)
[ -n "${dep}" ] && echo "${port}: ${dep}"
done
-aDe
___
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 wrote: > On Wed, 27 Apr 2011 13:00:17 +0100 > Chris Rees 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 4/27/2011 4:12 PM, Jerry wrote: On Wed, 27 Apr 2011 15:48:36 +0200 Erik Trulsson 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: Re: saving a few ports from death
Quoth Eitan Adler on Wednesday, 27 April 2011:
> > What is not broken -- just old, like databases/db2 or www/apache13*, for
> > example -- should be left alone (until it becomes both broken and
> > unmaintained). And even then, the removal should not be
> > mass-scale/automatic...
>
> This recent sweep was neither mass scale nor automatic.
> 536/22816 ports is only 3.234% of all the ports. Furthermore bapt@,
> myself, and a few other people went through each of the categories
> ensuring the projects were actually dead (not necessarily that the
> distfile couldn't be found). Then bapt@ marked the ports *deprecated*
> which does not mean deleted. It was a warning that people who were
> interested should step up and take up the work. If after N amount of
> time no one does so they will be individually deleted.
>
> > Maybe, for cleanliness and neatness, we should have a separate directory
> > (and category): "obsolete" -- where ports can go to die peacefully. But it
> > should not be cvs' "Attic"...
>
> Who will be the ones to deal with that category, ensuring new
> infrastructure works, etc? The port maintainer? oh wait!
> cvs's Attic can be easily restored if people take up the slack. I see
> no reason to change this policy.
>
> --
> Eitan Adler
Modifying the script that was posted earlier, we can list out all
installed ports that are currently deprecated, and why:
#!/bin/sh
prefix=/usr/ports/
makefile=/Makefile
for file in `pkg_info -oxa | grep "/"`
do
yes=`grep DEPRECATED= ${prefix}${file}${makefile}`
if [ -n "$yes" ]
then
echo $file $yes
fi
done
When I ran this on my system, I found only lang/libutils. It must have been
needed by something I've since uninstalled, because nothing depends on it
now -- so I deleted it.
--
.O. | Sterling (Chip) Camden | http://camdensoftware.com
..O | sterl...@camdensoftware.com | http://chipsquips.com
OOO | 2048R/D6DBAF91 | http://chipstips.com
pgpxU3jAVMkAt.pgp
Description: PGP signature
Re: saving a few ports from death
On 04/27/2011 08:59, Mikhail T. wrote: What is not broken -- just old, like ... or www/apache13* apache13 is way past EOL, and the apache team is working hard to move the default to apache22, at which point I personally hope that apache13 dies a quick and painful death :) -- 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: Re: saving a few ports from death
> What is not broken -- just old, like databases/db2 or www/apache13*, for > example -- should be left alone (until it becomes both broken and > unmaintained). And even then, the removal should not be > mass-scale/automatic... This recent sweep was neither mass scale nor automatic. 536/22816 ports is only 3.234% of all the ports. Furthermore bapt@, myself, and a few other people went through each of the categories ensuring the projects were actually dead (not necessarily that the distfile couldn't be found). Then bapt@ marked the ports *deprecated* which does not mean deleted. It was a warning that people who were interested should step up and take up the work. If after N amount of time no one does so they will be individually deleted. > Maybe, for cleanliness and neatness, we should have a separate directory > (and category): "obsolete" -- where ports can go to die peacefully. But it > should not be cvs' "Attic"... Who will be the ones to deal with that category, ensuring new infrastructure works, etc? The port maintainer? oh wait! cvs's Attic can be easily restored if people take up the slack. I see no reason to change this policy. -- Eitan Adler ___ 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: Re: saving a few ports from death
On -10.01.-28163 14:59, Robert Huff wrote: It is also possible it is only important to a fairly small number ... but to those it is absolutely crucial. Or the port might become useful/essential/critical to somebody in the future... What is not broken -- just old, like databases/db2 or www/apache13*, for example -- should be left alone (until it becomes both broken and unmaintained). And even then, the removal should not be mass-scale/automatic... Maybe, for cleanliness and neatness, we should have a separate directory (and category): "obsolete" -- where ports can go to die peacefully. But it should not be cvs' "Attic"... -mi ___ 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: FreeBSD Port: squeezeboxserver-7.5.3, build okay but fails to start.
On Wed, Apr 27, 2011 at 07:15:07AM -0700, spotter wrote: > I am having the exact same problem with a brand new FreeBSD 8.1-RELEASE > install and a fresh squeezeboxserver (v7.5.3) port build. > (Slimserver was working fine under FreeBSD 6.2, until I tried to get > miniDLNA working, as well, for a BluRay player access to same music library. > sigh) > Any solutions worked out for squeezeboxserver v7.5.3 under FreeBSD > 8.1-RELEASE? Assuming you aren't using mysql for anything else, you might try manually installing an older version and then reinstalling the port. My squeezeboxserver is running with 5.0. If that works we should be able to restrict the allowed versions of mysql to ones that work. -- Brooks > > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/FreeBSD-Port-squeezeboxserver-7-5-3-build-okay-but-fails-to-start-tp3861984p4343776.html > Sent from the freebsd-ports mailing list archive at Nabble.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" > pgpntJVefKeex.pgp Description: PGP signature
Re: Dropping maintainership of my ports
On 27 April 2011 13:54, Kurt Jaeger wrote: > Eitan Adler wrote: >> Things like the gmake upgrade and new ports >> features take a lot of time. Furthermore adding a port seems to be a >> "trivial" task, however the committers have to (a) fix it up if it is >> formatted badly (b) test it in a tinderbox and only then (c) commit >> it. > > I use three boxes (for 8.1 i386, amd64 and 9-current amd64) to > test. I do not use a tinderbox, as I assume considerable complexity > to set one up. Nah, have a look at [1]. Easy as pie. > Does using a tinderbox make a large difference ? Yes! It finds hiccups in pkg-plist (very difficult to notice manually), it tests in different versions -- just add them to the queue. If you'd really like to try it out, I'll give you an account on my machine. Let me know. Chris [1] http://tinderbox.marcuscom.com/README/ ___ 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: Dropping maintainership of my ports
Eitan Adler wrote: > There is a lot of work that has to be done in the background even if > no new ports are added. Things like the gmake upgrade and new ports > features take a lot of time. Furthermore adding a port seems to be a > "trivial" task, however the committers have to (a) fix it up if it is > formatted badly (b) test it in a tinderbox and only then (c) commit > it. This takes more time than just "cvs commit". A lot of work has > been done in recent years to make this process faster and I'm sure > more could be done - but a lot of people don't realize how much work > goes on behind the scenes I think it is important to clean up ports because otherwise there is a big burden on the FreeBSD organization, and also on each individual user, when they upgrade their machine. I think on the other hand that some ports are especially important, and don't always receive the care they need, for reasons that i don't know. I have taken some time to look at some ports in the "lang" category that are unmaintained or are severely old. I have noted that eiffel 13a is deprecated and has an expiration date. Indeed i have found old copies of this software, and it seems that the people doing it have disappeared someway. However at least one is now listed as contributor to gobo-eiffel http://sourceforge.net/projects/gobo-eiffel/ which is not a freebsd port. There is the "official" eiffelstudio port, which has a valid download link but no maintainer, and smarteiffel which is maintained. I am more interested by the cmucl lisp compiler. In the ports we can find cmucl 19f which is maintained by Martin Cracauer, but is already quite old, and there is no maintainer for cmucl-extras. In fact the cmucl project does the work of providing precompiled stuff for various architectures (the lisp compiler is written in lisp so can only be compiled by a recent enough precompiled compiler, anyways) and in particular one finds freebsd binaries here: http://common-lisp.net/project/cmucl/downloads/snapshots/2011/04/ These binaries are compiled on freebsd_8.1, and there are two versions the unicode version and the non-unicode version, plus the cmucl-extra (localized messages, an adapted editor, called hemlock plus some goodies). So my point is, how is it that cmucl freebsd version finds care and love in the cmucl community, but that this does not extend to an adequate place in the freebsd ports? The other big lisp from the same ancestry, sbcl is better maintained, since the last version is 1.0.47, while freebsd is at 1.0.43, that is 6 months old. These lisps are *very* important for their use in the CAS software maxima, which is actively developed and used by a lot of people (in ancient times the traditional compiler for maxima was gcl but it seems it doesn't work well nowadays, and clisp is far too slow). But they are also important for many other uses, and at this point i see an important omission in the ports system. The "standard" way nowadys to install lisp packages is to use quicklisp http://www.quicklisp.org/beta/ and after that hundreds of applications can be installed automatically in the same way as cpan does for perl modules. Instead there are a select few lisp applications in the ports, which have a clisp and a sbcl slave port. This is strange. -- Michel TALON ___ 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: saving a few ports from death
On Wed, Apr 27, 2011 at 08:02:34AM -0700, Chip Camden wrote: > Quoth Eric on Wednesday, 27 April 2011: ... > > >> My search for "popularity" metrics is intended to point me, as a > > >> maintainer, to ports I might want to adopt now, rather than wait for > > >> someone to complain about them. Everything *I* use is already > > >> maintained, so I've moved on to looking for things other people might > > >> need. But I don't want to waste my time on something that nobody uses. > > >> :) I have suggested in the past that part of the ports infrastructure could toggle a count somewhere each time a port is made. This should be opt in of course. It would make it very easy to see which port might need a maintainer. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ 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: saving a few ports from death
On Wed, Apr 27, 2011 at 1:00 AM, Mark Linimon wrote: > I need to migrate portsmon to another server so that we can start up > these periodic emails again. > > mcl > ___ > With the large number of ports to be maintained , tasks to be performed becomes very complex . The current structure of problem report submitting and e-mails about current problems may be modified to reduce the tasks to be performed even for slightly. On the problem report submitting page , http://www.freebsd.org/send-pr.html the following fields may be added to make it more structured and to be able to generate e-mails to maintainers directly : Remove field Category . Add the following fields : FreeBSD Version : ( Selected from a drop-down list like Category ) FreeBSD Architecture : ( Selected from list ... ) Related to ( Radio Button ) Base : Program Name : ... in Directory : ... - Port : Port Name in .../Latest/ Directory : ... Port Version : If there is a working version in another operating system Name : ... operating system Version : ... Port Name : ... Port Version : ... Source Repository URL : - Into Class field : Add item : Feature Suggestion . Under the box "How to repeat the problem" , addWhich tests are applied : addTesting software available : addTesting Software URL : With the above structure , it is possible . to generate e-mails to maintainers automatically , . to eliminate problem reports when operating system or port version numbers of the respective ports changes by moving them to an archive . Problem report query page http://www.freebsd.org/cgi/query-pr-summary.cgi?query may be adapted accordingly . ... In e-mails , a more structured listing will be helpful : PR FreeBSD FreeBSDPort Port NumberVersion ArchitectureName Version Description ---- --- -- - In the present system , mentioning only the category with vague descriptions causes difficulty to understand structure of the problem , at least for persons foreigner to port maintenance . Also , supplying a link to problem report numbers during generation of e-mails automatically makes them easily accessible . Thank you very much . Mehmet Erol Sanliturk ___ 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: saving a few ports from death
Quoth Eric on Wednesday, 27 April 2011:
> > From: Anton Shterenlikht
> > Date: Wed, 27 Apr 2011 10:14:41 +0100
> > To:
> > Subject: Re: saving a few ports from death
> >
> > On Tue, Apr 26, 2011 at 03:55:56PM -0700, Charlie Kester wrote:
> >>
> >> My search for "popularity" metrics is intended to point me, as a
> >> maintainer, to ports I might want to adopt now, rather than wait for
> >> someone to complain about them. Everything *I* use is already
> >> maintained, so I've moved on to looking for things other people might
> >> need. But I don't want to waste my time on something that nobody uses.
> >> :)
> >
> > Interesting..
> >
> > I used this sh(1) script to find
> > unmaintained ports that I use.
> > (I couldn't find a way to do the
> > job with the existing tools like
> > pkg_info or portmaster):
> >
> > #!/bin/sh
> >
> > prefix=/usr/ports/
> > makefile=/Makefile
> >
> > for file in `pkg_info -oxa | grep "/"`
> > do
> > yes=`grep MAIN ${prefix}${file}${makefile} | grep ports`
> > if [ -n "$yes" ]
> > then
> > echo $file
> > fi
> > done
> >
>
> [SNIP]
>
> Small observation, since that script picks up all of us who use 'ports' in
> our maintainer email addresses (myself for example), might I suggest the
> following tweak to your script (full address and checking for file
> existence):
>
> #!/bin/sh
>
> prefix=/usr/ports/
> makefile=/Makefile
>
> for file in `pkg_info -oxa | grep "/"`
> do
> if test -f ${prefix}${file}${makefile}
> then
> yes=`grep MAIN ${prefix}${file}${makefile} | grep -i 'ports@freebsd\.org'`
> if [ -n "$yes" ]
> then
>echo $file
> fi
> fi
> Done
>
Good catch -- even with that change, my list has 57 ports in it
(including, ironically, sysutils/bsdstats). A lot of the ones on my list
are requirements for other ports, though.
--
.O. | Sterling (Chip) Camden | http://camdensoftware.com
..O | sterl...@camdensoftware.com | http://chipsquips.com
OOO | 2048R/D6DBAF91 | http://chipstips.com
pgpg87PzKQ9DK.pgp
Description: PGP signature
Re: Dropping maintainership of my ports
On Wed, Apr 27, 2011 at 07:35:58AM -0400, Jerry wrote: > On Wed, 27 Apr 2011 09:49:58 +0200 > Erik Trulsson articulated: > > > On Wed, Apr 27, 2011 at 12:15:43AM -0700, Charlie Kester wrote: > > > On Tue 26 Apr 2011 at 23:27:40 PDT John Marino wrote: > > > > ... > > > > > > Every response from the committers ignored what I said I was trying > > > to do, and instead repeated the same old arguments about stale, > > > unfetchable, broken or superceded ports. That "talking points" No, no and no. If you have a copy of the upstream package the port was based upon and it is open source, you can 'fork' it. Create a project on sourceforge, or Berlioz, or somewhere, put the package there, announce it get some people together to maintain it. That has the advantage of having FreeBSD minded people maintaing it upstream. That's all. Easy Peasy. That's for unfetchable ports or even superceded ports. If you prefer an older program than a supposed newer suggested replacement, you can fork the older program. That's how it works. > > (Actually the policy is that unmaintained and non-working ports should > > be let to die, unless somebody steps up to fix the port and take > > maintainership.) Exactly. > > > > Nobody is stopping you from assuming maintainership of one or more of > > those unmaintained ports, and thus preventing them from being removed. > > I concur with Erik. I think you are totally missing the point of the > original post. The desired wish was to remove dead ports that could not > be fetched, or would not build. Possibly, even superseded ports; Right. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ 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: FreeBSD Port: squeezeboxserver-7.5.3, build okay but fails to start.
I am having the exact same problem with a brand new FreeBSD 8.1-RELEASE install and a fresh squeezeboxserver (v7.5.3) port build. (Slimserver was working fine under FreeBSD 6.2, until I tried to get miniDLNA working, as well, for a BluRay player access to same music library. sigh) Any solutions worked out for squeezeboxserver v7.5.3 under FreeBSD 8.1-RELEASE? -- View this message in context: http://freebsd.1045724.n5.nabble.com/FreeBSD-Port-squeezeboxserver-7-5-3-build-okay-but-fails-to-start-tp3861984p4343776.html Sent from the freebsd-ports mailing list archive at Nabble.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 Wed, 27 Apr 2011 15:48:36 +0200 Erik Trulsson 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 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. -- 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 09:17:46 -0400 Steven Kreuzer 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, 27 Apr 2011 08:50:52 -0400 Robert Huff 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?
> 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: Dropping maintainership of my ports
> So, if the maintainers of the small leaf ports would be able > to commit their work themselves, it would free the ports committers > with the large ports projects on their hands to work on those ? > > Would this work ? If you look through this list's archives I actually proposed this idea myself once ;-) The problem is that (a) often maintainers don't do the work 100% well. I am not knocking everyone - but just because you _say_ you will do the work doesn't mean you _will_ do it. Furthermore becoming a committer implies a certain level of trust beyond just "you can submit patches" as you get shell access to the FreeBSD machines and other such things. > > I use three boxes (for 8.1 i386, amd64 and 9-current amd64) to > test. I do not use a tinderbox, as I assume considerable complexity > to set one up. You may want to mention that you use said three machines in the PR - it would be of service. Different committers have differing policies for what they will commit. Some will accept that, others will want tinderbox logs, and others will always test every patch themselves. > > Does using a tinderbox make a large difference ? Using a tinderbox ensures that a "clean" build works (ie that there are no missing dependencies). > I agree, the infrastructure is massive! 23,000 ports held together with Makefiles - I'm still surprised it works ;) -- Eitan Adler ___ 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 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: Dropping maintainership of my ports
Eitan Adler wrote: > On Wed, Apr 27, 2011 at 4:23 AM, Kurt Jaeger wrote: > > Then you have misunderstood things. I don't think anybody would be > > unhappy if you (or anybody else) took maintainership of one or more of > > the currently unmaintained ports. > > > There are two things. Becoming a maintainer seems to be really easy. > > Becoming a maintainer requires that you commit to do the work to > ensure that a certain program works on FreeBSD. How easy this is > depends on you. Yes, that's how I handle it. > > Having one's PRs committed is a bit more difficult and sometimes > > takes 4-6 weeks (I had a case recently with 155399 and 155400). > > There is a lot of work that has to be done in the background even if > no new ports are added. I'm aware of this. What I see is that only a few ports committer do most of the commits of the small leaf ports. This would burn me out as well, if I had to do it 8-} So, if the maintainers of the small leaf ports would be able to commit their work themselves, it would free the ports committers with the large ports projects on their hands to work on those ? Would this work ? > Things like the gmake upgrade and new ports > features take a lot of time. Furthermore adding a port seems to be a > "trivial" task, however the committers have to (a) fix it up if it is > formatted badly (b) test it in a tinderbox and only then (c) commit > it. I use three boxes (for 8.1 i386, amd64 and 9-current amd64) to test. I do not use a tinderbox, as I assume considerable complexity to set one up. Does using a tinderbox make a large difference ? > This takes more time than just "cvs commit". A lot of work has > been done in recent years to make this process faster and I'm sure > more could be done - but a lot of people don't realize how much work > goes on behind the scenes I agree, the infrastructure is massive! -- p...@opsec.eu+49 171 3101372 9 years to go ! ___ 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: Dropping maintainership of my ports
If after this thread you still want to drop maintership I'd like the following: >>> deskutils/teapot >>> math/ised >>> security/ccrypt >>> sysutils/moreutils >>> sysutils/moreutils-parallel >> I've been told that we shouldn't be looking for reasons to save any > unmaintained port, What you have been told is "no-one steps up to (a) fix the problem, (b) take maintainership and (c) _continue_ with maintainership. Well, in that case, the port does not _deserve_ to live. After all, no-one cares about it. If they did, they'd take care of (a) thru (c) above." If you are stepping up to do the work that is great and we thank you for that! We we don't want is people who only volunteer for part (a) and don't continue with (b) and (c). This is because the work for fixing these ports falls on the rest of the community, and mainly the committers if it were to break again or when making "sweeping" changes to the tree. A large amount of the work that goes into things like a gmake or autotools upgrade is fixing individual ports that broke. If people step up to continue to maintain the now deprecated ports I see nothing wrong with helping them to do so. If that someone is you - even better! > and I was specifically told this in response to my > efforts to identify ports that have a lot of users. Merely finding "popular" ports does not help. We need people who have the time and energy to maintain the ports. I do not want to say that "we are a volunteer project" and as such are forgiven however such a model does change how we must do things. We can not "assign" ports to people, even committers, unless they agree to do the work. Furthermore we can use maintainership to judge popularity if indirectly and imperfectly. If no one steps up to do the work of all the port's users it is not that popular. If you are the one stepping up to do the work I would urge you continue! However merely pointing at the port and saying "this needs to be fixed" won't help as someone still has to fix it. > So I don't think current policy supports the conclusion that "we need to find > someone to take them soon." The policy is one of passiveness and this seems to be the main difference between the others and the you. Correct me if I am wrong but you believe that we should be trying as hard as we can to find somehow or someone to save these ports. Others believe that if someone wants to they can step up and do the work to save these ports. On Wed, Apr 27, 2011 at 4:23 AM, Kurt Jaeger wrote: > Then you have misunderstood things. I don't think anybody would be > unhappy if you (or anybody else) took maintainership of one or more of > the currently unmaintained ports. > There are two things. Becoming a maintainer seems to be really easy. Becoming a maintainer requires that you commit to do the work to ensure that a certain program works on FreeBSD. How easy this is depends on you. > Having one's PRs committed is a bit more difficult and sometimes > takes 4-6 weeks (I had a case recently with 155399 and 155400). There is a lot of work that has to be done in the background even if no new ports are added. Things like the gmake upgrade and new ports features take a lot of time. Furthermore adding a port seems to be a "trivial" task, however the committers have to (a) fix it up if it is formatted badly (b) test it in a tinderbox and only then (c) commit it. This takes more time than just "cvs commit". A lot of work has been done in recent years to make this process faster and I'm sure more could be done - but a lot of people don't realize how much work goes on behind the scenes -- Eitan Adler ___ 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" 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 > > 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?
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 > 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: Dropping maintainership of my ports
On Wed, 27 Apr 2011 09:49:58 +0200 Erik Trulsson articulated: > On Wed, Apr 27, 2011 at 12:15:43AM -0700, Charlie Kester wrote: > > On Tue 26 Apr 2011 at 23:27:40 PDT John Marino wrote: > > > > > >You're just sulking because your idea of identifying popular ports > > >wasn't met with enthusiasm. > > > > > > > No, it's more than that. I got the distinct impression that many > > of the committers would be unhappy if I took maintainership of some > > of the ports I might identify as "popular", because it would > > interfere with their plans to trim the portstree. > > > Then you have misunderstood things. I don't think anybody would be > unhappy if you (or anybody else) took maintainership of one or more of > the currently unmaintained ports. > What plans there are, are not so much about trimming the portstree in > general but trimming the number of unmaintained ports. > > What is met with uninterest is your plans to identify "popular" ports. > > > > Re-read the thread. At every point I'm talking about looking for > > ports I (and others) might want to maintain, as a service to their > > users. Now ask yourself why I've been getting so much resistance > > to that, when we keep hearing how deprecated ports can be easily > > resurrected if someone steps up to maintain them? > > Actually you spend much time speaking about/looking for "popular" > ports and that is what is met with uninterest. > If you want to take maintainership of a port because you personally > use that port and want to have it working, that is great. > If you want to take maintainership of a port because you believe that > it is a "popular" port, then go ahead, just don't expect much help > with identifying such ports. > > > > > Every response from the committers ignored what I said I was trying > > to do, and instead repeated the same old arguments about stale, > > unfetchable, broken or superceded ports. That "talking points" > > response tells me that they didn't want me doing what I was doing > > to buck an already-established policy of letting unmaintained ports > > die unless and until someone complains. > > (Actually the policy is that unmaintained and non-working ports should > be let to die, unless somebody steps up to fix the port and take > maintainership.) > > Nobody is stopping you from assuming maintainership of one or more of > those unmaintained ports, and thus preventing them from being removed. I concur with Erik. I think you are totally missing the point of the original post. The desired wish was to remove dead ports that could not be fetched, or would not build. Possibly, even superseded ports; although that was not specifically mentioned I don't believe. In to many of those cases those ports have no formal maintainer. Unfortunately, some do. In any case, it was proposed that those said ports be removed. Ports that are current would not be affected. As you stated, your ports are current and in working order. This proposal would therefore not effect you unless I am also misreading the intent of the proposal. -- 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 more we disagree, the more chance there is that at least one of us is right. ___ 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: saving a few ports from death
> From: Anton Shterenlikht
> Date: Wed, 27 Apr 2011 10:14:41 +0100
> To:
> Subject: Re: saving a few ports from death
>
> On Tue, Apr 26, 2011 at 03:55:56PM -0700, Charlie Kester wrote:
>>
>> My search for "popularity" metrics is intended to point me, as a
>> maintainer, to ports I might want to adopt now, rather than wait for
>> someone to complain about them. Everything *I* use is already
>> maintained, so I've moved on to looking for things other people might
>> need. But I don't want to waste my time on something that nobody uses.
>> :)
>
> Interesting..
>
> I used this sh(1) script to find
> unmaintained ports that I use.
> (I couldn't find a way to do the
> job with the existing tools like
> pkg_info or portmaster):
>
> #!/bin/sh
>
> prefix=/usr/ports/
> makefile=/Makefile
>
> for file in `pkg_info -oxa | grep "/"`
> do
> yes=`grep MAIN ${prefix}${file}${makefile} | grep ports`
> if [ -n "$yes" ]
> then
> echo $file
> fi
> done
>
[SNIP]
Small observation, since that script picks up all of us who use 'ports' in
our maintainer email addresses (myself for example), might I suggest the
following tweak to your script (full address and checking for file
existence):
#!/bin/sh
prefix=/usr/ports/
makefile=/Makefile
for file in `pkg_info -oxa | grep "/"`
do
if test -f ${prefix}${file}${makefile}
then
yes=`grep MAIN ${prefix}${file}${makefile} | grep -i 'ports@freebsd\.org'`
if [ -n "$yes" ]
then
echo $file
fi
fi
Done
Although in only greping makefiles that exist it doesn't alert you to your
installed ports when the port has been removed from the tree...
It's an interesting situation and I wonder if there is a tool (I suppose
akin to portaudit) that alerts sys admins when ports they have installed are
depreciated or maintainers drop them? Obviously one can sign up for the
various types of alerts from Freshports, but I expect a few people here have
rolled their own periodic alert tools...
Regards
Eric
___
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: saving a few ports from death
On Tue, Apr 26, 2011 at 03:55:56PM -0700, Charlie Kester wrote:
>
> My search for "popularity" metrics is intended to point me, as a
> maintainer, to ports I might want to adopt now, rather than wait for
> someone to complain about them. Everything *I* use is already
> maintained, so I've moved on to looking for things other people might
> need. But I don't want to waste my time on something that nobody uses.
> :)
Interesting..
I used this sh(1) script to find
unmaintained ports that I use.
(I couldn't find a way to do the
job with the existing tools like
pkg_info or portmaster):
#!/bin/sh
prefix=/usr/ports/
makefile=/Makefile
for file in `pkg_info -oxa | grep "/"`
do
yes=`grep MAIN ${prefix}${file}${makefile} | grep ports`
if [ -n "$yes" ]
then
echo $file
fi
done
I got:
print/libpaper
graphics/libwmf
print/mgv
x11-toolkits/open-motif
devel/t1lib
print/transfig
textproc/urlview
graphics/xfig
all of which I use daily,
either directly of via
dependencies (xpdf or
ImageMagick). So if you have
the time and determination,
I'd be extremely grateful
if you decide to take up
the maintainership of
either of these ports.
Many thanks
Anton
--
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: saving a few ports from death
> Where is the current list of deprecated ports? > You can find the deprecated ones here http://www.freshports.org/ports-deprecated.php and the one set to expire there : http://www.freshports.org/ports-expiration-date.php regards, Bapt ___ 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"
FreeBSD Port: ntp-4.2.7p78
Dear Mr. I noticed the ntp-devel port has not been updated in nearly 6 months. The port currently has ntp version 4.2.7p78, while the current development version at ntp.org is 4.2.7p158. Do you have any plans in the near future to keep the development ntp port more up to date with ntp.org? Best regards, Adri Koppes ___ 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: Dropping maintainership of my ports
Hi! > > No, it's more than that. I got the distinct impression that many of the > > committers would be unhappy if I took maintainership of some of the > > ports I might identify as "popular", because it would interfere with > > their plans to trim the portstree. > Then you have misunderstood things. I don't think anybody would be > unhappy if you (or anybody else) took maintainership of one or more of > the currently unmaintained ports. There are two things. Becoming a maintainer seems to be really easy. Having one's PRs committed is a bit more difficult and sometimes takes 4-6 weeks (I had a case recently with 155399 and 155400). Maybe, if maintainer can "somehow easily" become ports committer, this hurdle might be lower ? -- p...@opsec.eu+49 171 3101372 9 years to go ! ___ 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 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, 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. -- 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: Dropping maintainership of my ports
On Wed, Apr 27, 2011 at 12:15:43AM -0700, Charlie Kester wrote: > On Tue 26 Apr 2011 at 23:27:40 PDT John Marino wrote: > > > >You're just sulking because your idea of identifying popular ports > >wasn't met with enthusiasm. > > > > No, it's more than that. I got the distinct impression that many of the > committers would be unhappy if I took maintainership of some of the > ports I might identify as "popular", because it would interfere with > their plans to trim the portstree. Then you have misunderstood things. I don't think anybody would be unhappy if you (or anybody else) took maintainership of one or more of the currently unmaintained ports. What plans there are, are not so much about trimming the portstree in general but trimming the number of unmaintained ports. What is met with uninterest is your plans to identify "popular" ports. > Re-read the thread. At every point I'm talking about looking for ports > I (and others) might want to maintain, as a service to their users. Now > ask yourself why I've been getting so much resistance to that, when we > keep hearing how deprecated ports can be easily resurrected if someone > steps up to maintain them? Actually you spend much time speaking about/looking for "popular" ports and that is what is met with uninterest. If you want to take maintainership of a port because you personally use that port and want to have it working, that is great. If you want to take maintainership of a port because you believe that it is a "popular" port, then go ahead, just don't expect much help with identifying such ports. > > Every response from the committers ignored what I said I was trying to > do, and instead repeated the same old arguments about stale, > unfetchable, broken or superceded ports. That "talking points" response > tells me that they didn't want me doing what I was doing to buck an > already-established policy of letting unmaintained ports die unless and > until someone complains. (Actually the policy is that unmaintained and non-working ports should be let to die, unless somebody steps up to fix the port and take maintainership.) Nobody is stopping you from assuming maintainership of one or more of those unmaintained ports, and thus preventing them from being removed. -- 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: Dropping maintainership of my ports
On Tue 26 Apr 2011 at 23:27:40 PDT John Marino wrote: You're just sulking because your idea of identifying popular ports wasn't met with enthusiasm. No, it's more than that. I got the distinct impression that many of the committers would be unhappy if I took maintainership of some of the ports I might identify as "popular", because it would interfere with their plans to trim the portstree. Re-read the thread. At every point I'm talking about looking for ports I (and others) might want to maintain, as a service to their users. Now ask yourself why I've been getting so much resistance to that, when we keep hearing how deprecated ports can be easily resurrected if someone steps up to maintain them? Every response from the committers ignored what I said I was trying to do, and instead repeated the same old arguments about stale, unfetchable, broken or superceded ports. That "talking points" response tells me that they didn't want me doing what I was doing to buck an already-established policy of letting unmaintained ports die unless and until someone complains. Today wasn't the first time I've had this discussion with them. But it was the last straw as far as I'm concerned. ___ 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"
