Hi Nicolas,
this sounds very reasonable, also for our internal purposes. But this
means we need a volunteer to do a lot of work, including finding some
hosting outside of collabnet. Anyone? (I cannot do that myself, too many
duties already).
Regards,
Marcin
Nicolas Mailhot pisze:
[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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
