3 ms·
In short: we generally only remove things when they break, break other things or the projects are dead. How hard we try to fix these things generally come down
by mikemcquaid 10y ago
In short: we generally only remove things when they break, break other things or the projects are dead. How hard we try to fix these things generally come down to how used our analytics say they are.
- heuermh 10y agoAre the usage analytics available to package maintainers? What about in downstream taps such as Homebrew-Versions and Homebrew-Science? Would be nice to know when it comes to grant writing time.
- mikemcquaid 10y agoWe can make them available on request. Email me.
- a-no-n 10y agoHow did the "royal we" arrive at this "reasoning?" If popularity were a valid signal of importance, people should only express their eternal love for PHP and Javascript, and ignore computer science, functional programming languages, computer engineering and little-known-but-really-fucking-important packages. Call me ageist, but code churn and labeling projects "dead" adds nothing in the context of portable code which has matured to the point stability; there's zero functional value added in refactored code being "new." Ongoing support, adding features and keeping pace with platform compatibility are separate issues from judging code to be "inferior" despite working because it's "old." What may seem "dead" to people whom don't know about particular packages but may well just be stable and resting very quietly because it just works.
- mikemcquaid 10y agoIf projects are portable and continue to work without patching indefinitely: we don't consider them dead. What we're unwilling to do is to apply patch after patch to unmaintained and undeveloped projects to keep them working on macOS; at that point we're forking the project and lack either the desire nor people power to do so.