Re: Bug#588870: gitolite: [debconf_rewrite] Debconf templates review
Sorry for not following up immediately, there is too much going on over
here at the moment.
* Jonathan Wiltshire <email@example.com> [2010-07-12 23:57:37 CEST]:
> On Thursday, July 01, 2010, I notified you of the beginning of a review process
> concerning debconf templates for gitolite.
> The debian-l10n-english contributors have now reviewed these templates,
> and the proposed changes are attached to this bug report.
Thanks a lot - it's really appreciated!
> Please review the suggested changes are suggested, and if you have any
> objections, let me know in the next 3 days.
3 days is a bit short of a timegap when package maintainers are
encouraged to give the translators 10 days. Sorry to have missed that
rather short time frame.
> Please try to avoid uploading gitolite with these changes right now.
> The second phase of this process will begin on Thursday, July 15, 2010, when I will
> coordinate updates to translations of debconf templates.
I would have liked to send out the call myself after having
incorporated the templates. :( I even think to remember that this was
> On Wednesday, July 28, 2010, I will contact you again and will send a final patch
> summarizing all the updates (changes to debconf templates,
> updates to debconf translations and new debconf translations).
I think there is no need for that - translators have to send them my
way anyway, so I am a bit puzzled about this duplicated work of yours?
Some comments on the patch for the templates and the package
> Template: gitolite/gituser
> Type: string
> Default: gitolite
> -_Description: The name of the system user to create:
> +_Description: System username for gitolite:
> Please enter the name for the system user which should be used by
> - gitolite.
> + gitolite. It will be created if necessary, and its home
> + directory will be used to store repositories.
Having this question as a user I would wonder: "and what is its home
directory?" Is this really suggested style that way?
> Template: gitolite/gitdir
> Type: string
> Default: /var/lib/gitolite
> -_Description: The directory to contain the repositories:
> - Please enter the path for the directory in which you want to store the
> - git repositories guarded by gitolite. This will also become the home
> - of the former entered username.
> +_Description: Repository path:
> + Please enter the path in which the gitolite repositories should be stored.
> + This will be set as the system user's home directory.
You have mentioned in your initial response that the text needs not to
refer to the former question because the ordering of the displayed
questions might be different (even though I wouldn't know how debconf
handles that other than what's happening through debian/config). In that
light I start to have the same question as before, but even stronger in
the light of that reasoning for the change: "What system user?"
I fail to see the removal of "former entered" to be clearing up the
> Template: gitolite/adminkey
> Type: string
> -_Description: The key for the admin user:
> +_Description: Administrator's SSH key:
> Please specify the key of the user that will administer the access
> - configuration of gitolite. You can either give the filename or paste
> - the ssh public key. Leave empty if you do not want to set up gitolite
> - in the directory specified earlier.
> + configuration of gitolite.
> + .
> + This can be either the SSH public key itself, or the path to a file
> + containing it. If it is blank, gitolite will be left unconfigured and
> + must be set up manually.
Right, it makes a lot sense to be more explicit with respect to SSH
> - What makes gitolite unique is its dedication: Its primary target is corporate
> - environments where the ability to restrict who can push to what branch is also
> - important. It has grown beyond that initial motivation to write it and
> - acquired several other neat features that you can find described in the main
> - README.
> + Gitolite can restrict who can read (clone/fetch) from or write
> + (push) to a repository, and who can push to what branch or tag - an
> + important issue in corporate environments. Other features include:
> + * access control by branch-name or by modified file/directory;
> + * per-developer "personal namespace" prefixes;
> + * simple but powerful configuration file syntax (with validation);
> + * config files (and authority for maintaining them) can be split;
> + * easy integration with gitweb;
> + * comprehensive logging;
> + * easy migration from gitosis.
I like the change to the description a lot too, just an amusing
sidenote for me: Have received quite some downputting comments for
having taken the upstream description which refered to gitosis in the
ITP, now you are putting it back in. *smirks*
Again, thanks, and if you'd like to comment on the above two questions
with respect to making it more clear for the user and home directory I'd
appreciate that. I hope that this can be solved quickly so that we don't
annoy translators too much who have picked up on your rushed in call for
"Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder
Mensch auch ein Privatleben haben sollte."