Bug#592317: developers-reference: Document the communication channels and what's expected from DD in terms of communication/marketing

On Tue, Aug 10, 2010 at 2:32 PM, Steve Langasek wrote: > On Mon, Aug 09, 2010 at 09:55:57AM +0200, Raphael Hertzog wrote: >> Among important things: >> - we want to make sure that people use d-d-a only for stuff relevant to >>   developers only, other announces or press-releases ought to be sent t

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 591857 ...

Processing commands for cont...@bugs.debian.org: > user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was r...@debian.org). > limit package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to '

Bug#591857: debian-policy: please clarify which of DEB_{BUILD,HOST}_* is which

Adam Borowski writes: > It is utterly non-obvious what the BUILD and HOST architectures mean. > Is the latter the build (duh) host, or the target host? > Is the former the machine you build _on_ or build _for_? > Browsing the relevant documentation (debian-policy, man dpkg, ...), I > found no p

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 581011 ...

Processing commands for cont...@bugs.debian.org: > user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was r...@debian.org). > limit package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to '

Bug#581011: Maintainer/Uploaders nomenclature

"J.M.Roth" writes: > I was always wondering (concerning 5.6.2/5.6.3): > 1) The "Maintainer" field can contain only ONE contributor, whereas > there may be several to the package. > 2) The "Uploaders" field can contain several people, whereas - > technically - there can be only one uploader. >

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 590696 ...

Processing commands for cont...@bugs.debian.org: > user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was r...@debian.org). > limit package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to '

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 459868 ...

Processing commands for cont...@bugs.debian.org: > user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was r...@debian.org). > limit package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to '

Bug#459868: debian-policy: Definition of Maintainer: when using a mailing list

Russ Allbery writes: > I like this general approach. Thank you! I played with a bit and came > up with the following. This retains a Policy should only for the > correct setting of the Maintainer field for an orphaned package and > remains silent on when packages are orphaned. This change has

Bug#590696: debian-policy: Correct name of the FHS in the package description

Christoph Anton Mitterer writes: > Attached patch would change the package description to use the correct > name of the FHS, which is not only a Linux thingy. Especially now that > we also have kfreebsd. Thanks, applied. -- Russ Allbery (r...@debian.org)

Bug#587991: perl-policy: /etc/perl missing from Module Path

Niko Tyni writes: > The last paragraph seems redundant to me. I suggest dropping it. > Otherwise it all looks good to me. Good point. Here's updated proposed wording. diff --git a/perl-policy.sgml b/perl-policy.sgml index 3b76b94..03e5dfb 100644 --- a/perl-policy.sgml +++ b/perl-policy.sgml @

Re: Notes from Policy BoF at DebConf10

Raphael Hertzog writes: > Since you want to switch to docbook anyway, I would suggest you use > publican to manage and build the documentation. It has built-in support > for translations, you can have conditionals in the markup and build > several variants of the document (with or without rationa

Re: Notes from Policy BoF at DebConf10

Hi, On Wed, 11 Aug 2010, Russ Allbery wrote: > Manoj proposes making each normative requirement in Policy a separate > XML entity, which allows building different merged documents in > different orders incorporating all or some of those rules. Those > sections could have separate rationales that