control: tag -1 + pending
Hello,
On Thu 01 Apr 2021 at 10:44AM -07, Russ Allbery wrote:
> Russ Allbery writes:
>
>> In attempting to revise recent GRs to use the same terminology as
>> Policy, I got frustrated again by the lack of precision of our current
>> language. This is an attempt to mak
> "Russ" == Russ Allbery writes:
Russ> Russ Allbery writes:
>> In attempting to revise recent GRs to use the same terminology as
>> Policy, I got frustrated again by the lack of precision of our
>> current language. This is an attempt to make a minor
>> improvement. It
Russ Allbery writes:
> In attempting to revise recent GRs to use the same terminology as
> Policy, I got frustrated again by the lack of precision of our current
> language. This is an attempt to make a minor improvement. It doesn't
> go all the way to using all-caps terms the way that RFC 2119
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 keywords in bold wouldn't have this proble
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 keywords in bold wouldn't have this problem, and
> maybe it would actually make it /easier/ to write patches beca
Hello Guillem,
On Thu 30 Jan 2020 at 01:16AM +01, Guillem Jover wrote:
> Some of the words chosen to convey normative meaning are glue words
> used to build pretty mundane sentences, so having them appear around
> while they might not convey normative meaning seems rather confusing,
> and is a me
On Wed, 2020-01-29 at 14:42:08 -0700, Sean Whitton wrote:
> On Sun 26 Jan 2020 at 03:48AM +01, Guillem Jover wrote:
> > I think one of the nice things about RFC2119 is that it uses uppercase
> > versions for the normative keywords, so that these are very clearly
> > distinguished both when writing
Hello,
On Sun 26 Jan 2020 at 03:48AM +01, Guillem Jover wrote:
> I think one of the nice things about RFC2119 is that it uses uppercase
> versions for the normative keywords, so that these are very clearly
> distinguished both when writing and readin, from sentences that may
> use some of the com
On Fri, 2020-01-03 at 20:43:14 -0800, Russ Allbery wrote:
> Russ Allbery writes:
> > I agree, but let's also fix existing incorrect wording. I reviewed
> > every instance of may and optional in Policy, and I think this larger
> > diff will make wording (mostly) consistent. I've tried not to chan
Hello,
On Fri 03 Jan 2020 at 08:43PM -08, Russ Allbery wrote:
> Russ Allbery writes:
>
>> I agree, but let's also fix existing incorrect wording. I reviewed
>> every instance of may and optional in Policy, and I think this larger
>> diff will make wording (mostly) consistent. I've tried not to
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 the ``sysvinit`` package may do
>
Sam Hartman writes:
> One question:
> +The Release Team may, at their discretion, downgrade a Policy requirement
> +to a Policy recommendation for a given release of the Debian distribution.
> +This may be done for only a specific package or for the archive as a
> +whole. This provision is inten
Russ, I've reviewed your new patch.
I haven't been participating in this discussion before, but I think it
is fair to say that I have significant experience with these sorts of
normative language discussions and Debian policy in general.
I agree with all your changes (with one question below).
My
Sean Whitton writes:
> Let's definitely reconsider those 'must' requirements in response to
> this work, but let's not commit ourselves to the idea that it's always a
> bug for the Release Team's conception of an RC bug, and Policy 'must'
> requirements, to disagree.
> The Release Team's concept
Russ Allbery writes:
> I agree, but let's also fix existing incorrect wording. I reviewed
> every instance of may and optional in Policy, and I think this larger
> diff will make wording (mostly) consistent. I've tried not to change
> the sense of any of these Policy statements (even though a f
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 the ``sysvinit`` package may do
>> -so.)
>> +themselves in the archive either. (Only the ``init-system-
Hello,
On Sun 29 Dec 2019 at 11:20am -08, Russ Allbery wrote:
> Paul Gevers writes:
>> On 21-11-2019 13:59, Paul Gevers wrote:
>
>>> [Disclaimer: the words below are as a member of the release team, but
>>> not necessarily those of the team. We haven't discussed this yet.]
>
>> We have had a dis
Paul Gevers writes:
> On 21-11-2019 13:59, Paul Gevers wrote:
>> [Disclaimer: the words below are as a member of the release team, but
>> not necessarily those of the team. We haven't discussed this yet.]
> We have had a discussion, and there were no objections against my vision
> below.
>> I c
Dear Policy Editors,
On 21-11-2019 13:59, Paul Gevers wrote:
> [Disclaimer: the words below are as a member of the release team, but
> not necessarily those of the team. We haven't discussed this yet.]
We have had a discussion, and there were no objections against my vision
below.
> I can envisi
Dear Russ,
[Disclaimer: the words below are as a member of the release team, but
not necessarily those of the team. We haven't discussed this yet.]
On 17-11-2019 20:47, Russ Allbery wrote:
> Let me copy the release team. How would you all prefer to handle the
> relationship between release-criti
Hello,
On Mon 18 Nov 2019 at 05:34PM -08, Russ Allbery wrote:
> Yeah, that was my thought process, but I did totally break my own rule. I
> can break this out into a separate change if that makes more sense. I was
> trying to reword the sentence to avoid using "no ... may" and trying to
> keep
David Bremner writes:
> Sean Whitton writes:
>>> -No package for a 64 bit architecture may install files in
>>> -``/usr/lib64/`` or in a subdirectory of it.
>>> +Packages must not install files in ``/usr/lib64`` or in a subdirectory
>>> +of it.
>>
>> This seems to be a semantic c
Sean Whitton writes:
>
>> -No package for a 64 bit architecture may install files in
>> -``/usr/lib64/`` or in a subdirectory of it.
>> +Packages must not install files in ``/usr/lib64`` or in a subdirectory
>> +of it.
>
> This seems to be a semantic change, generalising the requi
Hello,
On Sun 17 Nov 2019 at 05:48PM -08, Russ Allbery wrote:
> I agree, but let's also fix existing incorrect wording. I reviewed every
> instance of may and optional in Policy, and I think this larger diff will
> make wording (mostly) consistent. I've tried not to change the sense of
> any of
Sean Whitton writes:
> On Sun 17 Nov 2019 at 10:10AM -08, Russ Allbery wrote:
>> +* The term *may* and the adjective *optional* are sometimes used to
>> + clarify cases where it may otherwise appear that Policy is specifying a
>> + requirement or recommendation. These words describe decisions t
Hello Russ,
Thanks for this.
On Sun 17 Nov 2019 at 10:10AM -08, Russ Allbery wrote:
> +* The term *may* and the adjective *optional* are sometimes used to
> + clarify cases where it may otherwise appear that Policy is specifying a
> + requirement or recommendation. These words describe decisio
Bastian Blank writes:
> On Sun, Nov 17, 2019 at 10:10:11AM -0800, Russ Allbery wrote:
>> +The Release Team may, at their discretion, downgrade a Policy requirement
>> +to a Policy recommendation for a given release of the Debian distribution.
>> +This may be done for only a specific package or fo
On Sun, Nov 17, 2019 at 10:10:11AM -0800, Russ Allbery wrote:
> +The Release Team may, at their discretion, downgrade a Policy requirement
> +to a Policy recommendation for a given release of the Debian distribution.
> +This may be done for only a specific package or for the archive as a
> +whole.
On Sun, Nov 17, 2019 at 10:10:11AM -0800, Russ Allbery wrote:
> Changes:
>
> * Add "prohibited" to the terms for requirements
> * Add another tier (Policy advice) using encouraged and discouraged
> * Stop confusing may and optional with wishlist bugs
> * Add terms for the collective set of Policy
Package: debian-policy
Version: 4.4.1.1
Severity: normal
In attempting to revise recent GRs to use the same terminology as
Policy, I got frustrated again by the lack of precision of our current
language. This is an attempt to make a minor improvement. It doesn't
go all the way to using all-caps
30 matches
Mail list logo
