From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Aaron Lauterer <a.lauterer@proxmox.com>,
Christoph Heiss <c.heiss@proxmox.com>
Subject: Re: [pve-devel] [PATCH installer v2 16/17] fix #5536: post-hook: add utility for sending notifications after auto-install
Date: Wed, 24 Jul 2024 10:24:55 +0200 [thread overview]
Message-ID: <d360b143-d97b-437a-98df-7327961bd590@proxmox.com> (raw)
In-Reply-To: <c5b5a1f9-128f-4bba-b75f-e891287c7961@proxmox.com>
Am 23/07/2024 um 16:57 schrieb Aaron Lauterer:
> There are quite a few preparation changes in other sub-crates
> (auto-installer, installer-common).
> I've only gotten through them for now and haven't looked at the actual
> post-hook crate stuff.
>
> Wouldn't it be nicer to split the preparation patches into their own
> commit? It would make the patch smaller and the history would be a bit
> clearer as we don't mix adding the post-hook crate with all the
> preparation that is needed.
This isn't a binary thing, sometimes it can be nicer to have some
preparatory stuff up-front, most often if it's not only affecting new code
and code changes limited to the thing a patch wants to do, otherwise it can
also be nice to see what is needed to make it work, especially as often
preparatory patches cannot be reviewed in isolation anyway and one needs to
look into the patches that they're preparing for anyway to actually be able
to determine if the thing as a whole makes sense the way it's implemented,
split and used.
As mentioned, this is often subjective, both have some advantages and
disadvantages, IMO the best heuristic is the mentioned "how much is existing
code impacted and how much is this related to the semantic thing the patch
wants to do", all else is a bit of a balance that different reviewers might
also disagree a bit with, so it's also fine to reject a split or merge if
you, as patch author, really think it would make it worse – ideally with
some argumentation and avoiding hard lines to avoid "kerfuffle" or getting
less reviews in the future ;-)
unrelated and definitively not only applying just to you, only as a
gentle reminder: I would like to see that replies on the mailing list get
unrelated stuff trimmed out and use of inline/bottom posting, that makes
it quicker to read and reply and also to digest (longer) threads.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2024-07-24 8:24 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 13:48 [pve-devel] [PATCH installer v2 00/17] fix #5536: implement post-(auto-)installation notification mechanism Christoph Heiss
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 01/17] tree-wide: fix some typos Christoph Heiss
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 02/17] fetch-answer: partition: fix clippy warning Christoph Heiss
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 03/17] common: simplify filesystem type serializing & Display trait impl Christoph Heiss
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 04/17] common: setup: serialize `target_hd` as string explicitly Christoph Heiss
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 05/17] common: split out installer setup files loading functionality Christoph Heiss
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 06/17] common: setup: deserialize `secure_boot` property from runtime env Christoph Heiss
2024-07-23 14:31 ` Aaron Lauterer
2024-08-05 13:12 ` Christoph Heiss
2024-08-19 10:32 ` Christoph Heiss
2024-08-20 14:56 ` Christoph Heiss
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 07/17] debian: strip unused library dependencies Christoph Heiss
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 08/17] fetch-answer: move http-related code to gated module in installer-common Christoph Heiss
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 09/17] tree-wide: convert some more crates to use workspace dependencies Christoph Heiss
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 10/17] auto-install-assistant: replace `PathBuf` parameters with `AsRef<Path>` Christoph Heiss
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 11/17] auto-installer: tests: replace manual panic!() with assert_eq!() Christoph Heiss
2024-07-23 10:39 ` Aaron Lauterer
2024-07-23 10:40 ` Aaron Lauterer
2024-07-23 10:46 ` Christoph Heiss
2024-07-23 11:04 ` Aaron Lauterer
2024-07-23 11:37 ` Christoph Heiss
2024-07-24 7:54 ` Thomas Lamprecht
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 12/17] auto-installer: tests: simplify empty disks check Christoph Heiss
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 13/17] auto-installer: tests: replace `PathBuf` parameters with `AsRef<Path>` Christoph Heiss
2024-07-18 13:48 ` [pve-devel] [PATCH installer v2 14/17] auto-installer: move `SystemDMI` struct to common crate Christoph Heiss
2024-07-18 13:49 ` [pve-devel] [PATCH installer v2 15/17] fix #5536: auto-installer: answer: add `posthook` section Christoph Heiss
2024-07-18 13:49 ` [pve-devel] [PATCH installer v2 16/17] fix #5536: post-hook: add utility for sending notifications after auto-install Christoph Heiss
2024-07-23 14:57 ` Aaron Lauterer
2024-07-24 8:24 ` Thomas Lamprecht [this message]
2024-07-24 11:21 ` Aaron Lauterer
2024-08-05 13:17 ` Christoph Heiss
2024-07-18 13:49 ` [pve-devel] [PATCH installer v2 17/17] unconfigured.sh: run proxmox-post-hook after successful auto-install Christoph Heiss
2024-07-24 11:34 ` [pve-devel] [PATCH installer v2 00/17] fix #5536: implement post-(auto-)installation notification mechanism Aaron Lauterer
2024-08-21 9:41 ` Christoph Heiss
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=d360b143-d97b-437a-98df-7327961bd590@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=a.lauterer@proxmox.com \
--cc=c.heiss@proxmox.com \
--cc=pve-devel@lists.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