On 03/24/2014 10:23 PM, Miloslav Trmač
wrote:
That doesn't work.
On the contrary if it did not the business module Red Hat is build
upon would not exist since Red Hat is making money out of stability
promises to it's customers which upstream is not providing right.
Unfortunately a common reason to deprecate a component is
that the upstream has gone away or become inactive, in which
case we can't expect that same upstream to take action to
coordinate a deprecation.
Here we are talking about various upstreams that make up the
core/baseOS not single entity.
Now if an upstream for a component is dead in every sense of the
word as in not being actively maintained anywhere by anyone it
should be removed because that in itself is the signal for
deprecation.
If people oppose said removal they simple should have to step up and
start actively maintain that component thus bringing life to it
again for those users that continue to use it as in if upstream has
gone away and someone or some downstream distribution continues to
patch that component it effectively has become the new upstream and
the circle of life and the ecosystem surrounding that component
continues.
(The Base WG has, as one its goals:
Based on feedback from other WGs, provide a API and/or ABI
stability for a specific release rather than simply package
versions/releases
)
I eagerly await how they plan on succeed doing that and how they are
going to overcome certain obstacles they will be faced with solving
while doing so.
By the way the kernel does not have a proper deprecation process
which is accurately reflected in all the code that is
bit-rotting there so it's not the holy grail of code maintenance
as you let it out to be.
The kernel has built a reputation for having a very simple
deprecation process: "Don't" :)
Right which is bound to catch up with them ( it's unavoidable with
evolution that disruptive changes will happen ) and arguably already
has.
JBG