Ok to get this to a close how about the following:
In general kicad symbols are allowed to be marked obsolete via the description field as soon as the manufacturer declares the part as obsolete or some other comparable state. (The obsolete tag should look as follows: [obsolete date] date format: yyyy-mm the tag includes the brackets. an example would be [obsolete 2018-01])
One year later it is allowed to move the symbol to a library within the obsolete directory.
If the contributor can show that a part has been declared as obsolete by the manufacturer at least one year in the past, the part can be transferred into the obsolete lib without the waiting period.
Most importantly: We maintainers will not take care of this! We will accept requests to declare something as obsolete. (If the contributor can provide evidence that the manufacturer declared something as obsolete. We will ignore all distributors here! I will not stand for binding kicad to such companies.) But i am not prepared to check all symbols regularly if they are still active. (I already sink way too much time into kicad as is.)
We might add a script that checks the lib regularly for tagged symbols. This script could then move symbols that have been tagged as obsolete into the obsolete libs after the grace period of one year expired.
All of this has lower priority compared to getting the lib ready for the v5 release. I rely on you guys to remind me after the v5 release if non of you have implemented this until then. (I maintain the right not to increase my personal priority for this. For any reason.)
I do not particularly subscribe to the negative image of “a dusty folder at the back”, but I agree with the intent described here. And after all, we are a community, so when a community member shows that some part is mistakenly moved to “the back of the library”, it is easy enough to correct.
[quote=“mifi, post:22, topic:9260”]
I do not particularly subscribe to the negative image of “a dusty folder at the back” . . . [/quote]
My use of hyperbole gets me into trouble again. In fact, scholars occasionally unearth beautiful gems from within dusty folders stacked in the backs of libraries.
The point of this discussion is to develop a process which prevents the accumulation of obsolete parts from either becoming a visual or mental obstacle to using the libraries efficiently, or degrading KiCAD’s performance for the majority of users. I think we have accomplished that and the proposal from @Rene_Poschl is a good solution.
I like the general policy. However, for a lot of old parts it’s hard to tell exactly when they are made obsolete, or even if the manufacturer has declared them obsolete - the original manufacturer may no longer exist, or the part is simply not listed on the manufacturer website. So putting YYYY-MM is largely a guess.
A case in point: 27128 and 27C128 EPROMs. I believe they are obsolete, but I can’t find a PCN or similar for them. The best I have is a Microchip datasheet dated 2004 which is marked “Obsolete”, or similar datasheets marked “NRND”, the best I can do is put 2004 and an arbitrary month.
Not that it will help with decisions, but as an FYI, Digikey’s part status is normalized to the few standard nomenclatures, so if it says Obsolete, you can pretty much count on it being not manufactured anymore. The normalization is likewise true with NRND and Last Time Buy.
That doesn’t mean stuff doesn’t come back from the dead, actually you’d be surprised at how many products come back after being obsoleted. Sometimes manufacturers shrug it off as if it never happened and make the related documents go away.
Indeed, I think the goals of the official lib and Digikey lib are somewhat different. The DK lib is supposed to be a quick prototyping lib that has a subset of parts that a large cross-section of people might want to play with and could reasonably expect it to be in stock. Given this, the current strategy to encode the status if it’s something other than active and stocking. It’s certainly subject to change with feedback, but that’s the way it has been leaning.