Re: DEP-2: Debian Package Maintenance Hub
On Sat, 28 Jan 2012, Bernhard R. Link wrote:
> Requiring the maintainer field to be set to a specific value effectively
> makes that field useless. It would make more sense to get rid of that
> field then[1]. (Though I'd prefer to make it only optional).
Well, it's not useless for a user who's looking for an email contact
with the people maintaining the package.
So I definitely see some value in keeping the field in the .deb.
Planning to drop it will require more work and coordination with many
teams for little gain.
One thing that we can discuss however is if we should hijack the
packages.debian.org MX for this and reuse the existing email adresses
that we already have.
I preferred to keep things separate to start but I'm ready to be convinced
otherwise.
> One big problem is properly categorizing information. The system works
> best if everything going in is properly classified. Having a mail
> address everything looking at "Maintainer:" is sending mail to does not
> offer that. (It might be useful to have that address as a way to send
> a personal mail to the maintainers. But any service sending
> information should not be classified as personal mail, so even if it is
> sent as mail it needs to contain some meta-data and if implementing that
> one can also hard-code the mail address instead of using the
> maintainer).
The PTS already has this problem and we have code that categorizes it
based on various headers. And anything that doesn't match any known
category falls in some default bucket.
The presence (or lack thereof) of the maintainer field doesn't change
anything to this problem.
> > ### Using a modern framework for web development
> >
> > DDPO is implemented in PHP. The PTS uses a mix of Perl, Python, XSLT and
> > shell scripts. While both works very well and are reliable, we can do much
> > better by using a modern framework for web development (starting with
> > internationalization of the web interface).
>
> I guess almost any of them was considered the "modern framework" at
> their time. Focusing too much on "modern" and "framework" might lead to
> something ending like the pts's XSLT: something so modern and
> future-proof extensible that some years later most developers would
> prefer to only touch it with a very long pole.
>
> I'd guess that even some mixture of basic perl python and shell stuff
> will have bigger changes to still be easily modifyable by the mayority
> of developer in some years than any framework modern today. (Though
> limiting it to one of perl or python might even improve that).
Yeah, when I say "modern", it doesn't mean "recent" or "marginal". :-)
I agree that we should limit ourselves to either Perl or Python and my
experience is that Python is more widely used for web development than
Perl. I have been following (and somewhat maintaining) the Django
framework for Python and I was planning to use that.
http://www.djangoproject.com
It's well documented, relatively mature and has sane upstreams. But if a
majority of the persons who are usually maintaining the PTS, the DDPO and
the other relevant infrastructure want something else, I'm completely
ready to listen and investigate that alternative.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
Reply to: