Re: [gentoo-dev] Deleting old news items
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
> 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
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
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
+1 signature.asc Description: Digital signature
Re: [gentoo-dev] Deleting old news items
+1 There is also https://www.gentoo.org/support/news-items/ if needed signature.asc Description: Digital signature
[gentoo-dev] Deleting old news items
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
