| Message ID | CAJGKYO6YhdJ3GEop7rzvV=P6bOJ1KO3WqNJ+-5rSnUviRAV5gw@mail.gmail.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | [1/1] fixed 2 typos in RECIPE-API-CHANGELOG.md (due to 87d31ee) | expand |
06.12.2022 15:24, Roberto A. Foglietta wrote: > Hi all, > > I sent the patch with elastic mail and probably it went into the spam > folder, so I am manually sending this as well. Best regards, R- > > From ee4b3bb4ddb9825ec8aad30ec4440d4ca5b79db5 Mon Sep 17 00:00:00 2001 > From: "Roberto A. Foglietta" <roberto.foglietta@gmail.com> > Date: Tue, 6 Dec 2022 12:53:46 +0100 > Subject: [PATCH] fixed 2 typos in RECIPE-API-CHANGELOG.md (due to 87d31ee) > > bugfix, typos, documentation > > 87d31ee: add interface to passthrough env vars to sbuild > > Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com> > --- > RECIPE-API-CHANGELOG.md | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md > index 1b8efa5..0bb8338 100644 > --- a/RECIPE-API-CHANGELOG.md > +++ b/RECIPE-API-CHANGELOG.md > @@ -436,8 +436,8 @@ specific bitbake variables as environment > variables into the sbuild environment. > The motivation behind it is to allow the use of external mirrors for > programming languages with builtin > package managers (like rust and go). By that, the variables are also > excluded from the bitbake signatures. > This helps in areas where default mirrors can either not be reached > or provide only little throughput. > -Please note, the forwarded variables do not have to exist. While they > are not forwared in case they do not > +Please note, the forwarded variables do not have to exist. While they > are not forwarded in case they do not > exist, empty variables are forwarded. > > -**Note about reproducability**: the forwarded variables must not have > any influence on the generated package. > +**Note about reproducibility**: the forwarded variables must not have > any influence on the generated package. > This mechanism must also not be used to inject build configurations. > For these cases, templates should be used. Hello Roberto, This changes are ok, but the patch itself is formatted quite badly. There is no need in mention fixed hash (87d31ee) in commit title. On the other hard, mentioning of fixed hash in commit message should be informative to note how it is connected to the current patch, like: Fixes: 87d31ee ("add interface to passthrough env vars to sbuild") It's probably don't mentioned anywhere in the Isar documentation, but commit message is better to be formatted in the form of text (started with a capital letter and ended with a dot), not just a keyword list. One of the keywords can be used as a prefix to the commit title to point the place of changes were done by the patch. In general you can follow kernel patches submitting guidelines that are quite good documented and much more strictly. And once again: please submit patchsets with 'git send-mail'. This will reduce manual work during review and applying, and also will allow Patchwork to generate correct applicable records.
On Tue, 6 Dec 2022 at 14:30, Anton Mikanovich <amikan@ilbers.de> wrote: > > This changes are ok, but the patch itself is formatted quite badly. > the patch has been formatted by git format-patch > There is no need in mention fixed hash (87d31ee) in commit title. > On the other hard, mentioning of fixed hash in commit message should be > informative to note how it is connected to the current patch, like: > > Fixes: 87d31ee ("add interface to passthrough env vars to sbuild") ok, resending in attachment > > And once again: please submit patchsets with 'git send-mail'. This will > reduce > manual work during review and applying, and also will allow Patchwork to > generate correct applicable records. > I sent the patch with elastic mail and probably it went into the spam folder. As explained in this list in the past, Google does not allow anymore to use their smtp via git. Thus, I am using smtp.elasticmail.com but usually the e-mail that I send via that smtp do not arrive in the list but they end up in moderation. So, as far as possible, I did. Please check the following thread about: https://groups.google.com/g/isar-users/c/xC6-QImeLzc/m/1HATZVvVAgAJ Best regards, R-
06.12.2022 18:16, Roberto A. Foglietta wrote: > On Tue, 6 Dec 2022 at 14:30, Anton Mikanovich <amikan@ilbers.de> wrote: > >> This changes are ok, but the patch itself is formatted quite badly. >> > the patch has been formatted by git format-patch > >> There is no need in mention fixed hash (87d31ee) in commit title. >> On the other hard, mentioning of fixed hash in commit message should be >> informative to note how it is connected to the current patch, like: >> >> Fixes: 87d31ee ("add interface to passthrough env vars to sbuild") > ok, resending in attachment > >> And once again: please submit patchsets with 'git send-mail'. This will >> reduce >> manual work during review and applying, and also will allow Patchwork to >> generate correct applicable records. >> > I sent the patch with elastic mail and probably it went into the spam > folder. As explained in this list in the past, Google does not allow > anymore to use their smtp via git. Thus, I am using > smtp.elasticmail.com but usually the e-mail that I send via that smtp > do not arrive in the list but they end up in moderation. So, as far as > possible, I did. Please check the following thread about: > > https://groups.google.com/g/isar-users/c/xC6-QImeLzc/m/1HATZVvVAgAJ > > Best regards, R- I still see commit message "bugfix, typos, documentation" which do not looks good enough. Also please mark updated patchsets as v2, v3, etc. next time.
On Tue, 6 Dec 2022 at 20:56, Anton Mikanovich <amikan@ilbers.de> wrote: > > I still see commit message "bugfix, typos, documentation" which do not looks > good enough. Also please mark updated patchsets as v2, v3, etc. next time. > Please check this patch, please. Thanks for your patience. Best regards, R-
06.12.2022 23:52, Roberto A. Foglietta wrote: > On Tue, 6 Dec 2022 at 20:56, Anton Mikanovich <amikan@ilbers.de> wrote: >> I still see commit message "bugfix, typos, documentation" which do not looks >> good enough. Also please mark updated patchsets as v2, v3, etc. next time. >> > Please check this patch, please. Thanks for your patience. > > Best regards, R- Hello Roberto, Thanks for improving submitting quality. Just one note for the next time: marking patch/patchset version is usually done in the '[PATCH]' prefix, like: [PATCH v3] Fixed 2 typos in RECIPE-API-CHANGELOG.md This can be done on patch generation stage in the following way: git format-patch -v 3 HEAD~1 Or by --subject-prefix="PATCH v3" option of 'git send-email' command.
From ee4b3bb4ddb9825ec8aad30ec4440d4ca5b79db5 Mon Sep 17 00:00:00 2001 From: "Roberto A. Foglietta" <roberto.foglietta@gmail.com> Date: Tue, 6 Dec 2022 12:53:46 +0100 Subject: [PATCH] fixed 2 typos in RECIPE-API-CHANGELOG.md (due to 87d31ee) bugfix, typos, documentation 87d31ee: add interface to passthrough env vars to sbuild Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com> --- RECIPE-API-CHANGELOG.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md index 1b8efa5..0bb8338 100644 --- a/RECIPE-API-CHANGELOG.md +++ b/RECIPE-API-CHANGELOG.md @@ -436,8 +436,8 @@ specific bitbake variables as environment variables into the sbuild environment. The motivation behind it is to allow the use of external mirrors for programming languages with builtin package managers (like rust and go). By that, the variables are also excluded from the bitbake signatures. This helps in areas where default mirrors can either not be reached or provide only little throughput. -Please note, the forwarded variables do not have to exist. While they are not forwared in case they do not +Please note, the forwarded variables do not have to exist. While they are not forwarded in case they do not exist, empty variables are forwarded. -**Note about reproducability**: the forwarded variables must not have any influence on the generated package. +**Note about reproducibility**: the forwarded variables must not have any influence on the generated package. This mechanism must also not be used to inject build configurations. For these cases, templates should be used. -- 2.34.1