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