[procps] The libproc1 branch and fixing the API
- From: Craig Small <csmall-procps@xxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Sun, 26 May 2013 07:58:14 +1000
I think we can all agree that the API for procps is, well, suboptimal.
There wasn't a lot of thought put into it way back when because it was
supposed to be an internal interface between procps tools only.
The original idea for libproc1 branch was to develop a new API and
change the entire lot in one hit. Unless someone has got a LOT of time
on their hands this is simply not going to happen. That also means that
anything else that changes the API such as human readable uptime or the
namespace support are also stuck. For network engineering fans out
there, we'd call it head of line blocking and its rather frustrating.
The big hairy unfinished change "fix API" blocks the little merge
requests because they need to be all done at once.
There is a tension between reducing the number of API changes and
waiting for forever to get The Only And Only API, so there needs to be a
compromise.
My idea is to use libproc1 branch as a collection for all the changes,
ideas, patches and merge requests that will change the API. I might
make a new branch, but there will be a branch for this. So an accepted
merge request that changes the API goes into there, once there is enough
of it, it gets rolled into master and we start again.
The main change is fixing the API tasks. Originally this would go into
libproc1 directly, but now there would be a separate (possibly private)
branch where a change for a specific tool or group of functions would be
prepared and then staged into libproc1. So vmstat might get some or all
of its functions cutover here in one block.
There will be more API changes this way, but then again there will be
more API fixes and enhancements this way too.
- Craig
--
Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/ csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Other related posts:
- » [procps] The libproc1 branch and fixing the API - Craig Small
