Re: mentors.debian.net reloading
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 d-mentors@l.d.o; 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
Reply to: