About the calculus for the project
About the calculus for the project
Posted Feb 9, 2012 22:03 UTC (Thu) by landley (guest, #6789)In reply to: About the calculus for the project by marcH
Parent article: A tempest in a toybox
I worked at a place that checked all the source code into horrors like "Accurev", "Rational", or whatever that one beginning with a P is I've blotted out. Starting with a tarball (no history beyond that) and checking in local changes on top of that.
Then the _fun_ ones go on to check the _result_of the build into a _second_ source control system, populated entirely with binaries and tracking the root filesystem layout (or RPM binaries, or whatever they ship).
Impedence matching between the first source control system and the second source control system is entirely ad-hoc. Bonus points if they're different technologies left over from a department merger and/or partial migration that never removed the "legacy" system. (Adding new one in parallel: easy. Removing old one: hard.)
I didn't fight with this stuff in a license enforcement context. I fought with it in a "I'm working a 3 month contract to fix accumulated customer bugs in a legacy system they've forgotten how to _build_. They have partial source code for their product, but no longer have the context it built in and the people who did this moved on years ago" context.
It's lucrative, yet horrible. (I remember a contract at Dell where they paid Red Hat to support Red Hat Enterprise 2 _after_ it was end of lifed because they'd done shared libraries in C++ which did an "extern C" around all their library exports and then returned a pointer to a class instance, so all the funky name mangling changes between gcc versions bit them on the nose and they either had to upgrade bangalore, raleigh, and austin all at the same time _and_ ship a flag day release to all customers (of this funky high-end SAS array diagnostic/monitoring tool) or stick with the old compiler forevermore. They got _into_ that state because nobody had realized the full ramifications of their build. Getting a handle on the real dependencies and reproduction sequence of modern software builds is _hard_, at least when the FSF was ever involved in any way. Grub 2. *shudder*)
The real world is messy. This is not new. You're talking about BusyBox, a project that at one point had FIVE shell implementations that didn't share code. If _we_ couldn't get that cleaned up in the first decade of the project's existence, why the heck are you holding others to a higher standard?
Rob
