Comments on policy modifications
-----BEGIN PGP SIGNED MESSAGE-----
Apparantly there are enough problems with the way I've worded the
original changes that I'm going to need to rewrite it, so I'm
withdrawing the proposal. That being said, I'd like some
clarifications.
Compressed html changelogs:
If I understand correctly, Manoj's argument is basically that
except for extreme circumstances, the lack of convenience in dealing
with compressed html changelogs outweighs the size benefits. On that
matter I don't really have a firm conviction one way or the other, but I
have no idea what "arbitrary size" would be considered appropriate to
require compression. Is it reasonable to leave the decision to compress
up to the individual developer? I think I would prefer that to a number
arbitrarily carved in stone.
"Files" section:
I left the files section as it was in the original proposal under
the idea that a minimal set of changes was more likely to find
agreement. Originally, the thought was to separate the issue of
logfiles being a subsection of files rather than documentation from the
issue of "Files" needing a whole section devoted to itself. If there
are no serious objections, I'd like to keep this one as is. If anyone
feels that "Files" should end up in its own primary section, that could
be filed as a new wishlist bug.
<arch>-<os>:
There have been three suggestions on this so far. Add "hurd" to the
list of acceptable <os> strings (currently the only acceptable one is
"linux", add "gnu" to the list of acceptable <os> strings, and for each
current arch, add <arch.hurd>.
My preference is to go with allowing <os> to be either "hurd" or
"linux". Allowing <os> to be "gnu" is confusing (and inaccurate), and
the <arch.hurd> thing really looks like an ugly hack, and calling it
part of Linux isn't particularly accurate, either. Would any serious
problems arise from going with the "i386-hurd" model?
Postinst stuff in the description:
This is orthogonal to the typo fix that was in the proposal. If
that needs to be pushed, I'd like to see it done separately from this
proposal. That being said, I don't think it's a good idea. While it
might be acceptable to suggest (not require) that serious warnings about
installation problems or whatnot that might incidentally also show up in
a postinst be placed in the description, requiring that entire
postinsts, minus prompts, be placed in descriptions is a very bad idea.
A lot of postinst-echo'd information is completely irrelevant to what a
package is.
Proposal templates:
As a sidenote, if anyone has an idea for templates for proposals, or
a format that would make proposals more readable or in some other
manner more aesthetic or easier to deal with than what I posted, I'd
also like to know about it.
===========================================================================
Zed Pobre <zed@va.debian.org> | PGP key on servers, fingerprint on finger
===========================================================================
-----BEGIN PGP SIGNATURE-----
Version: 5.0
Charset: noconv
iQEVAwUBNfxifNwPDK/EqFJbAQGyrAf/SwG+lJbh7f4Pk19gdwPEjf5Sk87RPURP
W+eV7RGSDb1OQxxEUVjsgYJcdsQ/HCRGQ0W9DMKyUCgD4bdUcUCPeTRX5I0H2ziT
dxiXXfsRvDmJeECkOqNhp7G8KhYugGcYdSSeotvvyk9uHB2ReleCUVC10Vhz1Kqz
Ya0SCS44VPnsN8Ccyuyez888ioA331hxQT9tSmjLmsAKHuFp6AQ3bMbTMAKS4ReM
TddOzu2ZT8B4v86/opKH+5etP2E71zEd/ESWFmuOfQVq52upKwpea7cGJFyEy057
r5LwlBRMPUOx9PlZ8P1SKQrcyi+DHKA5naQkRBa6rxdP9Fx0C6Sppw==
=4KRR
-----END PGP SIGNATURE-----
Reply to: