Hacker News new | past | comments | ask | show | jobs | submit login

> I'm convinced that change control is 99% pointless.

99% of the time their packaging and/or deployment systems can't track changes to the degree their change control setup claims anyway.

Thought experiment: run an "upgrade" command on your package manager. Even with a modest system, there are dozens (possibly hundreds) of "things" (executables, configurations, daemons, modules, etc.) that change. Often those things are rebuilds incorporating updates from their dependencies. So if a change management system wants to track exactly why each update happened, that appropriate stakeholders were in the loop, etc., you're actually stuck.

No [1] release system has that level of detail. You'd need a directed graph of all the reasons for all these changes top to bottom.

[1] Yes, I've seen safety critical situations before. No, the paperwork isn't at that level of detail there either. System-wide requirements (the whole system has to be fast in specific ways) don't map to particular lines of changed code like that. At some point, the paperwork gets to be gratuitous.




Change control need not be onerous.

One important aspect of it is simply sharing that a change is going to be made. It stops a few of those 'if only you had told me first' conversations.


My point is actually that it's not possible to do that meaningfully past a certain (rather modest) level of complexity and reuse. How does a library like openssl meaningfully and thoroughly notify all it's downstream users in Debian, Node, Gentoo, etc. what changes to pay attention to?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: