> It'd be lovely to have that done & tested :-) of course, some > careful > work is needed to ensure that the existing patches are either forward > ported, or checked to ensure that they are no longer needed.
ACK. The existance of those patches already shows the problem I was talking about in my previous mail. Most of the patches are ancient, against ancient versions, completely outdated. Many of them are only quick and dirty hacks for the bundled building (often simply done just because the package's build system was not driven correctly). Folks, this is the typical maintenance hell, I've already seen in lots of commercial/inhouse projects, that most likely come from the unwillingness of certain managers that don't want to invest a few resources in clean long-term solution (and fail to see that such hacks become magnitudes more expensive in the longer run). Just look at any larger former-commercial codebase, Mozilla is also good example for this. Just a sidenote: in one of my recent projects, i've been working on for about a year, we had exactly the same problem. It's a software for medical data aquisition computers und Linux embedded devices. These guys had bundled all the 3rdparty packages (beginning with an *really* ancient kernel, with really dirty hacked patches - up to lots of userland libraries). The build system was utterly complex and untable (when I came in, it only worked on an ancient customized Debian system, which of nobody had backed up ;-o). They completely refused the idea that this mess produces costly maintenance overhead. They claimed that this stuff wouldn't need to be touched, even while we *DID* need to touch it exactly for this tasks I was hired for. And I have real economic numbers on that: on my first weeks I proposed a cleanup and using a generic embedded distro engine (eg. Briegel or PTXdist), would have manpower costs of about 10kEUR. Obviously, they refused and continued the old way. Within that year, this old was produced costs in the scale of 50kEUR (without solving the actual problem, so I guess these costs will come every year, again and again). Well, these jerks were funny anyways: they're using MSVC for coding (via SMB shares) and use Team Foundation Server als source control (more precisely: what they belive in what source countrol would be). I've measured the extra costs compared to git: about 2kEUR per month. cu PS: please forgive me, if I'm a bit too emotional, but I really hate seeing resources burned on nonsense. _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
