I am not sure if we have any way to prevent really old news items from being showed on a first install. In my case, I am needing to install Gentoo on a new computer and I have just seen that I needed to read 12 news items... but many of them are obsolete and useless this days: https://www.gentoo.org/support/news-items/2013-09-27-initramfs-required.html -> On a first install, this information should be noted in Handbook to ensure people is aware of the issue when installing... but later, this news item is not needed https://www.gentoo.org/support/news-items/2014-06-15-gcc48_ssp.html -> should we still warn people about this? Cannot be this explained in the wiki? :/ https://www.gentoo.org/support/news-items/2014-10-26-gcc_4_7_introduced_new_c++11_abi.html -> This looks to me like really obsolete now, I doubt many users installing Gentoo will care about this or need to take any special action https://www.gentoo.org/support/news-items/2015-01-28-cpu_flags_x86-introduction.html -> This should probably be explained in the HandBook when configuring make.conf :/ (even default make.conf is still using the old USEs... but I think it was due to a fixed-in-testing bug in catalyst) https://www.gentoo.org/support/news-items/2015-02-04-portage-sync-changes.html -> the important information for new users is already shown in Handbook https://www.gentoo.org/support/news-items/2015-03-28-true-multilib.html -> PRobably obsolete at this time https://www.gentoo.org/support/news-items/2015-07-25-python-targets.html -> People installing Gentoo now don't need to take any special action on this https://www.gentoo.org/support/news-items/2015-08-13-openssh-weak-keys.html -> Probably not so important this days :/
This is an ongoing problem which I've also been looking at on and off for some time, but unfortunately most people don't seem to care about it. I'm not sure if there's much more we can do than contact the author of each item and ask them about removing it or at least see if we can restrict the atom ranges.
Yeah, maybe for the current issue we could CC the relevant authors (well, there are a lot) and, for the future, try to suggest people to prepare the news items trying to restrict them for the future (trying to guess a future version number I guess)
Do we have any reasonable way of disabling news items for new installs while preserving them for old upgrades? Or do we have to play with packages and profiles?
For the future, maybe we should introduce a header line like: Expires: yyyy-mm-dd After that date, the news item would not be shown any more.
(In reply to Ulrich Müller from comment #4) > For the future, maybe we should introduce a header line like: > Expires: yyyy-mm-dd > > After that date, the news item would not be shown any more. I don't think that solves the issue at hand. The problem is that what we would need to make the expiration based on install date rather than current date [but I don't think we can reasonably do that]. OTOH, we can just assume we can kill old news items once we stop supporting ancient system upgrades.
commit 3df15df9519122e6d59e44e0614427a1a3f4a42e Author: Michał Górny <mgorny@gentoo.org> Date: Fri Mar 31 22:28:17 2017 Remove multilib news item as obsolete for new installs, #608208 commit f0c7da5f74ddb272a1cdf3f0830f533d735779ca Author: Michał Górny <mgorny@gentoo.org> Date: Fri Mar 31 22:27:41 2017 Remove CPU_FLAGS_X86 news item as obsolete for new installs, #608208 I've decided to remove these two of mine because they're already 2 years old. I wouldn't mind removing PYTHON_TARGETS either but I'll let others decide. @python?
(In reply to Michał Górny from comment #6) > commit 3df15df9519122e6d59e44e0614427a1a3f4a42e > Author: Michał Górny <mgorny@gentoo.org> > Date: Fri Mar 31 22:28:17 2017 > > Remove multilib news item as obsolete for new installs, #608208 > > commit f0c7da5f74ddb272a1cdf3f0830f533d735779ca > Author: Michał Górny <mgorny@gentoo.org> > Date: Fri Mar 31 22:27:41 2017 > > Remove CPU_FLAGS_X86 news item as obsolete for new installs, #608208 > > > I've decided to remove these two of mine because they're already 2 years > old. I wouldn't mind removing PYTHON_TARGETS either but I'll let others > decide. @python? Personally, I would just nix the python stuff.
