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/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120128174207.gn4...@rivendell.home.ouaza.com