-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kay Ramme - Sun Germany - Hamburg wrote: [...]
What I wanted to say with the introduction was that I tried to be polite but as there was things you mentioned which are no-no for distributions and you offended all Debian users I needed to make clear I try that but I cannot gurantee it. I wrote that mail in one go. [...] > >>>purposes. Some are for desktop users, some are for generic servers, some > >>>are for specialized purposes like firewalls, application servers or > >>>clustering. Some try to imitate Windows or Mac OS X, some try to get > >>>away from other OSes as much as they can. A lot of changes are made to > >>>give personality to the distributions. > >>That does not necessarily mean, that they need to patch or change > >>anything in the provided products, does it? At least OOo provides > >>extensive configurability to actually change everything, without needing > >>to alter a single line of code. > > > >Of course that does. There's bugs in OOo. Bugs need to be fixed. > >Distributions and OOo have different release schedules. Or: You have > Release schedules shouldn't be the problem, I would expect Debian to > always ship the latest stable version. We can't always. Release schedules is release schedules. For example, we freeze in October, new OOo will come September. I am not sure we will have enough time to get it into the distri. (Building, testing in real-world, all library dependencies must be met etc, various revisions, approval cycles, etc) Or take stable: 1.1.3 is in stable (1.1.4 was released already, yes, I maybe could have gotten that in, but 1.1.3 needed updates first and then it was too late. 1.1.5 was released *after* the sarge release) > >some additions you *need* for whatever reasons. > > > >And you don't build some of the optional stuff. > >You have various UNFIXED security things open (Mozilla to name the most > >prominent one). > Isn't Mozilla providing binaries of products with latest security patches? No. Not for old versions. Just new versions. And the OOo tree still contains mozilla 1.7.5 which you build against (NB: I don't know how your build env looks like) and ship. > >In any case, it is a no-no for a Linux distri to ship binaries you just > >got. > For what reason? Because you can't do source fixes? You can't produce reliable binaries? You can't provide packages for other archs (like we also do ppc and sparc, for 1.1.x there also was s390) > >And not everything is configurable... > So you patch what is not configurable? And what we need for other stuff, too. We also of course patch the configs for our default-configs. We also patch features in if that's sensible or if those features are planned to go upstream some time (KDE stuff, Lockdown, Calc Solver etc) after all, OOo claims to be free software, so changing it is allowed (claims to becausse there's stuff which is *not* free in the tree since loong which outstanding issues for them...) > >That also means that you don't need to ship every lib inside the > >package, bloating it for example. Or you have to integrate with > >distro-specifics (like sensible-browser, run the browser you have > >choosen system-wide in the env or set with the BROWSER envvar, just for > >example, that's a minor one). > This seems to be some kind of system integration, isn't it? Right. > >Or take pyuno. You need a internal python and can't use the systems' > >python modules, not to mention the stuff isn't simply usable by the > >systems' normal python. > Just take a look from an ISVs perspective. Yeah, I know, but you implied wanting every distri getting the rpms from OOo and building their rpms/debs out of that. > >>>3) Corrections - A lot of the work is made to fix problems in the > >>>packaged software itself. Why are such changes not done upstream at the > >>>initial software projects? They are done upstream too, but since it's a > >>>much slower process than a quick fix in the distribution, upstream > >>>corrections are done usually much after the distribution is in the > >>>retail stores. > >>This is understood, but is IMHO the wrong approach and really should be > >>the exception, I think at least we at OOo are very willing to support > >>the distributions to get their fixes merged in upstream. > > > >LOL. I have many counterexamples here where bugs ARE NOT GETTING FIXED > >after submitted. > >I can look for them. > Are you only submitting bugs or fixes as well? When I can fix them I submit fixes as well. But they also didn't get applied.... See for example http://qa.openoffice.org/issues/show_bug.cgi?id=26865 which had an easy fix (ABI change, though, anyway) so it's not a that good example but it was possible to fix with some coordination for a major release like 2.0. I mostly commit fixes myself now when I have some... When I can not there's problems.. But for important functionality bugs or licensing bugs there's still no fix. Issue numbers on request... > >And anyway, you have an other release schedule than distributions. How > >is a distribution supposed to backport bugfixes for their next release > >if there's only binaries you ship and have to wait for a new OOo release > >(which might not fix those bugs after all) although the distris deadline > >is earlier? > AFAIK, we are providing respins of the current major version in regular > (mostly quarterly) intervals. We also provide respins of older versions > if needed. There is IMHO no need to backport any patches, just use the > latest stable version. Ah, suuuure. And then you have another schedule than a distri which wants to release. And at some time needs to set the baseline what will be there and at some time only allow minor fixes only. Would you accept hughe updates at RC phase of OOo? I don't think so. > >What if you need to fix bugs *before* a new version of OOo comes out > >upstream? > I would expect that you just do it like everybody else, stumble over a > problem, find a fix and push it upstream. Or did I misunderstood you? I do. but OOo release can take longer than we need the fix. Sometimes we need it immediately for testing and for the next release > >>>I will cowardly let the Debian guys answer this ;-). > >>Yes, Debianists, please comment ... > > > >I'll do. > >That's complete bullshit. > OK, another comment like this, and you may talk to anybody else ... Well, it's a attack against any person using Debian. > >Debian (and it's derivatives) is a distribution like everyone else - > >dpkg/deb even was there *before* rpm afaik. Even if not, Debian should be > Does that mean anything? > >natively supported, not though alien'ized packages which can have > >arbritrary amounts > >iof bugs through conversion. > It seems that you are somehow personally offended ... Right. Telling Debian people they just should use rpm is broken. There's deb and it's the superiour format... And even if it wasn't deb is the format for Debian so providing debs is the right thing to do. > >There *is* support for Debian in your build system, but you don't enable > >it... > >(Or you at least don't publish the resulting files for deb support) > As I said, there were plans to provide .debs. But, isn't that were. There isn't debs. (Not to mention you renamed the packages so that they are not parallel installable anymore with the official debs, but that's another matter) > uninteresting for you anyways, as you are going to build OOo by your own > anyway? Right. This is just an example. I also care about users which for some reason can't use my debs (yet), you know? Or people who want to test RCs (I don't follow every RC with an upload to Debian although I try to) stable as said has 1.1.3. There's backports of my packages, though, but for different reasons it's at 2.0.1.. Will be updated to 2.0.3 soon, though. > >>>... and we would have the DLL conflicts nightmare in Linux too (see > >>>"Coherence" paragraph) ;-). > >>So, we already have that par excellence ... :-(. Exactly this is the > >>reason, why we (being an ISV) have to bring all this 3rd party stuff by > >>our own, basically being a kind of a mini distro on Linux. > > > >No. > > > >Dynamic libraries under Linux have SONAMEs indicating > >binary-compatibility. The Windows DLL hell is about stuff just named > >.dll without indications about of that. > SONAMEs are fine if used consistently and changed if needed. Right. > >libfreetype6 is an exception, it a long time was buggy iin this respect, > >but bugs appear everywhere, even in OOo. > freetype was just one of many problems ... Which were the others? Regards, Rene -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEoSxm+FmQsCSK63MRAg5fAJ9/ZL5fVJh8VUQdNHH3gW+5z1UJjQCeN0BG 15O160rJK5ticusUAt3TzZs= =ttHk -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
