Agree __
On 09/07/2020, 13:48, "Hafnium on behalf of Olivier Deprez via Hafnium" <hafnium-bounces(a)lists.trustedfirmware.org on behalf of hafnium(a)lists.trustedfirmware.org> wrote:
Hi Andrew,
We seem to reach a consensus within ARM that it is something we can enable.
As a slight usage detail, we'd expect developers to use their initials for gerrit topics such a xy/topic-name.
That's already recommended for TF-A, although not always enforced.
This would avoid unintended/accidental merges in different repos because of gerrit topic name clashes.
Does it make sense?
Other folks in the ML, please shout if you disagree (you can also express that you agree 🙂).
Regards,
Olivier.
________________________________
From: Andrew Walbran
Sent: Wednesday, July 01, 2020 11:28
To: hafnium(a)lists.trustedfirmware.org; Benjamin Copeland; Olivier Deprez
Subject: Re: change.submitWholeTopic option for Gerrit
Any thoughts on this?
On Fri, 26 Jun 2020 at 21:21, Andrew Walbran <qwandor(a)google.com<mailto:qwandor@google.com>> wrote:
Hello,
How would people feel about enabling the change.submitWholeTopic option (https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#cha…) for Gerrit?
So far, we have relied on this to ensure that submodule changes get submitted along with the corresponding change to the main repository. Our usual workflow has been that whenever a change is made to one of the submodule repositories, both that change and the corresponding change to the main repository are tagged with the same topic. That way it is only possible to submit either once they have all been reviewed +2 and the main change has passed presubmit. This avoids submodules getting out of sync or changes to them being missed or not properly tested.
However, it looks like this is a per-host configuration option rather than per-repository, so it would also affect the other Trusted Firmware projects using the same Gerrit host. Are there any other uses of topics there which would conflict with this config change?
(If there are other people who might have an opinion on this please add them to the thread.)
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
Hi Andrew,
We seem to reach a consensus within ARM that it is something we can enable.
As a slight usage detail, we'd expect developers to use their initials for gerrit topics such a xy/topic-name.
That's already recommended for TF-A, although not always enforced.
This would avoid unintended/accidental merges in different repos because of gerrit topic name clashes.
Does it make sense?
Other folks in the ML, please shout if you disagree (you can also express that you agree 🙂).
Regards,
Olivier.
________________________________
From: Andrew Walbran
Sent: Wednesday, July 01, 2020 11:28
To: hafnium(a)lists.trustedfirmware.org; Benjamin Copeland; Olivier Deprez
Subject: Re: change.submitWholeTopic option for Gerrit
Any thoughts on this?
On Fri, 26 Jun 2020 at 21:21, Andrew Walbran <qwandor(a)google.com<mailto:qwandor@google.com>> wrote:
Hello,
How would people feel about enabling the change.submitWholeTopic option (https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#cha…) for Gerrit?
So far, we have relied on this to ensure that submodule changes get submitted along with the corresponding change to the main repository. Our usual workflow has been that whenever a change is made to one of the submodule repositories, both that change and the corresponding change to the main repository are tagged with the same topic. That way it is only possible to submit either once they have all been reviewed +2 and the main change has passed presubmit. This avoids submodules getting out of sync or changes to them being missed or not properly tested.
However, it looks like this is a per-host configuration option rather than per-repository, so it would also affect the other Trusted Firmware projects using the same Gerrit host. Are there any other uses of topics there which would conflict with this config change?
(If there are other people who might have an opinion on this please add them to the thread.)
Hi,
The issue happens because driver/linux/Makefile defines CHECKPATCH with a default script path only if CHECKPATCH is not already set (uses ?= operator)
It works by unsetting the existing environment CHECKPATCH from kokoro/build.sh when invoking the linux driver checkpatch as done here:
https://review.trustedfirmware.org/c/hafnium/hafnium/+/4879
I think that's fine with build dependencies, nothing to change here.
Regards,
Olivier.
________________________________
From: Andrew Walbran
Sent: Monday, May 18, 2020 17:21
To: Olivier Deprez
Cc: hafnium(a)lists.trustedfirmware.org
Subject: Re: [Hafnium] kokoro/build and CHECKPATCH
If there are dependencies missing from https://hafnium.googlesource.com/hafnium/+/refs/heads/master/docs/GettingSt… then please send me a change to add them. I'm curious about pathlib, as it's not listed in https://hafnium.googlesource.com/hafnium/+/refs/heads/master/build/docker/D… either.
We should probably fix the build to ignore any locally set value of CHECKPATCH, as it should always be using the version checked into the repository.
On Mon, 18 May 2020 at 16:01, Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> wrote:
Hi Andrew,
Notice I do git clean -fdx prior to trying CHECKPATCH set/not set, because it looks there's some dependency to local ninja build files.
When CHECKPATCH is set I'm still seeing the issue mentioned earlier.
When CHECKPATCH is not set, I got failures related to missing python dependencies on my ubuntu host (ply pathlib python-git). I don't recall seeing those dependencies listed in Hafnium pages, but that's fair enough. Now the checkpatch step passes by installing those python libs.
Obviously I'm not facing this issue when running through docker hermetic build.
So I guess it's low priority glitch, not sure if it really requires a fix or a notice in documentation?
Regards,
Olivier.
________________________________________
From: Andrew Walbran
Sent: Monday, May 18, 2020 13:32
To: Olivier Deprez
Cc: hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>
Subject: Re: [Hafnium] kokoro/build and CHECKPATCH
That's weird, I haven't seen that before. Running either kokoro/build.sh or 'make checkpatch' locally works for me, whether or not CHECKPATCH is set.
The Makefile in the root directory is setting CHECKPATCH unconditionally, but it looks like the one under drive/linux uses the existing value if there is one. Maybe we should change that?
What error do you get when CHECKPATCH is not set?
On Fri, 15 May 2020 at 18:18, Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> wrote:
Hi,
Is there a known problem around checkpatch when running kokoro/build.sh locally?
I noticed if CHECKPATCH env variable is already set then kokoro/build.sh fails with:
+ export CROSS_COMPILE=aarch64-linux-gnu-
+ CROSS_COMPILE=aarch64-linux-gnu-
+ cd driver/linux
+ make HAFNIUM_PATH=/home/olidep01/WORK/hafnium-upstream checkpatch
<my-own-checkpatch-dir>/checkpatch.pl<http://checkpatch.pl> -f main.c
Must be run from the top-level dir. of a kernel tree
Makefile:43: recipe for target 'checkpatch' failed
make: *** [checkpatch] Error 2
If I unset CHECKPATCH before running build.sh then it fails at the driver/linux check.
Is this something known and/or needing fix?
Regards,
Olivier.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org<mailto:Hafnium@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
How would people feel about enabling the change.submitWholeTopic option (
https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#cha…)
for Gerrit?
So far, we have relied on this to ensure that submodule changes get
submitted along with the corresponding change to the main repository. Our
usual workflow has been that whenever a change is made to one of the
submodule repositories, both that change and the corresponding change to
the main repository are tagged with the same topic. That way it is only
possible to submit either once they have all been reviewed +2 and the main
change has passed presubmit. This avoids submodules getting out of sync or
changes to them being missed or not properly tested.
However, it looks like this is a per-host configuration option rather than
per-repository, so it would also affect the other Trusted Firmware projects
using the same Gerrit host. Are there any other uses of topics there
which would conflict with this config change?
(If there are other people who might have an opinion on this please add
them to the thread.)
