is
proposing anything like that.
How do you think this bug is prejudicial to advocates of alternative
init systems?
At any rate, we're unlikely to do a normative Policy release before
voting is done because we usually wait until we have more than two
normative changes waiting on our 'next&
ive releases, but before we
commit to that, I'd like to hear Adam explain how he thinks the GR
interacts with the bug at all, because so far as I can tell they're
orthogonal.
--
Sean Whitton
signature.asc
Description: PGP signature
looking at the diff.
Thanks again!
[1] https://janitor.debian.net/lintian-fixes/
--
Sean Whitton
signature.asc
Description: PGP signature
we'll get a better feel for how much work folks will
>be doing going forward on supporting other init systems, and thus on
>how quickly we should move versus giving them time to determine how
>they want to support equivalent functionality.
This is a sensible approach.
We clearly need progress on (3) more urgently than on (4) and (5), but I
am not sure there is any sensible ordering of (4) and (5), so let's not
worry too much about that.
--
Sean Whitton
signature.asc
Description: PGP signature
an RC bug, and Policy 'must'
requirements, to disagree.
The Release Team's conception of RC bugs, and the text of Policy, are
generated and updated by different processes, for different purposes. I
think Debian benefits from that diversity of normative processes, and it
would harm that to try too hard to keep the output of the two processes
in perfect sync.
--
Sean Whitton
signature.asc
Description: PGP signature
are more likely to already know
> about these subtleties.)
Yes, let's be sure to get this in.
--
Sean Whitton
signature.asc
Description: PGP signature
as we ought to get it into the next
Policy release to avoid creating any more cases that have to be migrated.
--
Sean Whitton
signature.asc
Description: PGP signature
``adduser.conf``.
>> +based on the ranges specified in ``adduser.conf``. New packages
>> +should follow the guidance of using an underscore prefix for their
>> +username.
>>
>> 1000-5:
>> Dynamically allocated user accounts. By default ``adduser`` will
I believe this should be a bit broader -- packages which are not new but
which are adding new users should also follow the underscore prefix
convention.
--
Sean Whitton
signature.asc
Description: PGP signature
thought the
> change accurately reflected what the GR conclusion was.
Likewise seconded.
--
Sean Whitton
signature.asc
Description: PGP signature
ce unit match a package's name."
Encouragement is still normative, so if we're going to encourage it,
it would be better to say /when/ it's encouraged and when it's not.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Fri 03 Jan 2020 at 08:27PM -08, Russ Allbery wrote:
> Sean Whitton writes:
>> On Sun 17 Nov 2019 at 05:48PM -08, Russ Allbery wrote:
>
>>> is being used.) You must not include the ``/etc/rcn.d`` directories
>>> -themselves in the archive either. (Only t
releases, including the information required for ``uscan`` to
> @@ -798,14 +799,13 @@ the upstream tarball. In order to satisfy the DFSG for
> packages in
> 2. include a copy of the sources in the ``debian/missing-sources``
> directory.
>
> -There is an optional convention to organise the contents of
> -``debian/missing-sources`` in the following way. For a sourceless
> -file ``foo`` in the subdirectory ``bar`` of the upstream tarball,
> -where the source of ``foo`` has extension ``baz``, the source is to be
> -located at ``debian/missing-sources/bar/foo.baz``. For example,
> -according to this convention, the C source code of an executable
> -``checksum/util`` is to be located at
> -``debian/missing-sources/checksum/util.c``.
> +Package maintainers are encouraged to use the following convention to
> +organize the contents of ``debian/missing-sources``: for a sourceless file
> +``foo`` in the subdirectory ``bar`` of the upstream tarball, where the
> +source of ``foo`` has extension ``baz``, the source is to be located at
> +``debian/missing-sources/bar/foo.baz``. For example, according to this
> +convention, the C source code of an executable ``checksum/util`` would be
> +located at ``debian/missing-sources/checksum/util.c``.
>
> Vendor-specific patch series
>
> diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
> index 06db3b5..09f58f8 100644
> --- a/policy/upgrading-checklist.rst
> +++ b/policy/upgrading-checklist.rst
> @@ -44,6 +44,10 @@ Version 4.5.0
>
> Unreleased.
>
> +9.1.1
> +No package is allowed to install files in ``/usr/lib64/``. Previously,
> +this prohibition only applied to packages for 64-bit architectures.
> +
> 9.3.2
> Packages that include system services should include ``systemd``
> service units to start or stop those services.
Seconded, except for the debian/missing-sources change, but including
the may->can change Sam suggested.
--
Sean Whitton
signature.asc
Description: PGP signature
some of the common words but that do not carry any normative
> meaning. Was there any consideration in using uppercased keywords?
Well, Russ has now gone through and eliminated non-normative use of the
keywords, so I think the question is moot.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Mon 27 Jan 2020 at 02:32PM -07, Nicholas D Steeves wrote:
> One thing I'm not sure about is what Policy section it would go in.
> Would it be appended to §4 as §4.18, or something else?
A new section of ch. 4 sounds good to me.
--
Sean Whitton
signature.asc
Descr
;re working towards declaring
dependencies on essential packages explicitly (if indeed that is
something we want to do, which I don't yet have a firm opinion on).
--
Sean Whitton
signature.asc
Description: PGP signature
Hello Josh,
On Tue 04 Feb 2020 at 04:13PM -08, Josh Triplett wrote:
> I think there's value in a bit of additional verbiage, which I suggested
> in a subsequent reply.
Okay -- I think further discussion would benefit from a concrete patch
against policy.git.
--
Sean Whitton
si
27;m probably missing other words. :)
I don't think we need to convert words that don't explicitly appear in
the keywords list -- "may not" would inherit its meaning from "may"
being a keyword, wouldn't it?
--
Sean Whitton
signature.asc
Description: PGP signature
end Janitor's work
with std-ver to do more than the sort of completely verifiable updates
described above, I would be grateful if you'd share your plans with
debian-policy@lists before implementing them; we may have something
useful to say.
Thank you for thinking carefully about std-ver, and once again for your
work on the Janitor project!
--
Sean Whitton
signature.asc
Description: PGP signature
lish,
> in addition to or instead of the description in Perl.
How about including both the Perl and the English, to make things easier
for the maximum number of people?
Removing the Perl strikes me as deleting something which could be very
useful to someone (e.g. if they're writing a scri
tnote here, so
the text is not normative. Thus I guess the authoritative version is
the implementation in dak.
In terms of preparing your patch, I would like to suggest that you give
the perl first and then maybe say "which is roughly equivalent to ..."
and then include your En
o
> span multiple lines. I'm guessing the syntax file is right and the patch
> should
> be changed?
In PCREs \s matches the newline character so I believe your text is
incorrect.
--
Sean Whitton
signature.asc
Description: PGP signature
> against: the entire changelog entry, or one line thereof at a time.
I see what you mean.
> Here's a revision of the patch incorporating the feedback so far:
I'm happy to go ahead and apply this though it would be useful for
someone else to verify the text does indeed agree with
us that
the requirement to seek consensus on debian-devel is not sufficient.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Sat 29 Feb 2020 at 09:38PM -08, Russ Allbery wrote:
> Sean Whitton writes:
>
>> One issue with using uppercased words is that people might think the
>> words have the same meaning as they do in RFCs, which they don't.
>
>> Your idea of marking key
us
that all licensing information should be available in that file.
[1] https://lists.debian.org/debian-devel-announce/2018/10/msg4.html
[2] Though, that does tend to slow down NEW review.
--
Sean Whitton
signature.asc
Description: PGP signature
the
requirements to document licenses in a way I did not intend.
--
Sean Whitton
signature.asc
Description: PGP signature
uld want the copyright notices
in d/copyright, but I disagree that my text leaves any room for doubt.
The text you quote would seem clearly to "require that copyright
information be included in all binary distributions".
Perhaps you could suggest an amendation to my text so I can better s
control: tag -1 + patch
Hello,
On Thu 26 Mar 2020 at 09:57AM -07, Sean Whitton wrote:
> The relevant parts of Policy to update are §§ 2.3, 4.5 and 12.5.
Here's a patch for seconding, and for the FTP Team to approve. Thanks
to Scott for prompting the "all copies" amenda
tributions;
>>
>> I'm assuming the entire list is supposed to hold at the same time? If
>> so perhaps adding an «and» here would make this completely unambiguous.
>
> Actually I think it would be the opposite. If we had:
I think Guillem means adding an 'and' after
dd "all of
the following" or something before the list.
> I'm don't think abbreviating debian/ as d/ is appropriate in policy?
> (Personally I fint it annoying also on debian/changelog, because then
> you need to search using multiple variants of the filenames, but meh
control: tag -1 +pending
Hello,
On Sun 05 Apr 2020 at 05:54PM -07, Sean Whitton wrote:
> Here's a patch for seconding, and for the FTP Team to approve. Thanks
> to Scott for prompting the "all copies" amendation.
FTP Team approval happened at today's team meeting:
Hello,
On Fri 10 Apr 2020 at 10:45PM +02, Guillem Jover wrote:
> On Tue, 2020-04-07 at 17:18:27 -0700, Sean Whitton wrote:
>> On Wed 08 Apr 2020 at 01:18AM +02, Guillem Jover wrote:
>> >> +The copyright information for files in a package must be copied
>> >>
s must not contain a non-default series file. That is,
+dpkg's vendor-specific patch series feature must not be used for
+packages in the Debian archive.
+
+(previously a "should not")
+
Version 4.5.0
-
--
Sean Whitton
signature.asc
Description: PGP signature
7;t forget that ..."
clause.
Thus the only Policy issue here could be the addition of an explicit
permission to use Debian revisions with 1.0 native packages. As
discussion is ongoing in the context of Lintian, that seems premature,
however.
So I think we can close the clone of this bug against Policy for now.
--
Sean Whitton
;
> Can I suggest that this sentence might be clarified as follows
>
> remember that hyphen (-) cannot be used in
> native {-package versions-}{+version numbers+}
>
> ?
Thanks, applied this change.
--
Sean Whitton
is seems superfluous, as it states on the "upstream_version"
> fragment:
>
> "The upstream_version may contain only alphanumerics and the characters
> . + - ~ (full stop, plus, hyphen, tilde)"
Technically superfluous but I think helpful to the reader, so I suggest
we just keep it.
--
Sean Whitton
. I don't see any sort of consensus
that we should deprive ourselves of the ability to declare packages
Essential.
> C) I'd support non-normative documentation that we don't expect to
> approve new essential packages in the future in policy.
This sounds like a good idea to me too.
--
Sean Whitton
t is required.
Well, it would need seconding, but otherwise, ACK.
Thank you for your interest.
--
Sean Whitton
signature.asc
Description: PGP signature
control: tag -1 + patch
Hello,
On Wed 30 Sep 2020 at 11:23AM +02, Christian Kastner wrote:
> On 2020-09-29 02:22, Sean Whitton wrote:
>> Technically superfluous but I think helpful to the reader, so I suggest
>> we just keep it.
>
> To be honest, as a reader, I found th
I'm working with Debian systems, I know I'm not going to have to spend
time improving my knowledge of awk, and anyway having to use a tool
which I think is worse.
I don't mean to suggest that this usecase of mine is decisive, but it
illustrates that the benefits of keeping Essential as it is are clear,
whereas the benefits of reducing Essential are, currently, vague. Could
we actually decrease installation size in a way that actually benefits
actually existing usecases if we were to start trying to reduce
Essential? I would like to see evidence of that.
--
Sean Whitton
signature.asc
Description: PGP signature
control: tag -1 + pending
Hello,
On Mon 09 Nov 2020 at 12:12PM +01, Mattia Rizzolo wrote:
> On Sat, Nov 07, 2020 at 01:01:28PM -0700, Sean Whitton wrote:
>> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
>> index 0d7a3e9..a21a510 100644
>
Hello,
On Mon 16 Nov 2020 at 04:12AM +01, Guillem Jover wrote:
> On Sat, 2020-11-07 at 13:30:13 -0700, Sean Whitton wrote:
>> Could I ask you to explain your wanting to reduce the Essential set for
>> the sake of small installation size in more detail, including some
>>
| Copyright 2009, 2005-2015 Angela Watts
>
> ?
The former. If you'd like to propose a patch making this clearer we
could get it applied.
--
Sean Whitton
0 into just 2009--2015, but I don't think we should
encourage combining 2009--2011 and 2013 into 2009--2013.
--
Sean Whitton
signature.asc
Description: PGP signature
please, for
seconding? See README.md in policy.git for more info.
--
Sean Whitton
signature.asc
Description: PGP signature
seful to be able to declare a
dependency and have it satisfied by one of these implementations?
So far this does not seem anything like, e.g., wanting to declare a
dependency on having the ability to programmatically send e-mail.
--
Sean Whitton
signature.asc
Description: PGP signature
could permit collapsing years just when the license does not have a
copyright notice reproduction requirement (see the changes in #955005
for another example of making Policy copyright notice requirements
conditional on particular licenses).
--
Sean Whitton
signature.asc
Description: PGP signature
don't think that's a particularly sensible
>> requirement.
>
> 'not fail' here means that the script terminates with return code 0.
This is how I would read it too. Would a patch to add "(i.e. exit with
return code 0)" resolve the original submitter's concerns?
--
Sean Whitton
signature.asc
Description: PGP signature
design was led by Niels
and Guillem). They were designing for the very long term, so I don't
think we can safely infer much from the present contents of the archive.
I'm also not really convinced by your arguments that having these other
possible values adds much of a burden. T
Hello,
On Tue 15 Dec 2020 at 06:02PM +01, Oxan van Leeuwen wrote:
> Hi,
>
> On 14-12-2020 22:43, Sean Whitton wrote:
>> On Mon 30 Nov 2020 at 07:49PM +01, Bill Allombert wrote:
>>> 'not fail' here means that the script terminates with return code 0.
>>
&g
Hello,
On Mon 14 Dec 2020 at 05:29PM -05, David Steele wrote:
> On Mon, Dec 14, 2020 at 3:48 PM Sean Whitton
> wrote:
>
>>
>>
>> Putting aside the use of the alternatives system, why is a virtual
>> package wanted? When would it be useful to be able to de
y want to specify that as one of the (or
the only?) requirements of the virtual package.
--
Sean Whitton
signature.asc
Description: PGP signature
that what is already there is invalid or unclear.
Please explain your motivations.
--
Sean Whitton
Hello,
On Tue 19 Jan 2021 at 04:19AM +01, Guillem Jover wrote:
> On Mon, 2021-01-18 at 18:25:55 -0700, Sean Whitton wrote:
>> On Thu 03 Dec 2020 at 05:08AM +03, Anatoli Babenia wrote:
>> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
>> > index edae8c1
version itself MUST be greater.
> --->8---
I don't think this text is clear enough -- Policy is about the contents
of packages, but it's phrased in terms of things which will happen -- it
refers to upgrades and to downgrades.
Could you try writing this in terms of what contents of packages must be
avoided in order to avoid the situations you describe?
Also, I think the thing about not supporting downgrades should be
somewhere too.
--
Sean Whitton
signature.asc
Description: PGP signature
part
and indicate that you are seeking seconds? Then we can get that
applied.
--
Sean Whitton
signature.asc
Description: PGP signature
ainer of the
Seconded, and I'll mark this bug as pending; if discussion on your other
issue gets to the point where wording is proposed, please clone this
bug.
--
Sean Whitton
signature.asc
Description: PGP signature
ing d/missing-sources
back and for rebasing the series -- now merged to 'next'.
--
Sean Whitton
signature.asc
Description: PGP signature
l package ``editor`` by including it in the
> ``Provides`` control field. The package providing the current default
Seconded.
--
Sean Whitton
signature.asc
Description: PGP signature
with making uploads to the Debian
archive (and we would not want to include the converse, that having such
a tight coupling implies you shouldn't include a Debian revision).
--
Sean Whitton
signature.asc
Description: PGP signature
> # 15 Feb 2019 Added logind
> # Added default-logind
> +#
> +# Russ Allbery:
> +# 01 Apr 2021 Added editor
> +# Added default-editor
Well, as you might guess, I prefer the "very hard" and "make use of"
wording, but nevertheless: seconded :) Thank you for the patch.
--
Sean Whitton
signature.asc
Description: PGP signature
that one too,
so I can apply both?
--
Sean Whitton
signature.asc
Description: PGP signature
rg/tags/uses-deprecated-adttmp
>
> I think autopkgtest.md should at least mention the new variable...
Thank you for this. I've committed a fix -- I just changed the variable
name rather than using your patch, if you don't mind, because it seemed
unnecessary to me to mention the old na
gt;every new upload (e.g. 1.3-0ubuntu1).
>
> * If the Debian package is backported to an older derivative and needs
>changes for it, add ~X to the debian_revision (e.g.
>1.2-3~bd1).
>
> Is the Debian policy the correct place to document that?
To be honest I'm not sure it is. What do you think about using a DEP
for this?
--
Sean Whitton
signature.asc
Description: PGP signature
not
> inherently apply to udebs. As I understand it, that's kind of the point
> of udebs.
Would you agree with this? You're only asking to stop seeing warnings
about S-V for source packages which produce only udebs?
--
Sean Whitton
signature.asc
Description: PGP signature
27;t. While the Lintian maintainers could decide to change
that, it's not been how the project has viewed Lintian in the past.
--
Sean Whitton
signature.asc
Description: PGP signature
control: clone -1 -2
control: reassign -2 debian-policy
control: retitle -2 Don't require Standards-Version field when only udebs
Hello,
On Thu 12 Aug 2021 at 11:47PM +02, Cyril Brulebois wrote:
> Sean Whitton (2021-08-12):
>> On Tue 27 Jul 2021 at 08:41AM -06, Sam
Package: debian-policy
[resending to submit@; can't clone merged bug]
Hello,
On Thu 12 Aug 2021 at 11:47PM +02, Cyril Brulebois wrote:
> Sean Whitton (2021-08-12):
>> On Tue 27 Jul 2021 at 08:41AM -06, Sam Hartman wrote:
>>
>> >
>> > So, it seems fairly o
in itself a bug.
Thus, the fact that there are a large number of incidences of
out-of-date-standards-version does not allow us to infer that anything
is wrong with the contents of the archive.
--
Sean Whitton
Debian release, so a Standards-Version older than the previous
Debian release is indicative of work (if only review work) that
needs doing.
and for most packages I *don't* want to review it more often than that.
So the tag is extremely useful to prompting me to look at something t
was
just intending to delay consideration of your arguments until after this
mistake has been undone, and we can have a proper discussion with input
from those who know more about udebs. I should have said this earlier,
so once again my apologies.
--
Sean Whitton
signature.asc
Description: PGP signature
was
just intending to delay consideration of your arguments until after this
mistake has been undone, and we can have a proper discussion with input
from those who know more about udebs. I should have said this earlier,
so once again my apologies.
--
Sean Whitton
if it takes a posting to d-d-a?
--
Sean Whitton
signature.asc
Description: PGP signature
buggy with this change. It was
thought to be just a clarification.
Russ, perhaps we should revert this?
--
Sean Whitton
signature.asc
Description: PGP signature
Hello Anatoli,
On Wed 18 Aug 2021 at 09:54AM +03, Anatoli Babenia wrote:
> My last comment is not addressed.
I'm afraid I still disagree with you about this.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello Bill,
On Tue 29 Jun 2021 at 11:13AM +02, Bill Allombert wrote:
> On Mon, Jun 28, 2021 at 03:20:04PM -0700, Sean Whitton wrote:
>> control: tag -1 + pending
>>
>> Hello Fabrice,
>>
>> On Mon 07 Jun 2021 at 11:53PM +02, Fabrice BAUZAC wrote:
>>
>&
Package: debian-policy
Version: 4.6.0.0
Tags: patch
X-debbugs-cc: Aurelien Jarno , debian-de...@lists.debian.org
On Wed 18 Aug 2021 at 02:10PM -07, Russ Allbery wrote:
> Sean Whitton writes:
>> On Wed 18 Aug 2021 at 11:10AM +02, Aurelien Jarno wrote:
>
>>> This path is us
sing this feature for the
sake of simplicity of understanding, so let's exclude that idea for now.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Fri 17 Sep 2021 at 06:24PM -04, Nicholas D Steeves wrote:
> Hi,
>
> Sean Whitton writes:
>
>> Hello,
>>
>> On Sun 25 Oct 2020 at 09:40PM -04, Joe Nahmias wrote:
>>
>>> Is this truly the case that all that's needed is a new patch? Can
he .dsc and as such end up in the Sources index. This is probably
> what we want anyway, but with all the people complaining about how big
> the index is getting it's something to consider. However it's also true
> that realistically very few packages are going to make use of
ter reducing any architecture-specific restrictions for
>> the build architecture in question, except when the later alternative
>> has the same package name as the first alternative. This is to improve
>> consistency between repeated builds of a package while still allowing
>> version ranges of the same package.
Can you turn this into a patch against our git repo, please?
--
Sean Whitton
signature.asc
Description: PGP signature
e.
Is there really no name for the first paragraph other than "general
paragraph"? Maybe "the source package's stanza"?
Also, how about "the text in this field describes all binary packages
which do not have their own Description: fields" ?
--
Sean Whitton
signature.asc
Description: PGP signature
self-contained: if you download
> all main or contrib source packages, that should give you the source
> code of all main and contrib binary packages.
I wonder if this idea that we want main+contrib to be self-contained
should be included in the text somehow? Or is it obvious?
--
Sean Whitton
signature.asc
Description: PGP signature
s are meant to be sent to d-devel, not just filed as a bug against
debian-policy, so perhaps you could do that and we'll give it a week,
then I'll go ahead and add these?
--
Sean Whitton
signature.asc
Description: PGP signature
control: tag -1 + pending
Hello Johannes,
On Sat 20 Nov 2021 at 10:52PM +01, Johannes Schauer Marin Rodrigues wrote:
> Hi Sean,
>
> Quoting Sean Whitton (2021-11-19 23:13:46)
>> Can you turn this into a patch against our git repo, please?
>
> maybe I'm looking at the w
diff.) The version of a
> +non-native package has an upstream component and a Debian component, and
> +there may be multiple Debian package versions associated with a single
> +upstream release version and sharing the same upstream source tar files.
> +
> +Most source packages in Debian are non
so need to be confident that making this
change in Policy would not render more than a few packages buggy.
--
Sean Whitton
signature.asc
Description: PGP signature
e requirement is only advisory based on how there is no
requirement on packages expressed must/should/etc. in the description of
Rules-Requires-Root: no in Policy. The target of the advice would be
authors and maintainers of package builders.
However, I missed the use of "required" in the text, which means there
is in fact a Policy requirement not to fail to build as non-root when
this field value is declared, I think?
Sorry for causing some confusion here.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello Guillem, Mattia,
On Fri 24 Dec 2021 at 01:42PM +01, Guillem Jover wrote:
> On Tue, 2021-12-21 at 17:53:31 -0700, Sean Whitton wrote:
>>
>> Is there really no name for the first paragraph other than "general
>> paragraph"?
>
> That's how the dp
7;t think we're requiring source packages
> to have descriptions. It may also be worth adding a paragraph explaining
> that source packages may have descriptions as well, but are not required
> to.
Right. I don't think we even want to recommend them at this point. I
would not like to put any pressure on maintainers to write them.
--
Sean Whitton
signature.asc
Description: PGP signature
dit how the source
> +distribution in Debian is derived from the upstream source.
> +
> +
> +Additionally, once documented in this manner, various tools such as
> +uscan or mk-origtargz can use
> +this information as instructions on how to automatically repack an
> +upstream source distribution into one suitable for use within Debian.
Nice.
--
Sean Whitton
control: tag -1 + pending
Hello,
On Sat 29 Jan 2022 at 08:24PM GMT, Simon McVittie wrote:
> On Thu, 23 Dec 2021 at 21:26:53 -0700, Sean Whitton wrote:
>> On Fri 29 Oct 2021 at 11:12AM +01, Simon McVittie wrote:
>> > it seems like a good time to introduce {default-,}dbus-syste
actual use):
>
> mir-demos: /usr/share/wayland-sessions/mir-shell.desktop
Seems fine. Just to confirm, the primary use case is so that if a
package providing wayland-session is installed, a display manager like
gdm3 won't try to install GNOME?
--
Sean Whitton
signature.asc
Description: PGP signature
ight have a hard time
figuring out what to use, unless they happen to stumble across the
discussion in this bug.
What do you think about adding a condensed version of your reasoning to
the Policy Manual somewhere?
--
Sean Whitton
licy without destroying existing references to chapter numbers?
Please go ahead and write a patch. The Policy Editors are happy to
review and edit proposed wording but we can't be responsible for
producing all of the text that gets added to Policy.
--
Sean Whitton
this in a second
> change. I think the second change also needs the base-passwd people in
> the loop.
The latter, please, assuming I'm not misunderstanding and the first
change makes things worse on the reproducibility front.
--
Sean Whitton
signature.asc
Description: PGP signature
the previous release cycle, I have split the mime-support into the
> media-types and the mailcap packages.
>
> The patch below updates the Policy to reflect that.
This is technically a normative change but since the change has already
been made in the archive, I've just gone ahead
ckage format MBF.
--
Sean Whitton
ragraph" is for prose.
--
Sean Whitton
signature.asc
Description: PGP signature
n of "stanza" in a footnote to mention it's a common alias or
> similar.
Hmm, I see.
> So, personally, I'd be happy to fully switch to stanza TBH, because it
> seems more specific to our use, probably easier to search for, and
> it's shorter.
I think
501 - 600 of 727 matches
Mail list logo
