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