New port with maintainer ports@FreeBSD.org [was: Question about
maintainers]
Danny Pansters
danny at ricin.com
Fri Jul 29 00:29:09 GMT 2005
<Too much to quote />
<And no CCs damnit! />
I'd like to contribute some observations. I think these may be of general
notice.
(1) We have too many ports as it is. Of course we also have too many
unmaintained ports but the fact is that for the present workforce we have too
many ports altogether. And although we have a very good influx we'll have too
many ports 2 years ahead also and likely 4 as well. They're growing
exponentionally.
(2) There are quite a lot of ports that are not up to what we should consider
QA standards. Most but not all of them comprise unmaintained ports. (personal
idea: nuke approximately half of them)
(3) So there appear to have been some very capable people who perhaps
partially got their commit bits to ports by bringing in lots of, ultimately
unmaintained, ports. Question: why this route to commit-dom anyway? I for one
love to add and maintain useful ports but heck I don't want to be a
committer. Could it be that previous practice invited this behaviour? I'd say
yes.
(4) So, what about another and more realistic route to being a committer vs
being a contributor? For example, a committer could assume a "mentor-light"
role for ports contributors, and ideally commiters wouldn't have to be
contributors themselves at all (fat chance I know ;-). Or we could have
pointyhat by-proxy of the committer so that the chain of communication is as
short as it needs to be. Those kinds of things can surely be improved and
would help to keep new people aboard. But, yeah, it would involve some
"rules".
I'd also like to express some of my own experience and ideas, mostly in reply
to Paul, and of personal notice:
(Roman may want to read also... you first dismiss what appears to be my sort
of "users" as not wotrhy and after that we appear to be having the same
annoyances:)
I'm not a programmer either. The only thing I learnt at uni was half baked
turbo pascal (6 weeks) and a crash course to DOS (3 weeks). In hindsight the
most useful thing I learnt was tex. At a later stage (~ 1996) I discovered
the internet and later on (~1998) Linux. In 2000 I started using FreeBSD.
I've only done a Java course once (after uni), and since then I taught myself
to use python and FreeBSD. All my understanding from C and C++ comes from
that starting point. So obviously I'm often stumped when working on a port,
but googling and bsd.ports.mk'ing along I get by. That is not to say that
sometimes maybe some more focused help from the FreeBSD people (the
committers) might be exactly what's needed.
In the meantime I took over all ports that have to deal with python bindings
to qt or kde and maintaining them. I like it. I like python for GUI stuff and
intend to bring that onto FreeBSD as a Qt/KDE development platform and have
it be increasingly better and complete (most of this depends on the original
authors also). So that developers can use it (myself first of course ;-).
Yes, I have problems everytime, whether because the snapshot changed a lot or
because of my ever trying to have the ports themselves behave more the same,
but I'll maintain them until I lose interest and if I do I'll leave them in a
working state. I feel that's expected. Besides, if nothing would ever break
it wouldn't be fun.
If that is what Frank means to say then I can only agree. I want "my" stuff to
work well and as expected, otherwise i rather retreat it. Or ask for help.
I can spell an example of a port I've gotten across that was nearly-working
when committed and since then half baked until an update to one of the ports
I maintain broke it. I wont name it :) but neither will I fix it. And there
are many cases like that.
As I said before ideally committers would not need to maintain any ports
themselves, obviously this is not true today but wouldn't that be a much
better goal than to just have as many ports as get thrown in and never mind
QA? QA is more important than quantity. It's the committers who should (and
in practice of course mostly are) looking after QA. And their job can be made
easier if less crap ports without maintainers are committed. I can use nicer
words, but that's how it is.
Please note, Paul, that as far as I have seen no one has been posting who
really put any contributor down for "biting off too much". It's a common
problem. I know it all to well. You can either work harder, ask for help,
give it time (don't underestimate this one ;-) or give up. The latter is OK
also. We're only human.
I fully agree with Mark and Kris on having a moratorium on _new_ ports without
a maintainer. They'll only cause harm later on if no one picks them up. It
creates expectations that cannot be met. A 1-3 month time period perhaps and
then if nobody becomes mainainer it gets slated for removal (even at that
stage someone could chip in). That's very reasonable IMHO. Someone has to
clean the mess somewhere.
Just my EUR 0.02,
Cheers,
Dan
More information about the freebsd-ports
mailing list