[For people interested in fixing the dictionary situation under Linux – in a separate message because most people will have ignored the flaming]
Here is my last-ditch effort to detail what distributions – every single Linux/BSD distribution – expect of a project like yours. I defy you to find a single distribution person that thinks otherwise. That's the conventions distributions are geared around, that's what makes material hit Linux user systems the fastest: A. Create consolidated raw material release archives : 1. regroup all the jumble of files on your wiki in a single archive 2. if you have material with different stability level (stuff that can be installed everywhere, alternative versions most people don't want, stuff terminally broken you keep in the hope someone will fix it), split this archive under those lines 3. if you have stuff under different licenses, split again so every archive has material under the same license. Put the authoritative license text of each archive inside it in a COPYING file (and use well-known licenses not something that needs a six-month trip to legal to be checked) 4. tag each archive with a release number, and increase the number next time you change them (ex: foo-x.y.z.zip, bar-a.b.c.tar.bz2) B. Publish them 1. choose a reference long-term ftp directory or indexed http directory 2. put world-readable archive files there 3. add detached checksums/digital signatures so people can check they've downloaded the right files 4. do not remove old archives after an update. If you want to separate the current release, use another directory with just this release in it, but keep the directory with all past and present release files C. Announce them 1. have an RSS feed with new releases, send announcement messages on a dedicated mailing list when you release a new file, put the info on the center of your home page 2. give people release highlights : what's new in the new release, why people will want it, what change and may have broken since the last release (having a changelog file in the release archives is nice too) D. Coordinate 1. Get your active dict authors agree on the next release date, and publish this date so people can plan against it 2. publish irc/ML/issue tracker channels where distro packagers can reach you, and where they can direct users in case of non-distribution-related problems 3. relay this feedback to dict authors as necessary And that's *all*. Nothing rocket science. A lot of it just boring organisation you lack today and makes lingucomponent a PITA to work with. Take care of this and distributions will take care of mirrors, installer/updater UI, language selection, splitting of the archives to reduce average downloads, license display, etc. Alternatively you can keep on pushing Dictoo. You'll find no distribution help on this front, and just waste the time of everyone involved. -- Nicolas Mailhot
signature.asc
Description: Ceci est une partie de message numériquement signée
