Re: [gentoo-dev] Deleting old news items

[Alec Warner]

On Fri, Jan 5, 2018 at 6:55 PM, Michał Górny <mgorny@g.o> 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
>
>
>