Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread Alec Warner
On Fri, Jan 5, 2018 at 6:55 PM, Michał Górny  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
>
>
>


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread 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

2018-01-05 Thread Kristian Fiskerstrand
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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread Kristian Fiskerstrand
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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread Alec Warner
On Fri, Jan 5, 2018 at 5:09 PM, Kristian Fiskerstrand 
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
>
>


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread Kristian Fiskerstrand
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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread Aaron W. Swenson
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?


signature.asc
Description: Digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread William Hubbs
On Fri, Jan 05, 2018 at 09:01:26AM -0500, Alec Warner wrote:
> On Fri, Jan 5, 2018 at 5:08 AM, Ulrich Mueller  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


signature.asc
Description: Digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread Ulrich Mueller
> 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 -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 ``-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


pgpg0R3gM_7gU.pgp
Description: PGP signature


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread Alec Warner
On Fri, Jan 5, 2018 at 4:00 AM, Michał Górny  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
>
>
>


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread Alec Warner
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  wrote:

>
>
> On Fri, Jan 5, 2018 at 5:15 AM,  wrote:
>
>> January 5, 2018 3:58 AM, "Alec Warner"  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
>>
>>
>


patch
Description: Binary data


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread Alec Warner
On Fri, Jan 5, 2018 at 5:15 AM,  wrote:

> January 5, 2018 3:58 AM, "Alec Warner"  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
>
>


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread Alec Warner
On Fri, Jan 5, 2018 at 5:08 AM, Ulrich Mueller  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 ``-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
>


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread nado
January 5, 2018 3:58 AM, "Alec Warner"  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

2018-01-05 Thread Ulrich Mueller
> 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 ``-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


pgpPLwewpjLBp.pgp
Description: PGP signature


Re: [gentoo-dev] Deleting old news items

2018-01-05 Thread 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

2018-01-04 Thread Alec Warner
On Thu, Jan 4, 2018 at 8:20 PM, Alec Warner  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  wrote:
>
>>
>>
>> On Wed, Jan 3, 2018 at 6: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.
>>>
>>
>> Ok, I'll submit a patch to the GLEP for this. Stay tuned.
>>
>> -A
>>
>>
>>>
>>> Ulrich
>>>
>>
>>
>


patch
Description: Binary data


Re: [gentoo-dev] Deleting old news items

2018-01-04 Thread Alec Warner
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  wrote:

>
>
> On Wed, Jan 3, 2018 at 6: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.
>>
>
> Ok, I'll submit a patch to the GLEP for this. Stay tuned.
>
> -A
>
>
>>
>> Ulrich
>>
>
>


patch
Description: Binary data


Re: [gentoo-dev] Deleting old news items

2018-01-03 Thread Alec Warner
On Wed, Jan 3, 2018 at 6: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.
>

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

-A


>
> Ulrich
>


Re: [gentoo-dev] Deleting old news items

2018-01-03 Thread Kristian Fiskerstrand
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  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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-03 Thread Kristian Fiskerstrand
On 01/03/2018 02:45 PM, Ciaran McCreesh wrote:
> On Wed, 3 Jan 2018 12:23:33 +0100
> Kristian Fiskerstrand  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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-03 Thread Ciaran McCreesh
On Wed, 3 Jan 2018 12:23:33 +0100
Kristian Fiskerstrand  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

2018-01-03 Thread Kristian Fiskerstrand
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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-03 Thread kuzetsa
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.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-03 Thread Ulrich Mueller
> 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


pgp8tYyWmIGCt.pgp
Description: PGP signature


Re: [gentoo-dev] Deleting old news items

2018-01-03 Thread kuzetsa
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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-03 Thread 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

2018-01-02 Thread Aaron W. Swenson
+1


signature.asc
Description: Digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-02 Thread Mikle Kolyada
+1

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


signature.asc
Description: Digital signature