maintainership
Sat, Dec 15, 2018 | maintainership, paramiko
Intro When it comes to software maintenance tradeoffs, most of what I laid out in “The why & when of software releases” remains accurate. An ‘iron triangle’ exists between speed, stability, and ease of maintenance – it’s impossible to prioritize all three. I historically prioritize stability, specifically via bugfix-oriented release branches – users can stick to a given minor version even after subsequent feature releases appear, with the implied contract that they can install updates from those branches without anything breaking.



Sun, Sep 29, 2013 | documentation, maintainership, sphinx

Most open source projects store documentation in the source repo itself. This is easy to do, allows the doc builder to reference in-code documentation (like Python docstrings), makes contributions from others simpler, etc.

However, it doesn’t always play nice with “meta” information such as how to contribute, project roadmap, and so forth.





Thu, Jun 7, 2012 | maintainership, packaging

On what?

Vendorizing. Including dependencies inside your own source tree as if they were part of your application. Also known as ‘bundling’, ‘omnibus’ etc. I’m going to be talking about Python software specifically, but it’s a general problem.

I’m weighing the pros and cons of vendorizing vs relying on externally-installed libraries, as I don’t see a strong consensus on the topic – and am curious what others with different experiences and use cases have to say.