Hi Christian, On Tue, Jun 13, 2006 at 10:18:19AM +0200, Christian H?tter wrote: > I've the wish to contribute to Debian. However, from all the stuff > needed to be done I would be best at coding, I guess. Although Debian's > Social Contract doesn't prevent people from writing Debian-specific > software, it IMHO propagates not to do so (c.f. "We will give back to > the free software community") but rather, whenever possible, "only" free > software which than can be converted into Debian (-specific) packages. Correct. "Normal" packages have an "upstream" part, which is a release tarball with no Debian-specific things in it, plus a Debian part. For most packages the Debian part is rather small (but in some cases it contains patches which upstream doesn't want to include/didn't include yet). > On the other hand, the free software community, including quite some > distributions based on the Debian project, can (and actually do) derive > programs from rather Debian specific sources, Well, yes, but they usually fork almost the entire distribution. Within such a fork, Debian-specific packages can be very useful. On a different distribution they are probably not. > while uploads of free software often remain unused because they are > considered amateures work which is to buggy to include in a distro and to > work intensive to audit. I don't think this is the reason, although it may play a part as well. The thing is that in order to get into Debian, two things must happen. The software must be packaged, and there must be someone to upload it. For both these things there must be a person willing to do it. In particular the packaging requires a person who wants to commit to maintaining the package for some time. I think the absence of such a person (or the person not having found the software) is more likely the reason for not having software included. > Thus, the free software community would benefit more from an already > distributed (and thus considered rather stable) program. I think Debian can be a benefit for the free software community by being as complete as possible (in terms of free software). That is, Debian should include any free software program which is considered valuable by some people. Mature programs almost automatically are, so they should (almost) all be included in Debian indeed. But many less mature programs should as well. > Now I'm completely unsure what to do in order to help Debian as good as > I can: > (a) "Just" writing free software and hope that it is good and attractive > enouth to be included in Debian when it is needed and ready. This likely doesn't work well, since packagers of new software are not so easily found. See below as well why I wouldn't do this anyway. > (b) Write free software according to the Debian guidelines and (try to) > find a Debian Maintainer who is willing (and has the time) to audit and > upload the software. This is very reasonable. In particular, if you want to become a Debian Developer (with voting and upload rights), you need to do this as a first step. Note that you're building the Debian package, and the sponsoring Developer only reviews (and uploads) it. > (c) (Trying to) become a Debian Maintainer, If you should want to become a Debian Developer depends on what you want to do. If you will maintain many packages, it is a very good idea. If you will likely maintain only one or two, which are pretty stable (so don't require a lot of uploads), you can also choose to use sponsors for the uploads and skip the (quite lengthy and moderately time-consuming) new-maintainer-process. The good news is that you can make this choice later. You will likely want to build Debian packages anyway (see below) and you will probably want to get them into the archive through a sponsor. You cannot actually start the NM process before doing that, so you can choose at a later time if you actually want to. > building and packaging the software on my own on basis of the ideals, needs > and policy of the Debian project (and thus *for* Debian and only implicitly > for the free software community). This doesn't have to be the case. There are some good things about packages which make them useful even for programs which will not be included in Debian: - It is easy to remove the software again. Without a package you must keep track of where all the files are (in particular make install; <change things>; make uninstall ; make install may leave stuff on the system, because it will uninstall the files from their new locations, which may be different from the old ones). With a package this is done for you by the packaging system (not for generated files, of course). - It is easy to transport the binaries including all their support files and documentation to a different system. - There are proper places for all your files. In particular, there is /usr/share/packagename and /usr/lib/packagename. For non-packaged software you probably have to put things under /usr/local, and since you didn't need to decide on a package name, you may not know what to call it. If you change this later, you get the problems of removing the software, as mentioned above (at least I always forget to uninstall before starting to change things). - Lintian and linda do some checks on the code (as opposed to most of their checks, which are on the package), which would be annoying to do manually. These checks point out problems to you, so your program gets better. For these reasons, I always make Debian packages of my programs, even for programs which aren't meant for redistribution at all (not that I write non-free software, I'm talking about programs that are not likely useful for anyone without my exact hardware setup). > Being aware that you can't give me the absolute answer to my question, > and because I really would like the idea to (try to) become a Debian > Developer (guessing that my dedication would increase quite a bit), I > would especially be interested in the answer to the question how much > time it takes to work really "Debian conform", that is, how much time > (the average) developers spend reading new guidelines etc., or better: > how much time is left for the actual development if you stay informed > about all the policy changes etc.? As I said, the new maintainer process costs some time, but that's a one-time invenstment. The same is true for building your first package. Once you know how things work, it's all pretty easy. (Well, the packaging part. upstream development doesn't get easier. ;-) ) You need to read policy once, and after that you can use the "upgrading-checklist", which summarizes the changes between versions. Well, that's how it works for me anyway, but I must note that I'm known for remembering things I read (as opposed to my girlfriend for example, who can read the same book twice withing a month and enjoy it both times. I would be bored to death the second time). I think you would like to build Debian packages, if only for your own convenience. When you have done so, you may want to maintain the package in the Debian archive, and look for a sponsor. After that (or better, several times that), you can apply to become a Developer if you want to. When learning to build packages, there is of course lots of documentation. Personally, I found the Debian-Women wiki page about very nice: http://women.debian.org/wiki/English/PackagingTutorial Of course the official documentation (new maintainer's guide, developer's reference) is very useful as well. You can also start with adopting an orphaned package, so you don't actually have to create a whole package yourself at first, but can adapt an existing package. Personally I wouldn't do that at first, because if the package isn't done nicely it teaches you bad habits. :-) If you want to learn packaging but don't have some upstream work ready, you can look at the requests for packaging. Those are from people who want some software in Debian, but don't want to/know how to package it themselves. Both orphaned packages and requests for new packages are found as bugs of the wnpp pseudo-package. Orphaned packages start with O:, request for package with RFP: http://bugs.debian.org/wnpp (ITP/ITA means intent to package/adopt. Don't touch these without communicating with the person who expressed the intent. And retitle the bug to this if you have the intent. RFA is request for adoption. Similar to O, but the previous maintainer is still around to set you up. RFH is request for help, which means a co-maintainer is wanted.) > P.S.: To help you answering my question here some information about me: > I'm a student of "Computational Visualistics" with special interests in > software engineering (and, of course, everything that has to do with > images, especially image synthesis). You may be interested in packaging hugin: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=251618 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=246244 (That's twice the same request, but with slightly different history.) > I like experimenting with computer technology in general and > security-specific topics in particular. Totally off-topic for this list, but in that case I want to let you know about the new Hurd port. (No code written yet, don't expect too much. ;-) ) Security is a very strong focus for it. Please see the mailing-list archives at http://lists.gnu.org/archive/html/l4-hurd/ (Don't be confused by the name, we are currently mostly talking about coyotos as a kernel, which is not l4) and/or subscribe and hang around a bit. The wiki is perhaps a more suitable place to get to know the project: http://hurd.gnufans.org/bin/view/Hurd/NextHurd If you want to reply about this part, please do so off-this-list, privately or on l4-hurd@gnu.org. > Reading a request on a not-yet-existing program on a german Debian board > about a month ago I started to seriously consider contributing to Debian > after I've written the program for only one person due to the lack of > reliable, trustworthy posibillities to test and share the program. Even without sharing, I think you will like to package it anyway. And when you've packaged it, you can of course try to find a sponsor to get it in Debian. :-) Have fun, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html
Attachment:
signature.asc
Description: Digital signature