[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Task list for a policy release



Manoj Srivastava <srivasta@debian.org> writes:

>  * #402780: debian-policy HTML "next" loops
>         This is either not a bug, or can't be fixed in policy: should
>         forward to debiandoc

Agreed.

>  * #47438: [PROPOSAL] update policy copyright
>         This is too hard to resolve right now; and might be moot, if we
>         do a policy rewrite in modular docbook

Right.  I think we punt on this for the time being.

>  * #175064: Debian policy documents should be UTF-8 encoded
>         Whoof. Well, we can make sure that the source files are in
>         UTF-8; and that we set ALNG=C in front of the debiandoc2X
>         invocations. but I am not sure that is enough.  Punt to the
>         docbook rewrite?

I vote we punt on this.  I'm not sure that debiandoc is up to the task,
DocBook will be, and I'd rather not put a lot of effort into the old
documentation tools for a bug that's been outstanding for this long.  It
can wait a little longer.

>  * #203098: debian-policy: using <link rel="..."> would be nice
>         Again, this is a debiandoc conversion issue, and should be
>         either forwarded, or closed.

Agreed.

>         The last bit is to look at the bugs with usertag wording; where
>  wording has been proposed; and to determine if the proposed wording is
>  acceptable and resolves the issue that was raised.

Here's my rundown on those with brief comments:

#452393: [PROPOSAL] clarify overstep between "required" and "important"
priorities

I'm inclined to accept and commit the patch in the bug.  It looks good to
me and I agree with the problem stated.

#402975: debian-policy: Introduce a requirement for internationalisation
of debconf templates

I think this is good to commit as-is, except changing should back to must.
Time has moved on since the last policy release.  I think it's fine to
make translation a requirement.  But if anyone objects, it's fine with me
to put it in as should for now and upgrade it later.

#392362: [PROPOSAL] Add should not embed code from other packages

I have proposed text that I'm happy with.

#379150: Documentation for Breaks in dpkg

This support was added in dpkg 1.14.6, so I'm inclined to accept and
commit this patch.  I trust Ian to document the feature, and the wording
seems fine to me.  The only caveat is that I don't know if we're ready to
accept Breaks fields in the archive already, and I'm not sure who to ask
about that or how to decide it (ftp-master?).

#367984: Policy 8.2 has unclear last sentence

Agreed with the problem, but I'm not sure about the solution of adding a
separate section for compile-time support programs.  An alternative fix
would be to drop any mention of the development package in this section
and mention *-config scripts elsewhere.  I think the wording needs a bit
more work here, but probably not a lot.

#363133: [PROPOSAL] Document support of package types in shlibs files 

I think this is fine with my suggested changes.  I'd be inclined to commit
it.

#250202: [PROPOSAL] "debian/README.source" file for packages with
non-trivial source

Bleh.  This is kind of a mess.

I don't like the last wording proposal in that it advocates strongly
against using quilt or dpatch, which as near as I can tell from other
Debian mailing list discussion and packaging teams are widely considered
best practices inside Debian even though they don't immediately give you
editable source.

I think the README.source idea is a good one and the basic idea of this
patch is solid, but all the stuff about recommended rules targets and the
like feels murky to me, as does the strong urging to unpack the source
with all patches pre-applied.

I don't think this one is really ready yet.

#209008: debian-policy: [PROPOSAL] common interface for parallel building
in DEB_BUILD_OPTIONS

This needs a decision on whether to use , or space as a separator for
different options and then some fiddling with the way that the options are
parsed, but I think with a little bit of work it would be done.  But I
don't think it's ready now.

#172436: [AMENDMENT 12/04/2004] web browser url viewing

On one hand, I really think we should just commit this and be done with
it, since it's largely implemented and it's been around for forever.  On
the other hand, the whole BROWSER escaping and quoting and whatnot is a
mess and aj has some good points at the end of the bug log about that.

I notice that /usr/bin/sensible-browser implements BROWSER in a way that
one has to be careful with the BROWSER setting to avoid security issues
with some URLs, which may not be horribly ideal.

I think I'd lean towards committing this as-is, since BROWSER is a general
standard implemented elsewhere, not just a Debian thing.

#114920: [PROPOSAL] remove foolish consistency in perl module names

This seems reasonable on its face, and I don't think the bug discussion
raised much in the way of serious issues.  On the other hand, we've lived
without the exception for a long time now, and I'm not sure I understand
just what's wrong with long package names.  Is it a UI issue?

#65577: [Amended] copyright should include notice if a package is not a
part of Debian distribution

I think this is a great idea and should be done.  However, I don't think
it's currently being done with contrib and non-free packages, so it's one
of the standard Policy chicken-and-egg situations.  I'm in favor of
applying this at the recommendation level (instead of the should that's in
the current wording).

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: