From: Dominik Csapak <d.csapak@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Cc: Wolfgang Bumiller <w.bumiller@proxmox.com>
Subject: Re: [pve-devel] [PATCH access-control v2 1/3] authenticate_2nd_new: only lock tfa config for recovery keys
Date: Fri, 21 Oct 2022 13:38:17 +0200 [thread overview]
Message-ID: <7e1140af-0bf3-ee06-7e07-4749d5095171@proxmox.com> (raw)
In-Reply-To: <04a8f643-cb3f-daf8-480b-240726cec255@proxmox.com>
On 10/21/22 13:29, Thomas Lamprecht wrote:
> Can we *please* get sane commit subject for *human* consumption?!
>
> The worst one, that really triggers me:
>> authenticate_user: pass undef instead of empty $tfa_challenge to authenticate_2nd_new
> Instead of a high level human overview it gives basically another almost
> machine readable diff of the lower level changes. So there's close to zero
> of useful higher level and/or _new_ info in there, but sure makes one stop
> to parse on seeing this in some log.
>
> Copying the method name (nor file module name!) is basically never a good
> idea, especially as tag and especially for (admin) user facing changes - it
> can naturally be OK for library stuff (i.e., dev-only facing changes), but
> even then seldom as start `<tag>:`...
>
> following would allow for a quicker to read, and (granted, slightly
> subjective) better high level understanding of the commits, thus better
> categorizing for when skimming through the log, e.g., in search of relevant
> changes due to some new/questionable/.. behavior; besides that it makes
> d/changelog writing easier.
>
> * tfa: only lock config for recovery keys on authentication
> * tfa: rename outdated $otp variable to $tfa_response
> (this is internal and won't ever make it in the d/changelog so only dev
> readability matters)
> * auth: drop passing bogus challenge variable when checking first factor
> (also internally, dev oriented)
>
> This should be also verified and either amened or commented on by the
> maintainer (planning) pushing a commit/series - while its obviously 1) hard
> and 2) a lot overhead to have a very strict rule book that's fine for a
> partially subjective thing like this, it should be that hard to detect the
> obvious cases, at least for user facing changes.
>
> May look like a small thing to "rant" on, but I spend a lot of time in git
> log et al. and copy pasted method/file names without simple concise tagging
> and for-human info can make it much harder with no benefit for anyone.
>
> Naturally applies to all devs/maintainers not just those in To/Cc here.
yes, you're completely right of course.
i don't think that it's a 'small thing to rant on' at all, i often
looked for commits where a better subject would have made it much more
obvious what is happening and would have been easier to identify
i'll use better commit subjects in the future.
next prev parent reply other threads:[~2022-10-21 11:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-21 8:31 [pve-devel] [PATCH access-control v2 0/3] improve tfa config locking Dominik Csapak
2022-10-21 8:31 ` [pve-devel] [PATCH access-control v2 1/3] authenticate_2nd_new: only lock tfa config for recovery keys Dominik Csapak
2022-10-21 11:29 ` Thomas Lamprecht
2022-10-21 11:38 ` Dominik Csapak [this message]
2022-10-21 8:31 ` [pve-devel] [PATCH access-control v2 2/3] authenticate_2nd_new: rename $otp to $tfa_response Dominik Csapak
2022-10-21 8:31 ` [pve-devel] [PATCH access-control v2 3/3] authenticate_user: pass undef instead of empty $tfa_challenge to authenticate_2nd_new Dominik Csapak
2022-10-21 8:47 ` [pve-devel] applied-series: [PATCH access-control v2 0/3] improve tfa config locking Wolfgang Bumiller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7e1140af-0bf3-ee06-7e07-4749d5095171@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
--cc=w.bumiller@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox