Maintenance of forked software
Opened this issue · 2 comments
Some partners fork software in order to fix bugs or add new functionality. Just a few examples include suds, django-queued-storage and photologue.
These forked versions aren't always available or maintained, which break system upgrades or breaks with newer Python versions.
Forked software should either be avoided at all cost or a maintenance plan needs to be in place that ensures that up to date versions of these forks are available for installation.
Currently devops puts out fires caused by this, and it doesn't scale and leads to more problems than it's worth.
Part of this can possibly be fixed by policy in the Ways of Working, but it might need integration in to other Praekelt policies as well.
Part of the issues with forks is that they're often not maintained. So
perhaps a good baseline rule is "if you fork, you maintain it". Maintaining
a fork at a bare minimum probably means 1) giving it a new name 2) have a
repository and way to submit patches 3) releases on PyPI whenever there are
patches (or wherever we normally get packages of that type from).
Great feedback and ideas, thanks @hodgestar