On Mon, Apr 20, 2015 at 9:13 PM, Mads Kiilerich <m...@kiilerich.com> wrote: > On 04/20/2015 06:51 AM, Thomas De Schampheleire wrote: >> >> On Sun, Apr 19, 2015 at 4:38 PM, Mads Kiilerich <m...@kiilerich.com> >> wrote: >>> >>> On 04/19/2015 05:57 AM, Thomas De Schampheleire wrote: >>>> >>>> I guess this is a place where a global configuration could make sense. >>>> :-( >>>> >>>> It would be nice to show everything everywhere but especially in the >>>> tables >>>> with commits that is not an option. >> >> Currently: >> - pull request author: username (full name) >> - pull request reviewers: full name >> - pull request commit overview: username only >> - repo summary/changelog: username if user found, else name from commit >> header >> - changeset detail: username (full name) if user found, else name from >> commit header >> (I haven't checked all other places yet, like notifications...) > > > Thanks - a review for consistency has value ... even more so if we can > establish guidelines for maintaining that consistency. > >> I would go for: >> - pull request author: full name (username) >> - pull request reviewers: full name (username) >> - pull request commit overview: username only >> >> For changeset/changelog displaying, I'm not fully sure: suppose >> someone uses the same e-mail to commit under two different display >> names, for example 'John Doe' and 'John Doe (scripted)'. In this case, >> one would probably expect the name from the commit header to appear in >> the changeset/changelog details. >> But the correlation to the actual user as known in Kallithea is also >> useful, so we should show that too, at least in the changeset details. >> In case both the name in the commit header, and the name known to >> Kallithea is the same, there would be some duplication if we show >> both, though. Maybe we should show both but clearly indicate that one >> is coming from the commit header and the other (if available) is the >> detail from Kallithea. > > > Currently we always use the user entry and show the username if the email > address is known (and we allow the system to email the user - we will never > spam users / email addresses that are unknown to the system). I think that > is fine. If the user wants to commit under different names, he should use > different email addresses.
While I understand your reasoning, it doesn't work in a corporate environment where you have only one e-mail address and no easy way to create aliases. I'm not saying that e-mail address should no longer be unique in Kallithea. I'm just saying that if a user commits with a name different than the name in Kallithea (under the same e-mail address) we should not ignore that or hide it in Kallithea. > >> So then we'd have: >> >> - repo summary/changelog: name from commit header >> - changeset detail: both name from commit header as full name (username). >> >> For other places that I did not identify above, 'full name (username)' >> would be preferred, unless if there is limited space in which case >> username could be shown alone. >> >> What do you think of that? > > > Looks fine ... except that I like that we always use the user entry if the > email address is known and only fall back to the parsed full name if the > parsed email address is unknown. > >> >> >>> Somewhat related: the username and email address will often have a >>> trivial >>> mapping. I would like to get rid usernames and just use email addresses - >>> also for login, perhaps with a config option for a default @domainname >>> that >>> always should be stripped. >> >> I'm not really opposed to that, but it does mean more typing for the >> typical user. > > > In which cases? We have completion for @annotation and reviewers ... and the > typical user will use a domain that will the default for the system and thus > can be left out. I was thinking of @annotation (wasn't aware that it had autocomplete) and login. But it's a non-issue, really. > >> >>> Another thing is the confusion that comes from having separate first name >>> and last name fields. Cultures put given name and family name in >>> different >>> order ... and sometimes people compensate for that in firstname/lastname, >>> sometimes they don't. I thus prefer to have a "full name" field with the >>> preferred spelling of the whole name and something like a "nick name" or >>> "common name" with the name the person usually goes by. (In addition to >>> that, there might be a "need" for having both the "real" name and the >>> name >>> transcribed to a different culture.) This ends up as a completely >>> different >>> problem but it might indicate that it could be relevant to have some kind >>> of >>> configurable template for naming ... or a couple of templates for "short" >>> and "long" name. >> >> I was planning to touch upon that subject in my previous reply, but >> left it out because I thought it would lead us too far :) >> >> Anyway, I think we should keep external authentication databases into >> account: we should be able to map data from such databases into the >> scheme we propose. Our LDAP database does have a separate firstname, >> lastname, a full name and a common name, so this would be mappable on >> your proposal. Note that the 'common name' in our database is not >> following the local convention of 'Firstname Lastname' but is >> 'Lastname Firstname' regardless, and I cannot change it. > > > In that case it is the LDAP admins who made the decision. It is better to > expose their wrong decision that to try to fix it in the vcs system ;-) Agreed. _______________________________________________ kallithea-general mailing list kallithea-general@sfconservancy.org http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
