Raphael, thanks for your thoughts.
On Sun, Oct 28, 2007 at 01:33:20PM -0600, Raphael Geissert wrote: > In my very personal opinion I think m.d.n is fine as it is now. It itches in my fingers to add a few fancy features. :) And I've seen what Python web frameworks can do so I'd be willing to do more than what's absolutely needed anyway. But I wouldn't say that it doesn't work. I wouldn't even say that a ppa.debian.net would supersede mentors.debian.net. > Since the first time I heard about doing all that job on m.d.n I tough > it was a waste of time (implementing) and resources. Partly. Perhaps. But on the [EMAIL PROTECTED] list you don't get a proper impression of which packages need sponsoring. I've often sponsored a package when the maintainer afterwards mailed me that some other DD has already jumped in. I didn't know that. And some basic automatic QA checking was needed, too, because I've hardly ever had a package that was ready to be uploaded without a few changes. I was thinking a lot about the sponsorship process back then and even talked to the Ubuntu guys when they were brainstorming about MOTUs and the REVU tool. Sponsorship should be made as easy as possible or otherwise Debian might miss interesting software and maintainers (who are not DDs) might get frustrated for creating packages that never get used. Implementing that was also partly fun and even helped me learn more about the syntactical subtleties of control files and possible repository layouts. > Ratings system: > As others have already said, they are useless and may cause more conflicts. IMHO rating packages is good (like pointing out problems or saying the classical "I'm not a DD but I've tested your package and it looks good"). Rating people sucks though. However I think that rating and commenting is the same feature. More like: "2 people were happy with your package - 12 said it's unworthy to get sponsored". > Comments system: > We already have [EMAIL PROTECTED]; adding a comments system might of > course reduce the number of emails sent to the list but might also > prevent many useful comments from being said. Other maintainers might not learn from hints they get from a RFS thread on the mailing list. But having to follow different media is distracting. You have uploaded your package to a website but discuss matters on the mailing list. I think that mailing lists are good to discuss general matters or to get help. But when you need to get comments on a package I think the comments should be found where the package is. Like I don't like to create cryptic mails when being on the shell but using the "bts" command-line tool. There are a few examples where information is kept together. > Subscribing to packages, /msg to sponsors: > I also think it is a waste of time. > Maintainers should either contact their sponsor or send an email to > the list when they need a mentor/sponsor. Same applies here. Why can you subscribe to bugs in the BTS then? > Communication between the maintainer and the sponsor is very > important; and most of the suggested features just reduce the > communication between them. IMHO it makes the communication easier and the people involved do not have to jump between BTS, email, mailing lists, IRC and a web site. As a sponsoree I'd perhaps manage multiple packages and would like to see what I have to do, which package was sponsored, where I have to fix bugs etc. Maintainers should know which means of communication Debian uses. But just because RFS have been sent to the mailing list doesn't mean it's the best way. But that's probably the same like when my coworkers try to convince me that "web forums" (phpbb etc.) are the only means to communicate and mailing lists stink. > If somebody wants to get a package in Debian's archive they should get > more involved with the _community_. And the key point on this is > communication. No denying that. But the community is distributed across different media. I wouldn't expect someone to just use mentors.debian.net and not being subscribed to [EMAIL PROTECTED] Many DDs dislike IRC. Many aren't subscribed to anything but debian-devel-announce. I myself unsubscribed from debian-devel from time to time because my asbestos pants where in the washing machine. > Shorter urls: > This can be done with mod_rewrite; there's no need to change anything > on the backend. Just cosmetics. Simple with web frameworks, too. Apache and CGI sucks for certain tasks. I even have a daemon to watch the apache access.log to count downloads of DSC files. It should have given me a hint that I was working around Apache. I just like that I can call qa.debian.org and packages.debian.org with my email address or a package name and get information on that. > "Making information available to others through proper interfaces...": > Is this really needed? Neil McGovern asked for a proper interface to use for sponsors.debian.net once. > "make the Python code available...": > Cristoph already said he was worried about sharing the code (maybe he > used other words). Let's say that some of the code sucks and I wouldn't expect anyone else to be so desperate to use it for their own applications. :) Fortunately my Python skills have advanced a lot since. I've put the repository online at http://workaround.org/mentors.debian.net Let me know if you find security bugs or passwords left around. > m.d.n as a deb-src: > I only use dget :) +1 then. Other DDs also said they didn't want to "aptitude update" just to get the new list of packages from m.d.n and prefer dget. So do I. The URL to the .dsc file is all you need then. > statistics: > As a maintainer I don't really find useful to know the number of times > a package has been downloaded nor the number of page views if the > person who downloaded/visited doesn't give any feedback. > So I think these could be dropped. Might be useless indeed. Not sure how curious a maintainer is. When I packaged my first pieces of upstream software I couldn't await someone to take a look. And even today I often get /msg'd by sponsorees because they just finished a package and were eagerly waiting for me sponsoring it. :) > When I first decided to create my first package I found kind of > difficult to find the right information. > So here are some comments that might help improving the websites and > documentation: > > Some people pointed me to the maintainer's guide, but some of its > pages should be updated. There are many tools now that should be > mentioned. > The first thing that comes to my mind is section 4.1 which describes > the control file and how to find build-depends: dpkg-genbuilddeps > could be mentioned in this case. > > Some guides/documentation point to mentors.d.n or sponsors.d.n; but as > a newcomer I was clueless on what I was supposed to do there. > Providing an start point at m.d.n would be great and I think it would > help a lot of people who want to get involved but don't know exactly > where to start. The current web site (as opposed to the version from 2003-2005) has at least an introductory article. From what else you said in your posting I assumed you'd rather say "there is the policy and the reference - why bother writing redundant information". ;) Seriously. I'd welcome written text that can be used on the introduction. Cheers Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
