[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Make GNUN more user-friendly

From: Thérèse Godefroy
Subject: Re: Make GNUN more user-friendly
Date: Thu, 29 Aug 2013 20:08:06 +0200

Le jeudi 29 août 2013 à 15:19 +0400, Ineiev a écrit :
> On 08/29/2013 12:06 PM, Thérèse Godefroy wrote:
>  >
>  > Update doesn't seem to work if the CVS entries don't mention the new
>  > file. But maybe I did something wrong.
> Hm..
> address@hidden:~/co$ cvs -d:pserver:address@hidden:/web/trans-coord co 
> trans-coord/trans-coord.html
> U trans-coord/trans-coord.html
> address@hidden:~/co$ cd trans-coord/
> address@hidden:~/co/trans-coord$ ls -a
> .  ..  CVS  trans-coord.html
> address@hidden:~/co/trans-coord$ cat CVS/Entries
> /trans-coord.html/1.3/Fri Mar  8 11:25:38 2013//
> D
> address@hidden:~/co/trans-coord$ cvs up .symlinks
> U .symlinks
> address@hidden:~/co/trans-coord$ ls -a
> .  ..  CVS  .symlinks  trans-coord.html
> address@hidden:~/co/trans-coord$ cat CVS/Entries
> /trans-coord.html/1.3/Fri Mar  8 11:25:38 2013//
> /.symlinks/1.1/Fri Feb 13 11:56:41 2009//
> D

It means that the new files have to be specified, whether with up or co.
I can't just do "cvs update" as usual, hoping naively that the new files
which are not tracked yet will be updated.

> I'm used to think that translations exist for the site; there may be
> people who work on translations primarily for different reasons, but
> it is disputable whether we should support such users (rather than
> make it easier to do a complete validation for all people who need
> validation, for instance).

With that sort of approach, there would be no French translation of
recent articles, except for a few very short pages that I translated
myself. Anyway, I am usually the one who turns the new translations into
POs, so there is no problem for the time being.

> This works in a different way: GNUN's cron job sends a message
> to the relevant list.  in theory, the same could be done with
> the translations staged in team's repository.

If you want GNUN to detect all the validation errors on site and send
emails, that's fine. But I see this as an unnecessary load on the server
because the same file has to be processed twice. Small load, I grant
you, but the way it is now -- the server is nearly blocked at times, for
whatever reason -- it may be a good idea to start getting thrifty.

> Autotools are needed to prepare a GNU Coding Standards-compliant
> distribution tarball (strictly speaking, they are not needed,
> but in practice it's the tool to make the job feasible).

Of course, but the packages that non-geeks install on their machines are
"binary" (meaning ready to install with dpkg, rpm, yum or whatever).
Very few people get the sources, even tho they are available.

> do you mean maintaining a Debian-type package?
> If yes, then it is a different activity (from maintaining
> the "upstream"), and it is typically done by other people.

Of course. I am not saying that it should be done, but that it can be

> I can't tell whether it has ever been done by anybody, I think it
> hasn't, because GNUN user base is very small, and such a package would
> only cover a part of it (it might even not cover all major Debian
> derivatives), so there would be little useful result.

Making a package from GNUN's sources isn't that difficult. I have one,
which will get handy next time I reinstall the system. Of course, it
doesn't quite pass Lintian -- Denis, please turn away. ;) I was just fed
up with the trans-coord folder. Besides, the package only weighs 189kB.

It would probably install correctly on all the recent versions of
Ubuntu, Trisquel, GnewSense, etc., besides Debian (GNU/Linux implied).
And Alien can make an rpm from a deb and vice-versa.

> I wouldn't call it pure, though: if it were pure, it would
> avoid running the editor twice.
Most of the time, the editor runs once: the configuration file only
shows up the first time the script is run, and Git doesn't display the
editor if one of the 3 messages is choosen (a standard "git commit"
would display it every time).  


reply via email to

[Prev in Thread] Current Thread [Next in Thread]