Re: Policy to remove obsolete packages

["Björn Höfling" <bjoern.hoefling@bjoernhoefling.de>]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

Hi simon,

On Thu, 7 Feb 2019 13:40:53 +0100
zimoun <zimon.toutoune@gmail.com> wrote:

> Hi,
> 
> I understand but I am not sure to see the points and/or advantages
> about a policy.
> 
> From my opinion, obsolete package is not well-defined and define  
> cleanly what an obsolete package is will be bikeshedding. :-)
> And I think that deprecated should come from upstream.
> However, a popcon of the downloaded substitutes should provide which
> packages are "important" and which are less; to have a better
> "priority list"---if needed.

I really wouldn't take that "Policy" too formal: It is more like that:
There are packages that are just broken and nobody cares. But nobody
removed them from Guix, because everybody was unsure about it.

Now we agreed on that when a package is broken for more than 6 months
we should announce it on dev-list and if then nobody takes action, we
remove it. It is more like "community consensus" that it is very OK to
remove these packages.

CI is another related topic we are working on. In theory, a commit
should break nothing. Or at least the commiter should get a message
back of what exactly they broke.

> And I also do agree that it is hard to find the information what it
> went wrong. For example, recently I was not able to find what breaks
> clang@3.5.

Sometimes it magically helps to just write a bug-report with the
correct error-message and/or link to hydra.gnu.org's failure. I noticed
in the past that a good, concise bug-report gets attention to the right
people to fix it :-)

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]