From owner-freebsd-ports Mon Aug 5 16: 1:58 2002 Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C49EA37B400 for ; Mon, 5 Aug 2002 16:01:55 -0700 (PDT) Received: from c3po.artlogix.com (sense-mcglk-240.oz.net [216.39.168.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67EF443E65 for ; Mon, 5 Aug 2002 16:01:54 -0700 (PDT) (envelope-from mcglk@artlogix.com) Received: from ralf.artlogix.com.artlogix.com (ralf.artlogix.com [192.168.0.4]) by c3po.artlogix.com (Postfix) with ESMTP id BFAD71A947; Mon, 5 Aug 2002 16:01:53 -0700 (PDT) To: ports@freebsd.org Subject: Re: Current unassigned ports problem reports From: Ken McGlothlen Date: 05 Aug 2002 16:02:08 -0700 Message-ID: <86k7n4yknj.fsf@ralf.artlogix.com> Lines: 79 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org naddy@mips.inka.de (Christian Weisgerber) writes: | Importing new ports is work. First, the committer needs to carefully check | the port. The quality of the submissions varies tremendously. Some ports | can be committed right away with little or no changes, some need extensive | reworking. Frequently, pointing out what's wrong to the submitters isn't | enough, because they don't know how to fix it. Or worse, they don't care. | The committer may end up re-writing the port himself. Communication with | submitters can be cumbersome. Some people take several days to respond to | e-mail. This is all very frustrating and tiring. Well, let's take the example of the shells/scponly port, which I submitted myself back on July 23. (I'm not upset about this; as the spectrum of delayed ports goes, this is nothing.) I think the quality is good. It's not a complicated port; in fact, it nearly compiled out of the box, and after the author of scponly accepted a few patches from me, the port got even simpler. I care about the port. Nobody's ever written me with problems, and I respond to email pretty much right away. I'd have an inkling what to fix if a problem were pointed out with it. Working on it is still fresh in my mind, of course, which helps. Now, say I submitted the port, and it languished for nine months. Then I get contacted with some issue regarding the port. What port? Oh, that thing. I gave up a long time ago. They want a change? Why bother? They'll sit on it for another nine months while I watch the software behind the port go through three more releases. And so on. . . . Now, *I'm* not so easily discouraged, but when you have people wanting and willing to contribute to FreeBSD, and their contributions are effectively ignored for months at a time, they're bound to think nobody cares. And that costs the effort some potential contributors. Keep in mind: I don't have a personal problem here. The existence of the shells/scponly port isn't going to affect very many people, and I already have it working on my system, and so there's no inconvenience to me. And I know that the FreeBSD team is stretched pretty thin as it is, and that there are problems with the process. All acknowledged. But I still think it's a problem, and that it needs to be solved. | > Perhaps another CVS tree (/usr/testports?), where non-committers can test | > the submitted ports and provide feedback? | | There's nothing to stop people from testing uncommitted ports. Except the risk of screwing up their systems. The nice thing about a different CVS tree is that you can have a completely different /usr/whatever/Mk tree with different options, so that things get put into, say, /usr/test rather than /usr/local, without changing the port Makefiles, sources, whatever. A separate /usr/whatever/distfiles directory keeps collisions from happening there as well. Uncommitted, untested changes could take place immediately in the /usr/whatever tree, and anyone who wanted to test them could just cvsup and try make, make install, whatever without screwing around too much with their installation. Also, some new targets could be created, such as make workedforme make brokenforme make needsfixing or whatever, which would generate appropriate PRs (or amendments to existing PRs) which would then get sent to the submitter and the PR database, and so on. When a port is working for the most part, the PRs would reflect that, and it might become a little smoother to look for ports that are working out for most people and commit them. I'm just brainstorming here, but such a process would be nice. The quality of the ports would get a little better, I suspect, and things wouldn't necessarily languish for months. More people would be willing to participate in the port-testing process. More contributions would get used and implemented in a timely manner, which would please the contributors. Not that I'm married to this concept; I'm sure there are other ways to accomplish the same thing as conveniently. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message