Hi all, In my very personal opinion I think m.d.n is fine as it is now.
About more (building, piuparts, linda/lintian on binaries, etc) QA checks: I think the maintainer should make all of these checks before even uploading the package to m.d.n "but it is complicated to setup foo/bar/etc": if somebody is not able to setup the tool he should read a little further before trying to create a package. I'm involved with several projects and I'm sad most people doesn't read anything, they just download and install. I think the first "QA check" is to make sure the maintainer is able to check the quality of his packages on his own. The mentor then should also make sure everything is ok. A mentor of course could automate the build/checks process but that's up to him. My main sponsor, Anibal, has written some script which automate the job done by dget/pbuilder/piuparts/linda/lintian. He has already created a package for those tools, and when they are ready he will upload them. So other mentors/sponsors could easily install and use them. 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. Ratings system: As others have already said, they are useless and may cause more conflicts. 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. 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. Communication between the maintainer and the sponsor is very important; and most of the suggested features just reduce the communication between them. 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. Shorter urls: This can be done with mod_rewrite; there's no need to change anything on the backend. "Making information available to others through proper interfaces...": Is this really needed? "make the Python code available...": Cristoph already said he was worried about sharing the code (maybe he used other words). As I already said at the beginning of my message, m.d.n is just fine for me. So all I can think about is making the code public for DD's only until everybody working on it agrees it is safe to make it world accessible. m.d.n as a deb-src: I only use dget :) 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. 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. I think this is all for the moment. -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
