On Wed, 2006-07-05 at 13:50 +0100, David Woodhouse wrote: > On Wed, 2006-07-05 at 08:02 -0400, seth vidal wrote: > > > SHOULD: If any form of networking over IPv4 networking is supported, the > > > same functionality over IPv6 should also be supported, and should be > > > enabled by default if the IPv4 support is. > > > > > > MUST: If IPv4 networking is supported, but for some reason the 'SHOULD > > > support IPv6' documented elsewhere is not obeyed, a bug must be opened > > > which should block the IPv6 tracker bug, and should contain a full > > > justification for the lack. > > > > requiring functionality in software is not part of the requirements for > > PACKAGING the software. > > It's a question of code quality. > > > We don't have i18n requirements for extras software, either. > > Perhaps we should? I thought we at least required that they join us in > the 21st century and operate correctly with UTF-8. Do we have _no_ > written guidelines on the quality of the software we accept to be > packaged? I assume basic security quality is at least part of the review process.. or I hope it is... if it is, then that is already about functionality and not packaging.. there would then seem to be a bit of a gray area (which is ok, it's what us humans are good at by making smart decisions rather than by-the-book decisions)... And if there is really no functional requirements in the spec.. maybe there should be a second spec/recommendation for functional things? That could be useful for external projects as well, as a checklist in the "did we forget anything to be useful to a wide audience" kind of way..
