Ability for maintainers to update own ports

Fernan Aguero fernan at iib.unsam.edu.ar
Tue Nov 11 06:43:04 PST 2003

+----[ Adam Weinberger <adamw at freebsd.org> (10.Nov.2003 21:21):
| > Is it so easy?
| > Where can I get a mentor? :)
| Submit lots of PRs, and a mentor will get you. As far as I'm concerned,
| people get offerred commit bits because committers get sick of
| committing so many PRs from somebody ;;)
| # Adam

And I think that maybe this is the reason why there are not
so many volunteers submitting stuff?

I may be able to maintain a couple of ports, but currently I
don't have the time to spent playing around with stuff I
don't know/need, just to get a committer's atention.

Although I'm now more experienced than I was a couple of
years ago, I don't consider myself a 'guru'. I can't program
in C, and I still have problems understanding the way
autoconf/configure works (in a way that would let me fix or
work around problems). But this hasn't stopped me from
trying to fix things.

In the past I sent a couple of PRs with updates for a few
ports. The maintainer was too busy to update them and I took the
time to help him. Some of the ports are now obsolete, as are
my PRs.

Thing is, I may take some time to work on a port and
fix/update it. I may also take some time to write to the
list asking for someone to pay attention to one or two PRs.
But if I get no reply I would consider that no one is
interested in the port, which is bad for end users and for
the project, because this really means that 'there was no
committer interested in the port'.

Which gets me back to the origin of this thread: should
maintainers have commit privileges for their ports?

My answer is that for big ports (Gnome, KDE, XFree86), ports
that are builduing blocks for other ports (autoconf,
libtool, etc.) and libraries that are widely used (gettext
comes to mind), we should follow our current policy.
Maintainers graduate to committers after showing proficiency
in what they do.
On the other side, there are many ports that are just
applications: no other port depends on them, and there is
little risk if the port is not perfect. In my particular
case I'm thinking in the biology stuff, because that's my
main interest. I guess that only a minority of the FreeBSD
user base would ever install one of those ports. And for
those that do, what is the potential impact of doing a
less-than-perfect port? Breaking hier(7)? In this case, 
the consequences of bad porting practices would impact the
port itself. 

My coin,


F e r n a n   A g u e r o

More information about the freebsd-ports mailing list