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