On 28.02.24 22:09, Charlie Li wrote:
Florian Smeets wrote:
This policy should give some guidance on when ports can or should be
removed. In general ports should not be removed without reason but if
a port blocks progress it should be deprecated and subsequently
removed. In general, if a ports blocks progress for some time it will
be removed so that progress can be made. For more details see below.
The phrasing "blocks progress" is problematic. Progress of what?
Indiscriminately hunting down EOL/apparently inactive software? Mass
migrating from one build system to another due to primarily personal
preference, even against upstreams' will? This phrasing is vague enough
to justify deprecating and removing, say EOL (but still fetchable and
buildable) libraries needed by actively-maintained and supported (and
popular) software that are in no rush to migrate away. If this vagueness
is intended, then it needs to be accompanied with *us* actively
developing in the upstream project to support efforts here.
The sentence you refer to is just a rough summary of what is described
in more detail further down. e.g.
- The port does not adapt to infrastructure changes (i.e. USE_STAGE,
MANPREFIX, compiler updates, etc.) within 6 months. Ports should be
set to DEPRECATED after 3 months and can be removed after 6
These reasons are good on first read but the premise needs to be worked
in earlier. Also need to consider actively-maintained and supported
software that happen to use EOL dependencies.
I don't understand what you are trying to say with the first sentence.
It's kind of implicit that we will not allow removal of libraries that
still have (lots of) ports depending on them with this policy. But we
should probably make this explicit. I'll add a note and come up with
something.
Thanks
Florian
