[gentoo-dev] Deleting old news items

[gentoo-dev] Deleting old news items

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]

Problem:

New stages have numerous news items listed that are likely not relevant,
but are shown due to limitations in the filtering in NEWS items. E.g. on a
recent stage3:

nspawntest / # eselect news list
News items:
  [1]   N  2013-09-27  Separate /usr on Linux requires initramfs
  [2]   N  2014-06-15  GCC 4.8.3 defaults to -fstack-protector
  [3]   N  2014-10-26  GCC 4.7 Introduced the New C++11 ABI
  [4]   N  2015-02-02  New portage plug-in sync system
  [5]   N  2015-07-25  Python 3.4 enabled by default
  [6]   N  2015-08-13  OpenSSH 7.0 disables ssh-dss keys by default
  [7]   N  2015-10-22  GCC 5 Defaults to the New C++11 ABI
  [8]   N  2016-06-19  L10N USE_EXPAND variable replacing LINGUAS
  [9]   N  2017-11-30  New 17.0 profiles in the Gentoo repository

Many of these are always displayed. For example:

https://gitweb.gentoo.org/data/gentoo-news.git/tree/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt

has "Display-If-Installed: sys-apps/portage" and will be displayed on
nearly every Gentoo machine. While relevant in 2015; I'm skeptical that its
relevant today. I am also considering explicit changes in the filtering
directives to resolve this in the future.

Glep42 states:

---
News Item Removal

News items can be removed (by removing the news file from the main tree)
when they are no longer relevant, if they are made obsolete by a future
news item or after a long period of time. This is the same as the method
used for updates entries.
---

I suggest we delete all entries prior to 2016. Git keeps history forever,
so folks can gander at the old entries on gitweb.gentoo.org:

https://gitweb.gentoo.org/data/gentoo-news.git/tree/

-A

[-- Attachment #2: Type: text/html, Size: 2406 bytes --]

Re: [gentoo-dev] Deleting old news items

[Mikle Kolyada]

[-- Attachment #1: Type: text/plain, Size: 71 bytes --]

+1

There is also https://www.gentoo.org/support/news-items/ if needed

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 313 bytes --]

Re: [gentoo-dev] Deleting old news items

[Aaron W. Swenson]

[-- Attachment #1: Type: text/plain, Size: 3 bytes --]

+1

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 376 bytes --]

[gentoo-dev] Re: Deleting old news items

[Michael Palimaka]

On 01/03/2018 11:13 AM, Alec Warner wrote:
> Problem:
> 
> New stages have numerous news items listed that are likely not relevant,
> but are shown due to limitations in the filtering in NEWS items. E.g. on
> a recent stage3:
> 
> nspawntest / # eselect news list
> News items:
>   [1]   N  2013-09-27  Separate /usr on Linux requires initramfs
>   [2]   N  2014-06-15  GCC 4.8.3 defaults to -fstack-protector
>   [3]   N  2014-10-26  GCC 4.7 Introduced the New C++11 ABI 
>   [4]   N  2015-02-02  New portage plug-in sync system
>   [5]   N  2015-07-25  Python 3.4 enabled by default
>   [6]   N  2015-08-13  OpenSSH 7.0 disables ssh-dss keys by default
>   [7]   N  2015-10-22  GCC 5 Defaults to the New C++11 ABI
>   [8]   N  2016-06-19  L10N USE_EXPAND variable replacing LINGUAS
>   [9]   N  2017-11-30  New 17.0 profiles in the Gentoo repository
> 
> Many of these are always displayed. For example:
> 
> https://gitweb.gentoo.org/data/gentoo-news.git/tree/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt
> 
> has "Display-If-Installed: sys-apps/portage" and will be displayed on
> nearly every Gentoo machine. While relevant in 2015; I'm skeptical that
> its relevant today. I am also considering explicit changes in the
> filtering directives to resolve this in the future.
> 
> Glep42 states:
> 
> ---
> News Item Removal
> 
> News items can be removed (by removing the news file from the main tree)
> when they are no longer relevant, if they are made obsolete by a future
> news item or after a long period of time. This is the same as the method
> used for updates entries.
> ---
> 
> I suggest we delete all entries prior to 2016. Git keeps history
> forever, so folks can gander at the old entries on gitweb.gentoo.org
> <http://gitweb.gentoo.org>:
> 
> https://gitweb.gentoo.org/data/gentoo-news.git/tree/
> 
> -A

I strongly support this idea. I've tried to push this several times in
the past however was met with some resistance from several teams.

Re: [gentoo-dev] Deleting old news items

[Michał Górny]

W dniu wto, 02.01.2018 o godzinie 19∶13 -0500, użytkownik Alec Warner
napisał:
> Problem:
> 
> New stages have numerous news items listed that are likely not relevant,
> but are shown due to limitations in the filtering in NEWS items. E.g. on a
> recent stage3:
> 
> nspawntest / # eselect news list
> News items:
>   [1]   N  2013-09-27  Separate /usr on Linux requires initramfs
>   [2]   N  2014-06-15  GCC 4.8.3 defaults to -fstack-protector
>   [3]   N  2014-10-26  GCC 4.7 Introduced the New C++11 ABI
>   [4]   N  2015-02-02  New portage plug-in sync system
>   [5]   N  2015-07-25  Python 3.4 enabled by default
>   [6]   N  2015-08-13  OpenSSH 7.0 disables ssh-dss keys by default
>   [7]   N  2015-10-22  GCC 5 Defaults to the New C++11 ABI
>   [8]   N  2016-06-19  L10N USE_EXPAND variable replacing LINGUAS
>   [9]   N  2017-11-30  New 17.0 profiles in the Gentoo repository
> 
> Many of these are always displayed. For example:
> 
> https://gitweb.gentoo.org/data/gentoo-news.git/tree/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt
> 
> has "Display-If-Installed: sys-apps/portage" and will be displayed on
> nearly every Gentoo machine. While relevant in 2015; I'm skeptical that its
> relevant today. I am also considering explicit changes in the filtering
> directives to resolve this in the future.
> 
> Glep42 states:
> 
> ---
> News Item Removal
> 
> News items can be removed (by removing the news file from the main tree)
> when they are no longer relevant, if they are made obsolete by a future
> news item or after a long period of time. This is the same as the method
> used for updates entries.
> ---
> 
> I suggest we delete all entries prior to 2016. Git keeps history forever,
> so folks can gander at the old entries on gitweb.gentoo.org:
> 

For completeness, I should point out that I've seen one user complaining
about old news items disappearing. While I support the motion, I think
we should take some care to make sure that there is some 'replacement'
documentation for the things announced by news items.

In other words, it's a bad idea to remove news items when the available
documentation explains the 'before' state and the news item is the only
source of information of the 'after' state.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Deleting old news items

[kuzetsa]

[-- Attachment #1.1: Type: text/plain, Size: 3278 bytes --]

On 01/03/2018 05:53 AM, Michał Górny wrote:
> W dniu wto, 02.01.2018 o godzinie 19∶13 -0500, użytkownik Alec Warner
> napisał:
>> Problem:
>>
>> New stages have numerous news items listed that are likely not relevant,
>> but are shown due to limitations in the filtering in NEWS items. E.g. on a
>> recent stage3:
>>
>> nspawntest / # eselect news list
>> News items:
>>   [1]   N  2013-09-27  Separate /usr on Linux requires initramfs
>>   [2]   N  2014-06-15  GCC 4.8.3 defaults to -fstack-protector
>>   [3]   N  2014-10-26  GCC 4.7 Introduced the New C++11 ABI
>>   [4]   N  2015-02-02  New portage plug-in sync system
>>   [5]   N  2015-07-25  Python 3.4 enabled by default
>>   [6]   N  2015-08-13  OpenSSH 7.0 disables ssh-dss keys by default
>>   [7]   N  2015-10-22  GCC 5 Defaults to the New C++11 ABI
>>   [8]   N  2016-06-19  L10N USE_EXPAND variable replacing LINGUAS
>>   [9]   N  2017-11-30  New 17.0 profiles in the Gentoo repository
>>
>> Many of these are always displayed. For example:
>>
>> https://gitweb.gentoo.org/data/gentoo-news.git/tree/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt
>>
>> has "Display-If-Installed: sys-apps/portage" and will be displayed on
>> nearly every Gentoo machine. While relevant in 2015; I'm skeptical that its
>> relevant today. I am also considering explicit changes in the filtering
>> directives to resolve this in the future.
>>
>> Glep42 states:
>>
>> ---
>> News Item Removal
>>
>> News items can be removed (by removing the news file from the main tree)
>> when they are no longer relevant, if they are made obsolete by a future
>> news item or after a long period of time. This is the same as the method
>> used for updates entries.
>> ---
>>
>> I suggest we delete all entries prior to 2016. Git keeps history forever,
>> so folks can gander at the old entries on gitweb.gentoo.org:
>>
> For completeness, I should point out that I've seen one user complaining
> about old news items disappearing. While I support the motion, I think
> we should take some care to make sure that there is some 'replacement'
> documentation for the things announced by news items.
>
> In other words, it's a bad idea to remove news items when the available
> documentation explains the 'before' state and the news item is the only
> source of information of the 'after' state.
>

I've personally needed to refer back to a few of those news
entries more than once. In particular, the instructions for
17.0 profile migration, the entry about -fstack-protector,
C++11 ABI notices, and the portage sync plugin system.

The most recent time I needed some of that was this week.

Following a mix-up with crossdev (still documenting the bug)
I decided to repair my toolchain in-place using a stage3
tarball rather than a full OS reinstall. Specifically, the
info was handy because there isn't much documentation on
how to correctly bootstrap from anything less than a
valid / non-broke stage3 tarball.

Even if nobody else has weird issues and needs to use a
strange method to repair their system in-place, the 17.0
profile migration news entry is recent enough that it
should be retained for at least a FULL YEAR, I feel.

- kuza


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Deleting old news items

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

>>>>> On Tue, 2 Jan 2018, Alec Warner wrote:

> Problem:
> New stages have numerous news items listed that are likely not
> relevant, but are shown due to limitations in the filtering in NEWS
> items. E.g. on a recent stage3:

> [...]

We could add an "Expires:" header to the news item format, and the
package manager (or eselect news) could mask old items based on it.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Deleting old news items

[kuzetsa]

[-- Attachment #1.1: Type: text/plain, Size: 664 bytes --]

On 01/03/2018 06:07 AM, Ulrich Mueller wrote:
>>>>>> On Tue, 2 Jan 2018, Alec Warner wrote:
>> Problem:
>> New stages have numerous news items listed that are likely not
>> relevant, but are shown due to limitations in the filtering in NEWS
>> items. E.g. on a recent stage3:
>> [...]
> We could add an "Expires:" header to the news item format, and the
> package manager (or eselect news) could mask old items based on it.
>
> Ulrich

the storage footprint for news entries is cheap.

why not just improve the user-facing documentation:
if someone wants to hide "old" news, they opt-out.

It's much harder to opt-in to viewing deleted news.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Deleting old news items

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 944 bytes --]

On 01/03/2018 12:07 PM, Ulrich Mueller wrote:
>>>>>> On Tue, 2 Jan 2018, Alec Warner wrote:
> 
>> Problem:
>> New stages have numerous news items listed that are likely not
>> relevant, but are shown due to limitations in the filtering in NEWS
>> items. E.g. on a recent stage3:
> 
>> [...]
> 
> We could add an "Expires:" header to the news item format, and the
> package manager (or eselect news) could mask old items based on it.

Do we necessarily need to do even that? A package manager could have a
feature to mask based on other heuristics without changing the format,
e.g all messages from before X, presumably with a switch to show older.

I'm thinking along the lines of only show those published within last 12
months by default, configurable by make.conf variable.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Deleting old news items

[Ciaran McCreesh]

On Wed, 3 Jan 2018 12:23:33 +0100
Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> Do we necessarily need to do even that? A package manager could have a
> feature to mask based on other heuristics without changing the format,
> e.g all messages from before X, presumably with a switch to show

Package manglers having to use heuristics when explicit information
could easily be provided by developers but isn't is the source of at
least 27.4% of Gentoo's problems.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Deleting old news items

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 873 bytes --]

On 01/03/2018 02:45 PM, Ciaran McCreesh wrote:
> On Wed, 3 Jan 2018 12:23:33 +0100
> Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>> Do we necessarily need to do even that? A package manager could have a
>> feature to mask based on other heuristics without changing the format,
>> e.g all messages from before X, presumably with a switch to show
> Package manglers having to use heuristics when explicit information
> could easily be provided by developers but isn't is the source of at
> least 27.4% of Gentoo's problems.

I'd say it is easier to have flexibility for user to decide than a
developer trying to estimate the value of the information for setting an
expiration date, as that is context dependent.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Deleting old news items

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1216 bytes --]

On 01/03/2018 03:13 PM, Kristian Fiskerstrand wrote:
> On 01/03/2018 02:45 PM, Ciaran McCreesh wrote:
>> On Wed, 3 Jan 2018 12:23:33 +0100
>> Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>>> Do we necessarily need to do even that? A package manager could have a
>>> feature to mask based on other heuristics without changing the format,
>>> e.g all messages from before X, presumably with a switch to show
>> Package manglers having to use heuristics when explicit information
>> could easily be provided by developers but isn't is the source of at
>> least 27.4% of Gentoo's problems.
> 
> I'd say it is easier to have flexibility for user to decide than a
> developer trying to estimate the value of the information for setting an
> expiration date, as that is context dependent.
> 

That said, I'd prefer either option over deleting news items, deleting
info shouldn't be necessary to begin with, it'd be more interesting to
have an "active" boolean or something, but still keep the info (but I'd
still say a PM filter based on date is better)

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Deleting old news items

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

On Wed, Jan 3, 2018 at 6:07 AM, Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Tue, 2 Jan 2018, Alec Warner wrote:
>
> > Problem:
> > New stages have numerous news items listed that are likely not
> > relevant, but are shown due to limitations in the filtering in NEWS
> > items. E.g. on a recent stage3:
>
> > [...]
>
> We could add an "Expires:" header to the news item format, and the
> package manager (or eselect news) could mask old items based on it.
>

Ok, I'll submit a patch to the GLEP for this. Stay tuned.

-A


>
> Ulrich
>

[-- Attachment #2: Type: text/html, Size: 1173 bytes --]

Re: [gentoo-dev] Deleting old news items

[Alec Warner]

[-- Attachment #1.1: Type: text/plain, Size: 1161 bytes --]

The attached patch proposes a new news item format (2.1).

In format 2.1, the Expires: header is mandatory.

PMs can detect whether a given news item is "expired" by comparing the
current date in UTC to the expired date.
Expired news items should not be shown to users.

Once this is accepted and implemented, we can go back and bump the existing
news items to format 2.1 and add the new mandatory header.

Old news implementations should ignore the "Expires" header (as they ignore
any unspecified header.)



On Wed, Jan 3, 2018 at 10:16 AM, Alec Warner <antarus@gentoo.org> wrote:

>
>
> On Wed, Jan 3, 2018 at 6:07 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
>> >>>>> On Tue, 2 Jan 2018, Alec Warner wrote:
>>
>> > Problem:
>> > New stages have numerous news items listed that are likely not
>> > relevant, but are shown due to limitations in the filtering in NEWS
>> > items. E.g. on a recent stage3:
>>
>> > [...]
>>
>> We could add an "Expires:" header to the news item format, and the
>> package manager (or eselect news) could mask old items based on it.
>>
>
> Ok, I'll submit a patch to the GLEP for this. Stay tuned.
>
> -A
>
>
>>
>> Ulrich
>>
>
>

[-- Attachment #1.2: Type: text/html, Size: 2240 bytes --]

[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 1747 bytes --]

diff --git a/glep-0042.rst b/glep-0042.rst
index 416bd18..dc2d77f 100644
--- a/glep-0042.rst
+++ b/glep-0042.rst
@@ -9,10 +9,10 @@ Type: Standards Track
 Status: Final
 Version: 4
 Created: 2005-10-31
-Last-Modified: 2017-11-29
+Last-Modified: 2018-01-04
 Post-History: 2005-11-01, 2005-11-05, 2005-11-07, 2005-12-11, 2005-12-13,
               2005-12-18, 2006-01-05, 2006-03-02, 2006-03-06, 2006-06-12,
-              2006-09-05, 2016-03-10, 2017-11-27
+              2006-09-05, 2016-03-10, 2017-11-27, 2018-01-04
 Content-Type: text/x-rst
 ---
 
@@ -247,11 +247,20 @@ The following headers describe the purpose and format of the news item:
     item. Mandatory.
 
 ``News-Item-Format:``
-    Known formats are ``1.0`` and ``2.0``.  Future revisions to the format
-    may increment the minor number for forwards-compatible changes (i.e.,
-    still allowing older tools to process the new format), or the major
+    Known formats are ``1.0``, ``2.0``, and ``2.1``.  Future revisions to the
+    format may increment the minor number for forwards-compatible changes
+    (i.e., still allowing older tools to process the new format), or the major
     number for major changes.
 
+  ``Expires:``
+    Date of expiration, in ``yyyy-mm-dd`` format (e.g. 2005-12-18) for
+    compatability with GLEP 45 [#glep-45]_. Translations should use the date of
+    the original news item. An item is expired if the current date in UTC is
+    greater than the expiration date of the item. Package manages should not
+    display expired items. In news item format ``>2.0``, this field is
+    mandatory. This field did not exist in formats ``<=2.0`` and is optional
+    there.
+
 The following headers are used for filtering:
 
 ``Display-If-Installed:``

Re: [gentoo-dev] Deleting old news items

[Alec Warner]

[-- Attachment #1.1: Type: text/plain, Size: 1484 bytes --]

On Thu, Jan 4, 2018 at 8:20 PM, Alec Warner <antarus@gentoo.org> wrote:

> The attached patch proposes a new news item format (2.1).
>
> In format 2.1, the Expires: header is mandatory.
>
> PMs can detect whether a given news item is "expired" by comparing the
> current date in UTC to the expired date.
> Expired news items should not be shown to users.
>

Brief amendment. In the case where the PM cannot parse the expires header;
it should assume the item is not expired and display it (e.g. it should
fail open.)

Updated patch attached.

-A


>
> Once this is accepted and implemented, we can go back and bump the
> existing news items to format 2.1 and add the new mandatory header.
>
> Old news implementations should ignore the "Expires" header (as they
> ignore any unspecified header.)
>
>
>
> On Wed, Jan 3, 2018 at 10:16 AM, Alec Warner <antarus@gentoo.org> wrote:
>
>>
>>
>> On Wed, Jan 3, 2018 at 6:07 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>
>>> >>>>> On Tue, 2 Jan 2018, Alec Warner wrote:
>>>
>>> > Problem:
>>> > New stages have numerous news items listed that are likely not
>>> > relevant, but are shown due to limitations in the filtering in NEWS
>>> > items. E.g. on a recent stage3:
>>>
>>> > [...]
>>>
>>> We could add an "Expires:" header to the news item format, and the
>>> package manager (or eselect news) could mask old items based on it.
>>>
>>
>> Ok, I'll submit a patch to the GLEP for this. Stay tuned.
>>
>> -A
>>
>>
>>>
>>> Ulrich
>>>
>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 3082 bytes --]

[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 1876 bytes --]

diff --git a/glep-0042.rst b/glep-0042.rst
index 416bd18..e6a639e 100644
--- a/glep-0042.rst
+++ b/glep-0042.rst
@@ -9,10 +9,10 @@ Type: Standards Track
 Status: Final
 Version: 4
 Created: 2005-10-31
-Last-Modified: 2017-11-29
+Last-Modified: 2018-01-04
 Post-History: 2005-11-01, 2005-11-05, 2005-11-07, 2005-12-11, 2005-12-13,
               2005-12-18, 2006-01-05, 2006-03-02, 2006-03-06, 2006-06-12,
-              2006-09-05, 2016-03-10, 2017-11-27
+              2006-09-05, 2016-03-10, 2017-11-27, 2018-01-04
 Content-Type: text/x-rst
 ---
 
@@ -247,11 +247,21 @@ The following headers describe the purpose and format of the news item:
     item. Mandatory.
 
 ``News-Item-Format:``
-    Known formats are ``1.0`` and ``2.0``.  Future revisions to the format
-    may increment the minor number for forwards-compatible changes (i.e.,
-    still allowing older tools to process the new format), or the major
+    Known formats are ``1.0``, ``2.0``, and ``2.1``.  Future revisions to the
+    format may increment the minor number for forwards-compatible changes
+    (i.e., still allowing older tools to process the new format), or the major
     number for major changes.
 
+  ``Expires:``
+    Date of expiration, in ``yyyy-mm-dd`` format (e.g. 2005-12-18) for
+    compatability with GLEP 45 [#glep-45]_. Translations should use the date of
+    the original news item. An item is expired if the current date in UTC is
+    greater than the expiration date of the item. Package manages should not
+    display expired items. In the event where the Expires: header not readily
+    converted to a date, package managers should assume items are unexpired.
+    In news item format ``>2.0``, this field is mandatory. This field did not
+    exist in formats ``<=2.0`` and is optional there.
+
 The following headers are used for filtering:
 
 ``Display-If-Installed:``

Re: [gentoo-dev] Deleting old news items

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

>>>>> On Thu, 4 Jan 2018, Alec Warner wrote:

> Brief amendment. In the case where the PM cannot parse the expires header; it
> should assume the item is not expired and display it (e.g. it should fail
> open.)

> Updated patch attached.

> +  ``Expires:``
> +    Date of expiration, in ``yyyy-mm-dd`` format (e.g. 2005-12-18) for

This is only an example, but choosing a date from 2005 looks strange.

> +    compatability with GLEP 45 [#glep-45]_. Translations should use the date of
> +    the original news item. An item is expired if the current date in UTC is
> +    greater than the expiration date of the item. Package manages should not
> +    display expired items. In the event where the Expires: header not readily
> +    converted to a date, package managers should assume items are unexpired.

I would strike that last sentence. The GLEP already says "tools
handling these news items must ignore any unrecognised header" which
implicitly covers it.

Also, if we would want to specify more explicitly how to deal with
invalid header syntax, then there should be a general section or
paragraph about that.

> +    In news item format ``>2.0``, this field is mandatory.

I think it should not be mandatory, for the purpose of the tools
dealing with news items. So I'd simply say here: "Only in news item
format 2.1 or later."

>                                                             This field did not
> +    exist in formats ``<=2.0`` and is optional there.

Strike this sentence. If we say "only in format 2.1" above, then it is
clear that it didn't exist before.

In addition, in the paragraphs for the "Display-If-*" headers, the 2.0
need to be updated to something like "2.0 or later" or "2.*".

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Deleting old news items

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]

On Fri, Jan 5, 2018 at 5:08 AM, Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Thu, 4 Jan 2018, Alec Warner wrote:
>
> > Brief amendment. In the case where the PM cannot parse the expires
> header; it
> > should assume the item is not expired and display it (e.g. it should fail
> > open.)
>
> > Updated patch attached.
>
> > +  ``Expires:``
> > +    Date of expiration, in ``yyyy-mm-dd`` format (e.g. 2005-12-18) for
>
> This is only an example, but choosing a date from 2005 looks strange.
>
> > +    compatability with GLEP 45 [#glep-45]_. Translations should use the
> date of
> > +    the original news item. An item is expired if the current date in
> UTC is
> > +    greater than the expiration date of the item. Package manages
> should not
> > +    display expired items. In the event where the Expires: header not
> readily
> > +    converted to a date, package managers should assume items are
> unexpired.
>
> I would strike that last sentence. The GLEP already says "tools
> handling these news items must ignore any unrecognised header" which
> implicitly covers it.
>

I wrote a lot more because I also wrote the patches to portage and things
were unclear to me.
For example when I read the spec "unrecognized header" to me meant the
header name only;
I'll add some extra words to clarify that invalid values are the same as
invalid header names.



> Also, if we would want to specify more explicitly how to deal with
> invalid header syntax, then there should be a general section or
> paragraph about that.
>

Ack, I've modified the unrecognised header section to clarify this a bit.


>
> > +    In news item format ``>2.0``, this field is mandatory.
>
> I think it should not be mandatory, for the purpose of the tools
> dealing with news items. So I'd simply say here: "Only in news item
> format 2.1 or later."
>

My concern is that if it isn't mandatory; we will end up with the same
problem.

No one will set expiry headers on their items and we will be forced to go
back and update old news items to add them once
there are too many items (today's state.)

Alternatively we could simply state amend the glep to have a default expiry
(say 3y) and if no expires header is present we consume the Posted header
for this purpose.


> >                                                             This field
> did not
> > +    exist in formats ``<=2.0`` and is optional there.
>
> Strike this sentence. If we say "only in format 2.1" above, then it is
> clear that it didn't exist before.
>
> In addition, in the paragraphs for the "Display-If-*" headers, the 2.0
> need to be updated to something like "2.0 or later" or "2.*".
>

Ack, done.


>
> Ulrich
>

[-- Attachment #2: Type: text/html, Size: 4075 bytes --]

Re: [gentoo-dev] Deleting old news items

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

On Fri, Jan 05, 2018 at 09:01:26AM -0500, Alec Warner wrote:
> On Fri, Jan 5, 2018 at 5:08 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
> > > +    In news item format ``>2.0``, this field is mandatory.
> >
> > I think it should not be mandatory, for the purpose of the tools
> > dealing with news items. So I'd simply say here: "Only in news item
> > format 2.1 or later."
> >
> 
> My concern is that if it isn't mandatory; we will end up with the same
> problem.
> 
> No one will set expiry headers on their items and we will be forced to go
> back and update old news items to add them once
> there are too many items (today's state.)
> 
> Alternatively we could simply state amend the glep to have a default expiry
> (say 3y) and if no expires header is present we consume the Posted header
> for this purpose.

If we have a default expiration, it should be one year after the date
posted to go along with our current policy of not supporting things that
are older than a year.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Deleting old news items

[Aaron W. Swenson]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

On 2018-01-05 15:16, William Hubbs wrote:
> If we have a default expiration, it should be one year after the date
> posted to go along with our current policy of not supporting things that
> are older than a year.
> 
> William

I thought it was three years.

At any rate, I think a year is too short.

How about 18 months?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 376 bytes --]

Re: [gentoo-dev] Deleting old news items

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 940 bytes --]

On 01/05/2018 10:28 PM, Aaron W. Swenson wrote:
> On 2018-01-05 15:16, William Hubbs wrote:
>> If we have a default expiration, it should be one year after the date
>> posted to go along with our current policy of not supporting things that
>> are older than a year.
>>
>> William
> 
> I thought it was three years.
> 
> At any rate, I think a year is too short.
> 
> How about 18 months?
> 

I might sound like a broken CD here, but why define the expiration as
part of the news format instead of specifying it in the package manager
as a user defined variable? Various use cases requires different
treatment, so leaving it up to user seems more relevant to me, and we
could allow information to be presented as part of stages to give a hint
for what dates to look for?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Deleting old news items

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]

On Fri, Jan 5, 2018 at 5:09 PM, Kristian Fiskerstrand <k_f@gentoo.org>
wrote:

> On 01/05/2018 10:28 PM, Aaron W. Swenson wrote:
> > On 2018-01-05 15:16, William Hubbs wrote:
> >> If we have a default expiration, it should be one year after the date
> >> posted to go along with our current policy of not supporting things that
> >> are older than a year.
> >>
> >> William
> >
> > I thought it was three years.
> >
> > At any rate, I think a year is too short.
> >
> > How about 18 months?
> >
>
> I might sound like a broken CD here, but why define the expiration as
> part of the news format instead of specifying it in the package manager
> as a user defined variable? Various use cases requires different
> treatment, so leaving it up to user seems more relevant to me, and we
> could allow information to be presented as part of stages to give a hint
> for what dates to look for?
>

The short answer is I haven't seen any real use cases for it and even if we
were to spec it out and add it, I don't think it would be used by more than
10 people. To me that is an incentive to avoid complicating the software
spec.

-A


> --
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
>
>

[-- Attachment #2: Type: text/html, Size: 2121 bytes --]

Re: [gentoo-dev] Deleting old news items

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1248 bytes --]

On 01/05/2018 11:40 PM, Alec Warner wrote:
>> I might sound like a broken CD here, but why define the expiration as
>> part of the news format instead of specifying it in the package manager
>> as a user defined variable? Various use cases requires different
>> treatment, so leaving it up to user seems more relevant to me, and we
>> could allow information to be presented as part of stages to give a hint
>> for what dates to look for?
>>
> The short answer is I haven't seen any real use cases for it and even if we
> were to spec it out and add it, I don't think it would be used by more than
> 10 people. To me that is an incentive to avoid complicating the software
> spec.

From my point of view it requires less specification, as it doesn't
require a policy for how to set the expiration date, but allowing some
flexibility on the part of the user base.

There are rather big differences e.g between a server upgrade pattern
and a desktop system, how would you account for that in the expire date?
in particular for non security relevant upgrades, e.g profile changes?


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Deleting old news items

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1578 bytes --]

On 01/05/2018 11:47 PM, Kristian Fiskerstrand wrote:
> On 01/05/2018 11:40 PM, Alec Warner wrote:
>>> I might sound like a broken CD here, but why define the expiration as
>>> part of the news format instead of specifying it in the package manager
>>> as a user defined variable? Various use cases requires different
>>> treatment, so leaving it up to user seems more relevant to me, and we
>>> could allow information to be presented as part of stages to give a hint
>>> for what dates to look for?
>>>
>> The short answer is I haven't seen any real use cases for it and even if we
>> were to spec it out and add it, I don't think it would be used by more than
>> 10 people. To me that is an incentive to avoid complicating the software
>> spec.
> 
> From my point of view it requires less specification, as it doesn't
> require a policy for how to set the expiration date, but allowing some
> flexibility on the part of the user base.
> 
> There are rather big differences e.g between a server upgrade pattern
> and a desktop system, how would you account for that in the expire date?
> in particular for non security relevant upgrades, e.g profile changes?
> 
> 

Lets take another real-life example; I have two machines A and B. A is
one a stage3 install from before switching from 13.0. to 17.0 and B is
on the latter. As a developer, how would you specify expiration for
switch between profiles?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Deleting old news items

[Michał Górny]

W dniu pią, 05.01.2018 o godzinie 23∶09 +0100, użytkownik Kristian
Fiskerstrand napisał:
> On 01/05/2018 10:28 PM, Aaron W. Swenson wrote:
> > On 2018-01-05 15:16, William Hubbs wrote:
> > > If we have a default expiration, it should be one year after the date
> > > posted to go along with our current policy of not supporting things that
> > > are older than a year.
> > > 
> > > William
> > 
> > I thought it was three years.
> > 
> > At any rate, I think a year is too short.
> > 
> > How about 18 months?
> > 
> 
> I might sound like a broken CD here, but why define the expiration as
> part of the news format instead of specifying it in the package manager
> as a user defined variable? Various use cases requires different
> treatment, so leaving it up to user seems more relevant to me, and we
> could allow information to be presented as part of stages to give a hint
> for what dates to look for?
> 

To be honest, I kinda agree with Kristian here. I feel like this header
isn't going to work well.

While the idea may initially sound good, I'm afraid we'll have the usual
developer split here: some developers will set very long times, some
will set very short times, some will not care and just copy some random
value (default, the value from some other news item). In the end, users
will end up seeing very old news items from dev X, while newer items
from dev Y will disappear.

So yes, I think having a single predefined time is better,
for consistency at least. And allowing user to adjust that time based
on his own is certainly better than making it only dev-settable.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Deleting old news items

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3464 bytes --]

On Fri, Jan 5, 2018 at 6:55 PM, Michał Górny <mgorny@gentoo.org> wrote:

> W dniu pią, 05.01.2018 o godzinie 23∶09 +0100, użytkownik Kristian
> Fiskerstrand napisał:
> > On 01/05/2018 10:28 PM, Aaron W. Swenson wrote:
> > > On 2018-01-05 15:16, William Hubbs wrote:
> > > > If we have a default expiration, it should be one year after the date
> > > > posted to go along with our current policy of not supporting things
> that
> > > > are older than a year.
> > > >
> > > > William
> > >
> > > I thought it was three years.
> > >
> > > At any rate, I think a year is too short.
> > >
> > > How about 18 months?
> > >
> >
> > I might sound like a broken CD here, but why define the expiration as
> > part of the news format instead of specifying it in the package manager
> > as a user defined variable? Various use cases requires different
> > treatment, so leaving it up to user seems more relevant to me, and we
> > could allow information to be presented as part of stages to give a hint
> > for what dates to look for?
> >
>
> To be honest, I kinda agree with Kristian here. I feel like this header
> isn't going to work well.
>
> While the idea may initially sound good, I'm afraid we'll have the usual
> developer split here: some developers will set very long times, some
> will set very short times, some will not care and just copy some random
> value (default, the value from some other news item). In the end, users
> will end up seeing very old news items from dev X, while newer items
> from dev Y will disappear.
>
> So yes, I think having a single predefined time is better,
> for consistency at least. And allowing user to adjust that time based
> on his own is certainly better than making it only dev-settable.
>

I'll swerve right then and say this:
antarus@nspawntest /var/lib/gentoo/news $ cat news-gentoo.unread
2013-09-27-initramfs-required
2014-06-15-gcc48_ssp
2014-10-26-gcc_4_7_introduced_new_c++11_abi
2015-02-04-portage-sync-changes
2015-07-25-python-targets
2015-08-13-openssh-weak-keys
2015-10-22-gcc-5-new-c++11-abi
2016-06-23-l10n-use_expand
2017-11-30-new-17-profiles

Here are my news items.

initramfs-required hits every Gentoo box, has 0 Display restrictions, and
will never ever ever go away => delete it.
gcc48_ssp: Display-If-Installed: >=sys-devel/gcc-4.8.3 (and it includes
basically every major arch.) It will also never ever ever ever go away.
Either delete it or cap the gcc version.
gcc_4_7: Same boat as above, either cap the gcc version or nuke it.
portage: display-If-Installed: sys-apps/portage, will display on ever box.
So cap that as well.
python-targets: has no Display-If Headers, it will display on every box.
Delete it or cap it.
openssh_weak_keys: Display-If-Installed: net-misc/openssh. This looks like
a bug (only people who were on < 7.0 care about it.
gcc-5: Display-If-Installed: >=sys-devel/gcc-5 => another uncapped news
item.
l10n: Another news item with no Display-If-* headers, it too will live
forever.
new-17-profiles: another >=gcc-X, will never go away.

So 3 items have no display headers and are not fixable without adding a new
header. Many others can be fixed by capping Display-If-Installed versions.

-- Aside, I'm not totally convinced modifying the entries will work based
on a bug in portage-news. I'll poke the implementation more.

-A


>
> --
> Best regards,
> Michał Górny
>
>
>

[-- Attachment #2: Type: text/html, Size: 4560 bytes --]

[gentoo-dev] Re: Deleting old news items

[Duncan]

Michał Górny posted on Sat, 06 Jan 2018 00:55:58 +0100 as excerpted:

> W dniu pią, 05.01.2018 o godzinie 23∶09 +0100, użytkownik Kristian
> Fiskerstrand napisał:
>> On 01/05/2018 10:28 PM, Aaron W. Swenson wrote:
>>> On 2018-01-05 15:16, William Hubbs wrote:

>>>> If we have a default expiration, it should be one year after the
>>>> date posted to go along with our current policy of not supporting
>>>> things that are older than a year.
>>> 
>>> I thought it was three years.

AFAIK, the one-year policy is on upgrades-from.  If a user hasn't synced 
and updated in a year, updating is likely to be "problematic", and may 
require techniques such as digging old tree states a year or so apart out 
of git and using those to update a year's worth of updates at a time, and/
or updating the system in increments, the few packages that will update 
successfully first, then trying again to get the ones that can now update 
due to the improved base of the first set, and again...  It helps if 
there's other systems you keep more current, so you've already dealt with 
most changes one or a few at a time.

I know this from experience as while I keep my main system current (I'm 
antsy if it's more than a week between syncs), I used to have a 32-bit-
only first-gen atom, that I built updates for in a chroot and synced 
over, that I'd sometimes go over a year between updates on.  (Personal 
policy was nothing private on that machine, and it was normally not 
internet connected, so I wasn't horribly worried about security.)

So over a year, while the above update method is normally still 
/possible/, the easier/recommended/supported method is simply using the 
old install to fetch a new stage-3 to a chroot, and install new to it, 
except that you can "cheat" by basing your new config including USE 
flags, etc, off the old one.

The 3-year may well be for individual packages, but all I've ever seen 
for the entire tree and full system update is 1 year.

>>> At any rate, I think a year is too short.
>>> 
>>> How about 18 months?

That seems a reasonable default...

>> I might sound like a broken CD here, but why define the expiration as
>> part of the news format instead of specifying it in the package manager
>> as a user defined variable? Various use cases requires different
>> treatment, so leaving it up to user seems more relevant to me, and we
>> could allow information to be presented as part of stages to give a
>> hint for what dates to look for?
>> 
>> 
> To be honest, I kinda agree with Kristian here. I feel like this header
> isn't going to work well.
> 
> While the idea may initially sound good, I'm afraid we'll have the usual
> developer split here: some developers will set very long times, some
> will set very short times, some will not care and just copy some random
> value (default, the value from some other news item). In the end, users
> will end up seeing very old news items from dev X, while newer items
> from dev Y will disappear.
> 
> So yes, I think having a single predefined time is better,
> for consistency at least. And allowing user to adjust that time based on
> his own is certainly better than making it only dev-settable.

$ equery b news.eselect
app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect)

So in that case it's not the PM, but eselect.

But a new eselect version that ships a default
/etc/eselect/news/expiry that looks something like this:

# Days after which unread news messages will no longer be shown
# Default is 548, 18 months, (365*1.5 rounded up)
expiry=548

... and which then looks there for the value, seems reasonable to me.

* Being in /etc the file would be subject to normal config-protection.

* Can be accomplished with a bit of code and simple eselect package 
version bump, presumably with a post-install message mentioning the new 
config option.  No need for all the bureaucracy of a GLEP update, etc.

* Handbook and etc. documentation that I believe already mentions news 
and suggests eselect news as the default reader can be updated to mention 
this config option as well.

* A news item announcing the new default expiry and config for it might 
be appropriate as well.

* Should that general approach be agreed, all that would remain to debate 
would be whether 548 days (365*1.5 rounded up) is appropriate.  The 
precise config file path, name and format would be up to the implementer 
and/or eselect news module maintainer.

* Other news readers could of course set and ship their own default 
expiry, if desired.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Deleting old news items

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

>>>>> On Sat, 6 Jan 2018, Duncan  wrote:

> $ equery b news.eselect
> app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect)

> So in that case it's not the PM, but eselect.

In fact, it is the PM that would do the filtering, before filling the
list of unread news items in /var/lib/gentoo/news/news-gentoo.read.

Filtering in eselect news would be problematic: Obtaining the list
of items with "eselect news list" and e.g. reading them with "eselect
news read" are issued as separate commands, which requires that the
list of valid items does not change. However, time-based filtering
could cause a race condition, like an item expiring between execution
of the two commands.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Deleting old news items

[kuzetsa]

[-- Attachment #1.1: Type: text/plain, Size: 1183 bytes --]



On 01/06/2018 05:05 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 6 Jan 2018, Duncan  wrote:
>> $ equery b news.eselect
>> app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect)
>> So in that case it's not the PM, but eselect.
> In fact, it is the PM that would do the filtering, before filling the
> list of unread news items in /var/lib/gentoo/news/news-gentoo.read.
>
> Filtering in eselect news would be problematic: Obtaining the list
> of items with "eselect news list" and e.g. reading them with "eselect
> news read" are issued as separate commands, which requires that the
> list of valid items does not change. However, time-based filtering
> could cause a race condition, like an item expiring between execution
> of the two commands.
>
> Ulrich

The race condition could be addressed by issuing a warning
at or around the time when expirations occur (midnight),
with or without detecting specific expirations which may
have occurred:

WARNING: [n] is about to / has expired, and the list order
is about to / has just changed (as appropriate for list
and read respectively)

Otherwise just warn when the commands run near midnight.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: Deleting old news items

[Ciaran McCreesh]

On Sat, 6 Jan 2018 08:18:19 -0500
kuzetsa <kuzetsa@gmail.com> wrote:
> On 01/06/2018 05:05 AM, Ulrich Mueller wrote:
> >>>>>> On Sat, 6 Jan 2018, Duncan  wrote:  
> >> $ equery b news.eselect
> >> app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect)
> >> So in that case it's not the PM, but eselect.  
> > In fact, it is the PM that would do the filtering, before filling
> > the list of unread news items
> > in /var/lib/gentoo/news/news-gentoo.read.
> >
> > Filtering in eselect news would be problematic: Obtaining the list
> > of items with "eselect news list" and e.g. reading them with
> > "eselect news read" are issued as separate commands, which requires
> > that the list of valid items does not change. However, time-based
> > filtering could cause a race condition, like an item expiring
> > between execution of the two commands.
> 
> The race condition could be addressed by issuing a warning
> at or around the time when expirations occur (midnight),
> with or without detecting specific expirations which may
> have occurred:

How accurate is "around"? Obviously we'd need to introduce a user
configuration option so different users could set appropriate values
for their needs.

Seriously though, all this complexity is just highlighting that dates
are a really bad way of deciding when a news item should expire, and
that if we need anything, it's more Display-If conditions.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: Deleting old news items

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

On Sat, Jan 6, 2018 at 11:25 AM, Ciaran McCreesh <
ciaran.mccreesh@googlemail.com> wrote:

> On Sat, 6 Jan 2018 08:18:19 -0500
> kuzetsa <kuzetsa@gmail.com> wrote:
> > On 01/06/2018 05:05 AM, Ulrich Mueller wrote:
> > >>>>>> On Sat, 6 Jan 2018, Duncan  wrote:
> > >> $ equery b news.eselect
> > >> app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect)
> > >> So in that case it's not the PM, but eselect.
> > > In fact, it is the PM that would do the filtering, before filling
> > > the list of unread news items
> > > in /var/lib/gentoo/news/news-gentoo.read.
> > >
> > > Filtering in eselect news would be problematic: Obtaining the list
> > > of items with "eselect news list" and e.g. reading them with
> > > "eselect news read" are issued as separate commands, which requires
> > > that the list of valid items does not change. However, time-based
> > > filtering could cause a race condition, like an item expiring
> > > between execution of the two commands.
> >
> > The race condition could be addressed by issuing a warning
> > at or around the time when expirations occur (midnight),
> > with or without detecting specific expirations which may
> > have occurred:
>
> How accurate is "around"? Obviously we'd need to introduce a user
> configuration option so different users could set appropriate values
> for their needs.
>
> Seriously though, all this complexity is just highlighting that dates
> are a really bad way of deciding when a news item should expire, and
> that if we need anything, it's more Display-If conditions.
>
>
I rescind my patches; I'm fairly sure portage is broken and I don't really
relish fixing it; I've already spent more than 2 hours working on this and
this isn't worth spending more time on anyway.

-A



> --
> Ciaran McCreesh
>
>

[-- Attachment #2: Type: text/html, Size: 2787 bytes --]

Re: [gentoo-dev] Re: Deleting old news items

[Anders Thomson]

As a non-dev...
>
>In fact, it is the PM that would do the filtering, before filling the
>list of unread news items in...

How come news' transport is tied to the pm / package tree at all? It would seem more natural to fetch news using e.g. rss and have a reader (which i can configure) sort out what to fetch/display when. 

Anders

Re: [gentoo-dev] Re: Deleting old news items

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

On Sat, Jan 6, 2018 at 2:51 PM, Anders Thomson <andersthomson888@gmail.com>
wrote:

>
>
> As a non-dev...
> >
> >In fact, it is the PM that would do the filtering, before filling the
> >list of unread news items in...
>
> How come news' transport is tied to the pm / package tree at all? It would
> seem more natural to fetch news using e.g. rss and have a reader (which i
> can configure) sort out what to fetch/display when.


https://www.gentoo.org/glep/glep-0042.html#requirements details the whys.

-A



>
> Anders
>
>

[-- Attachment #2: Type: text/html, Size: 1263 bytes --]

Re: [gentoo-dev] Re: Deleting old news items

[Anders Thomson]

On January 6, 2018 9:30:51 PM GMT+01:00, Alec Warner <antarus@gentoo.org> wrote:
>On Sat, Jan 6, 2018 at 2:51 PM, Anders Thomson
><andersthomson888@gmail.com>
>wrote:
>
>>
>>
>> As a non-dev...
>> >
>> >In fact, it is the PM that would do the filtering, before filling
>the
>> >list of unread news items in...
>>
>> How come news' transport is tied to the pm / package tree at all? It
>would
>> seem more natural to fetch news using e.g. rss and have a reader
>(which i
>> can configure) sort out what to fetch/display when.
>
>
>https://www.gentoo.org/glep/glep-0042.html#requirements details the
>whys.
>
Thanks.
Which of the requirements requires transport to be in a particular manner? I see implications on pm, but nothing on transport.

A

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Re: Deleting old news items

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 565 bytes --]

On 01/06/2018 11:11 PM, Anders Thomson wrote:
> Thanks. Which of the requirements requires transport to be in a
> particular manner? I see implications on pm, but nothing on
> transport.

tl;dr; the PM knows which packages are installed on the specific system,
a specific feed does not (although that doesn't exclude the possibility
of getting feed of all messages, which is already part of git repository)


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Re: Deleting old news items

[Denis Lisov]

On Sat, Jan 6, 2018 at 1:05 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> Filtering in eselect news would be problematic: Obtaining the list
> of items with "eselect news list" and e.g. reading them with "eselect
> news read" are issued as separate commands, which requires that the
> list of valid items does not change. However, time-based filtering
> could cause a race condition, like an item expiring between execution
> of the two commands.

Would it be possible to make the expiration times use not the wall
clock time, but the timestamp of the repository if one is available?

That would not only be more predictable (can expire on repository
manipulations only), but also better suited for updating severely
outdated systems. You can advance the repository state by 1 year and
read the news items as they were at that time, not half of them
expired and hidden.

Denis Lisov.

Re: [gentoo-dev] Deleting old news items

[Michał Górny]

W dniu czw, 04.01.2018 o godzinie 20∶20 -0500, użytkownik Alec Warner
napisał:
> The attached patch proposes a new news item format (2.1).
> 
> In format 2.1, the Expires: header is mandatory.
> 
> PMs can detect whether a given news item is "expired" by comparing the
> current date in UTC to the expired date.
> Expired news items should not be shown to users.
> 
> Once this is accepted and implemented, we can go back and bump the existing
> news items to format 2.1 and add the new mandatory header.
> 
> Old news implementations should ignore the "Expires" header (as they ignore
> any unspecified header.)

What will the relevant policy be, i.e. what value should we be putting there?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Deleting old news items

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

On Fri, Jan 5, 2018 at 4:00 AM, Michał Górny <mgorny@gentoo.org> wrote:

> W dniu czw, 04.01.2018 o godzinie 20∶20 -0500, użytkownik Alec Warner
> napisał:
> > The attached patch proposes a new news item format (2.1).
> >
> > In format 2.1, the Expires: header is mandatory.
> >
> > PMs can detect whether a given news item is "expired" by comparing the
> > current date in UTC to the expired date.
> > Expired news items should not be shown to users.
> >
> > Once this is accepted and implemented, we can go back and bump the
> existing
> > news items to format 2.1 and add the new mandatory header.
> >
> > Old news implementations should ignore the "Expires" header (as they
> ignore
> > any unspecified header.)
>
> What will the relevant policy be, i.e. what value should we be putting
> there?
>

My straw man is 1-3 years from date of posting. Like in theory authors
wouldn't even write it in and a pre-commit hook would just inject the
header into the message at commit-time.


>
> --
> Best regards,
> Michał Górny
>
>
>

[-- Attachment #2: Type: text/html, Size: 1684 bytes --]

Re: [gentoo-dev] Deleting old news items

[nado]

January 5, 2018 3:58 AM, "Alec Warner" <antarus@gentoo.org> wrote:
> ... snip ...
> + compatability with GLEP 45 [#glep-45]_. Translations should use the date of
> + the original news item. An item is expired if the current date in UTC is
> + greater than the expiration date of the item. Package manages should not
> + display expired items.

s/compatability/compatibility/ and s/Package manages/Package managers/

Regards,
--
Corentin “Nado” Pazdera

Re: [gentoo-dev] Deleting old news items

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

On Fri, Jan 5, 2018 at 5:15 AM, <nado@troglodyte.be> wrote:

> January 5, 2018 3:58 AM, "Alec Warner" <antarus@gentoo.org> wrote:
> > ... snip ...
> > + compatability with GLEP 45 [#glep-45]_. Translations should use the
> date of
> > + the original news item. An item is expired if the current date in UTC
> is
> > + greater than the expiration date of the item. Package manages should
> not
> > + display expired items.
>
> s/compatability/compatibility/ and s/Package manages/Package managers/
>

Vim even highlights these; thanks for pointing them out, fixed ;)


>
> Regards,
> --
> Corentin “Nado” Pazdera
>
>

[-- Attachment #2: Type: text/html, Size: 1199 bytes --]

Re: [gentoo-dev] Deleting old news items

[Alec Warner]

[-- Attachment #1.1: Type: text/plain, Size: 890 bytes --]

Latest version.

I still want to discuss whether Expires is Mandatory or Optional and how
that actually ends up being used.

-A

On Fri, Jan 5, 2018 at 9:01 AM, Alec Warner <antarus@gentoo.org> wrote:

>
>
> On Fri, Jan 5, 2018 at 5:15 AM, <nado@troglodyte.be> wrote:
>
>> January 5, 2018 3:58 AM, "Alec Warner" <antarus@gentoo.org> wrote:
>> > ... snip ...
>> > + compatability with GLEP 45 [#glep-45]_. Translations should use the
>> date of
>> > + the original news item. An item is expired if the current date in UTC
>> is
>> > + greater than the expiration date of the item. Package manages should
>> not
>> > + display expired items.
>>
>> s/compatability/compatibility/ and s/Package manages/Package managers/
>>
>
> Vim even highlights these; thanks for pointing them out, fixed ;)
>
>
>>
>> Regards,
>> --
>> Corentin “Nado” Pazdera
>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 1793 bytes --]

[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 3390 bytes --]

diff --git a/glep-0042.rst b/glep-0042.rst
index 416bd18..65c9230 100644
--- a/glep-0042.rst
+++ b/glep-0042.rst
@@ -9,10 +9,10 @@ Type: Standards Track
 Status: Final
 Version: 4
 Created: 2005-10-31
-Last-Modified: 2017-11-29
+Last-Modified: 2018-01-04
 Post-History: 2005-11-01, 2005-11-05, 2005-11-07, 2005-12-11, 2005-12-13,
               2005-12-18, 2006-01-05, 2006-03-02, 2006-03-06, 2006-06-12,
-              2006-09-05, 2016-03-10, 2017-11-27
+              2006-09-05, 2016-03-10, 2017-11-27, 2018-01-04
 Content-Type: text/x-rst
 ---
 
@@ -208,7 +208,9 @@ compatibility with and for the same reasons as existing Gentoo documentation
 A news item file's content will consist of an RFC 822 style header [#rfc-822]_
 followed by the main body of the message as plain text. This GLEP defines
 various optional and mandatory headers. Future GLEPs may propose new headers —
-tools handling these news items must ignore any unrecognised header.
+tools handling these news items must ignore any unrecognised header. Headers
+where the name of the header is valid but the value is invalid shall also count
+as unrecognised.
 
 .. Note:: A previous version of this GLEP had required that news items must
    be signed with a detached OpenPGP signature. This was deemed no longer
@@ -247,17 +249,25 @@ The following headers describe the purpose and format of the news item:
     item. Mandatory.
 
 ``News-Item-Format:``
-    Known formats are ``1.0`` and ``2.0``.  Future revisions to the format
-    may increment the minor number for forwards-compatible changes (i.e.,
-    still allowing older tools to process the new format), or the major
+    Known formats are ``1.0``, ``2.0``, and ``2.1``.  Future revisions to the
+    format may increment the minor number for forwards-compatible changes
+    (i.e., still allowing older tools to process the new format), or the major
     number for major changes.
 
+``Expires:``
+    Date of expiration, in ``yyyy-mm-dd`` format (e.g. 2019-01-18) for
+    compatibility with GLEP 45 [#glep-45]_. Translations should use the date of
+    the original news item. An item is expired if the current date in UTC is
+    greater than the expiration date of the item. Package managers should not
+    display expired items. In news item format ``2.1``, this field is
+    mandatory.
+
 The following headers are used for filtering:
 
 ``Display-If-Installed:``
     A package dependency specification (for example, ``>=sys-devel/gcc-5``
     or ``www-servers/apache``) conforming to EAPI 0 [#PMS]_ in news item
-    format ``1.0`` or to EAPI 5 in format ``2.0``.  If the user has the
+    format ``1.0`` or to EAPI 5 in format ``2.*``.  If the user has the
     package specified installed from the repository from which the news item
     was obtained, the news item should be displayed.
 
@@ -269,7 +279,7 @@ The following headers are used for filtering:
     A profile path, for example ``default/linux/sparc/13.0``. If the
     user is using the exact profile in question, the news item should be
     displayed. This header may be used to replace ``deprecated`` files in the
-    future.  In news item format ``2.0``, a terminal asterisk immediately
+    future.  In news item format ``2.*``, a terminal asterisk immediately
     following a slash acts as a wildcard for any further path components,
     for example ``default/linux/*``.
 

Re: [gentoo-dev] Deleting old news items

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

>>>>> On Fri, 5 Jan 2018, Alec Warner wrote:

> Latest version.
> I still want to discuss whether Expires is Mandatory or Optional and how that
> actually ends up being used.

If it is going to be mandatory, then we need to allow a special value
like "never" which would indicate that an item will never expire
(if we don't, people will inevitably use values like 9999-12-31 ...).
Also I think that the format should be called 3.0 rather than 2.1 then,
because introduction of a mandatory header is an incompatible change.

I don't just see the point of restricting the format by making this
mandatory in the GLEP. Every item goes through review, and there it
will certainly being pointed out if an Expires header is missing.

> +``Expires:``
> +    Date of expiration, in ``yyyy-mm-dd`` format (e.g. 2019-01-18) for
> +    compatibility with GLEP 45 [#glep-45]_. Translations should use the date of
> +    the original news item. An item is expired if the current date in UTC is
> +    greater than the expiration date of the item. Package managers should not
> +    display expired items. In news item format ``2.1``, this field is
> +    mandatory.

Regardless of the field being mandatory or not, the wording of the
last sentence is not very clear, because one could think that this
header was allowed in previous formats. I suggest something like:
"Only defined in news item format ``2.1`` or later, where it is
(mandatory|optional)."

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]