Date: Fri, 29 Jul 2005 02:27:08 +0200 From: Danny Pansters <danny@ricin.com> To: freebsd-ports@freebsd.org Subject: Re: New port with maintainer ports@FreeBSD.org [was: Question about maintainers] Message-ID: <200507290227.09027.danny@ricin.com> In-Reply-To: <1122588979.97751.1.camel@ikaros.oook.cz> References: <C3B81AFDB8A5DFB5AB566CC4@utd59514.utdallas.edu> <47ECFCB8BE498CEAB57757D7@utd59514.utdallas.edu> <1122588979.97751.1.camel@ikaros.oook.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
<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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507290227.09027.danny>