Date: 05 Aug 2002 16:02:08 -0700 From: Ken McGlothlen <mcglk@artlogix.com> To: ports@freebsd.org Subject: Re: Current unassigned ports problem reports Message-ID: <86k7n4yknj.fsf@ralf.artlogix.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86k7n4yknj.fsf>