Re: DEP-2: Debian Package Maintenance Hub
* Raphael Hertzog [120127 07:49]:
> High-level design of the new infrastructure
> -------------------------------------------
>
> ### Fixing the flow of information
>
> In order to cleanly solve the problem of the information flow, and to get
> rid of the hacks made everywhere to send a copy of the mails to the PTS,
> packages would be (progressively) modified to indicate
> Maintainer: <source>@pkgmaint.debian.org in their control file.
>
> Until all packages have been converted, the PTS would forward copies of
> the mails to ensure that the new infrastucture can still be used for all
> packages (even those who have not been updated yet).
>
> Using this intermediary address also solves the problem of maintainers who
> orphan their packages and are still listed as maintainers in many released
> packages.
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).
Having that new address there might look like it is easier to get to a
new system, but I fear it might it much harder to get to a sensible
system in the long run:
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).
[1] Perhaps with an intermediate period of having that field with that
value. Put planing for that field to stay while it would be required to
be useless in the long run is only planing for cruft.
> ### 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).
Bernhard R. Link
Reply to: