[for people interested in flames]
Le samedi 29 septembre 2007 à 21:18 +0200, Marcin Miłkowski a écrit : > Nicolas Mailhot pisze: > > Le samedi 29 septembre 2007 à 19:07 +0200, Marcin Miłkowski a écrit : > > The set of dictionaries available on a Linux system is not what OO.o > > chooses to bundle or not > > You're wrong in some cases. Sometimes it is - distributors use OOo > sources to build their RPMs. Then let me rephrase: distributions will make their own choice on what they distribute or not, and it does not have to follow the OO.o choice (indeed with other apps like Firefox 3 starting to use hunspell it most probably won't). So your horizon is not limited by OO.o releases > >> in distros that have such an exquisite system is to do it > >> manually. If you think this is better than using DicOOo, you should > >> probably consult your therapist. > > > > And what you don't understand is a distribution an open system and the > > solution to get something to users is to work with distributions not > > workaround them. > > Mind you, I've been using Linux for ten years now and I really think > that all distribution systems need workarounds to get my work done. > [...] So I don't > understand anyone claiming that this works. It seems to work well enough to attract new users and the nature of workarounds is to have them resorbed, not set in stone. But that needs cooperation from upstream suppliers. > > That's a funny argument, it seems I've made the effort to locate your > > list not the reverse. And there are a lot *more* apps distributions are > > interested in than distributions for apps to worry about. > > OO.o is an international project so there are local distros we must > worry about in many countries. The distribution that have been cited so far are hardly local and besides you fix the situation for one it'll fixed itself for everyone. If your argument is "I think I'm right, besides being told the contrary, and I don't have to admit otherwise till every distribution on earth tells me I'm wrong", that's childish and I could easily reverse the argument. > >> I've seen distros that > >> simply install all possible dictionaries. And that's definitely a > >> performance hog for OOo. > > > > And that's an OO.o bug plain and simple so don't expect us to build our > > system around your bugs. > > So don't expect users to use distributions that make their systems > useless in office work. Get real. Get real yourself, the users are expecting stuff to be just installed and just work, having them select at runtime separately from the rest of the system languages is a gross workaround no user is fond of. Besides you've snipped the part where I wrote the distro systems allow selecting languages too. > I cannot fix it myself and I'm not even sure if it still > is there. So you're not even sure the workaround you're so keen on inflicting on everyone is actually needed for something? > > Anyway, to stop the mutual ranting, what distributions expect from a > > component provider is : > > A. an authoritative download source (ftp or http directory) > > There are OOo mirrors with most stuff that is put on the wiki. And distributions have better things to do than hunt them down if you're not interested enough to reference them. > > B. raw material in nice versionned archives > > Not always feasible. Dictionary maintainers in some cases might be even > dead or we lost contact with them. And they'll sue you if you put their stuff in an archive with a number? Get real. Not that distributions can not fake numbers if needed, but that's one more thing that's a PITA about lingucomponent and when you put all the small annoyances together you understand why so few dictionaries are available in-distro. > > C. including licencing statements (in the archives), using well-known > > licenses that don't need analysis > > The bundled dicts are all LGPL. But we'd need to review that. Please do. Distributions care about not being sued for copyrighted work misapropriation. > > D. with if possible detached digital signatures or checksums to verify > > we're distributing the right stuff > > That's feasible. > > > E. feedback channels (mailing list, irc channel, bug tracker) > > Not feasible. You won't meet dictionary maintainers there if that's what > you mean. So problems can not be reported, let alone fixed. No distribution will be confortable with that. > > F. update announce channels (RSS, announce list, whatever) > > That's possible. > > > G. instructions to install your stuff via CLI scripts automatically > > Probably feasible. > > > H. some roadmap info so we know how your release schedule fits in ours > > Dictionary releases are not centralized. They are @ lingucomponent. Coordinating is your job, if you want to be more than friendly wiki space. > There is no roadmap and there > cannot be. Nobody but the maintainer for the Malayalam can know when a > release is ready. But you can ask him and publish the info. > > > F. all this on a nice easy-to-find webpage not something lost in a > > website maze > > This is possible. > > To sum up: in some cases, we have abandoned stuff we cannot update or > anything as maintainers are unknown or unreachable. So what you want is > something that cannot be even in the offing. I mean we accept open > source work but you cannot expect me, for example, to fix a Kashubian > dictionary. So we cannot simply do that for many languages. > That's why > we need a system that allows you to accept the license (if it's not > LGPL), download the stuff, and install it. That's why you *think* you need this system, none of your arguments are even remotely compelling to distro ears, we've all heard them before and they were as wrong then as they are today. For examples of how it ends, see the AMD open driver statement or the SUN openjdk statement. And they didn't use a half-hassed macroified system as distribution method. > If you can do this for Adobe > Flash Player, you can do that for OOo dictionaries. And that's the root of our contention. You consider this mode "natural", our users don't (a large part won't install the flash player manually, or hate doing it, especially on enterprise networks). As long as you strive emulating Flash you'll find yourself moaning about lack of distribution support. > The nice thing is that in the near future, hunspell will replace myspell > in Mozilla projects. This means that Firefox dictionaries will be > exactly the same as in OOo. This means the distros will have another hunspell dictionnary source hopefully better organised than lingucomponent (not that we really want to have two sources, but we'll gladly dump the less reasonable of them if we have a choice) > We could think of a common framework for distribution. Distribution is what distributions do and they started work on this about a year ago, so you're late. > Anyway, you probably don't distribute Firefox spelling > dictionaries, do you? We do for the major languages, We will do more with firefox3. We could do them all if the dictionary hosting project was more helpful instead of worrying about stuff we don't and won't use. > Let's reuse the solution as these are the same > files (in most cases, anyway, they are the same even now, the only > exceptions being those dictionaries that use advanced hunspell stuff). > As far as I remember Firefox people require me to click the website to > install an extension for every dictionary so that's not really bundled > in a distro, right? The firefox system is a problem too BTW but at least being done by browser people it has some security built-in and does not fall apart on the first non-trivial network config it encounters. With firefox3 modifications distributions asked for will permit installation of firefox extensions through normal distro packages, so the major distros will just distribute the most popular extensions directly and users won't have to ressort to the firefox manual installer. > > To take a non-software example the DejaVu project (dejavu.sf.net) has > > all this right and it got itself distributed by pretty much everyone in > > a short span of time (one of the stragglers being OO.o BTW which still > > has not realised Vera development stopped years ago) > > Fine. But mind you, fonts are easier to maintain than dictionaries. You have no idea what you're talking about. Fonts cross language boundaries, so you need to coordinate font designers from different countries, they're all over the desktop, you have to get them working on screens with different resolutions, in all the different font backends application use, and users are extremely sensitive to pixel-level defects. > In > most cases, you have more than one per language you can use the font in, > so you can simply select the right licenses, actively maintained ones > etc. It's not that simple in case of dictionaries. You cannot simply > pick the right ones if all you've got is some abandoned but decent stuff... Again this is wrong in particulars and in general. Fonts are harder than dictionaries, distributions are a lot more afraid of font changes than dictionary changes, and yet DejaVu got itself distributed because it did what distributions like without dragging feet. > > OTOH lingucomponent makes it awfully hard to find raw dictionary > > archives, check their version, their legal status, script their install, > > etc. So distributions don't bother, or only for the main languages. > > That's why we bother to make DicOOo work. And it works in most > situations. I'd replace "most" with "some" > Firefox works the same way - as far as I know. I've already explained distributions do not feel a lot better about firefox extensions than DicOOo. But at least the firefox guys know how to code a web client, they understand UI and security, their extensions are hugely popular, they need to plug code not just dictionnary files, so we hate their system less than yours. You could take perl as another example. CPAN has its own direct distribution method. But you know, 90% of linux users get their perl through distro packages instead. And the CPAN guys mostly understand it, they don't try to push everyone to their direct download system, they help distributions distribute their stuff in deb/rpm/whatever form, and everyone is happy. > So who's to blame? I'm not interested in blame though I know where it lies. I'm interested in improving user systems. Someone asked what distribution though of the problem. I've answered. If it was a rhetorical question and you've no intention of actually listening to distributions I apologise for wasting your time. Distributing is the heart of what distributions do and you won't change their opinions on the subject. (And trying would require contacting every distribution separately BTW). -- Nicolas Mailhot
signature.asc
Description: Ceci est une partie de message numériquement signée
