Re[2]: [PEAR-QA] Re: [pear-webmaster] Re: [PEAR-QA] Thought about unmaintained package (Net_IRC in this case)

Hello Klaus, >> In this scenario, a column that would normally be DATETIME or INT type >> now becomes VARCHAR. KG> Not quite... because the idea is to add two columns: one for the name of KG> the package that supercedes it and the other for the date/time of the KG> depreciation. Since the name of the package would be a tinytext field (I KG> suppose), it wouldn't do any harm to simply put "unmaintained" in there. I can offer adding status enum ('OK','ACTIVE','INQUIRY','UNMAINTAINED','DEPRECATED') status_change DATETIME status_related VARCHAR 'OK' -> NULL 'ACTIVE' -> link to current activity info 'INQUIRY' -> link to QA tracker? (doubt there will be any) 'UNMAINTAINED' -> NULL (but in presentation layer button to apply) 'DEPRECATED' -> name of successor To tell the truth I prefer this status to be in separate table, so events could be added to it and sorted by date like: package_id status_date status status_related (package_id status_date) - PRIMARY KEYS GROUP BY package_id ORDER BY status_date DESC Additional maintenance DB queries: check names for deprecated packages These modification can take 20 minutes to do or many days to talk. I think the problem is not in implementation, but in people who can do this practically. KG> On the other hand, what you say below is true. In fact, I'd almost KG> suggest linking based on package ID rather than package name (if it KG> depends on user input, it could make a mess if someone enters a package KG> that is not in the DB). I'd suggest a selection box something like for KG> maintainers... but n to 1 selection... But maybe that's overkill. At any KG> rate, even if "unmaintained" in the field signifies unmaintained status, KG> it probably would be best to put that in the interface as a checkbox. KG> Come to think of it, a package may be maintained but depreciated... And KG> another unmaintained but not depreciated. So I guess the best way to KG> solve the problem is to simply add a field indicating whether a package KG> is maintained or not. Please provide an example where package is maintained or deprecated? To me 'Deprecated' implies 'Unmaintained'. If you have time to report bugs and use deprecated package - you can always follow old PEAR tradition and contact former developers. It is Ok if you will not recieve support either it is deprecated package or unmaintained. t --