toggle quoted messageShow quoted text
My main concern is there is an easy path for the developers. I don’t want to have developers have to learn new development technologies just to run a “required” tool. I’m not as concerned on how we do it. Hosting binaries from a webpage that auto picks what to download would be fine with me.
I think the important thing is we make this walkup an use, and we write up the instructions not assuming “other knowledge”.
My use case is probably uncommon. We don’t use brew, but there is an internal brew we can use. So we generally just install build tools into our repo. We are more flexible on personal productivity tools so I’d probably consider switching to Visual Studio Code, especially if there was an Extension in the Marketplace I could just click on to configure Code for edk2 development. On the other hand nothing inspires hate like asking people to switch their editor, so I don’t think we can depend on Code as the solution.
Submodule within which repo? What would be the proposed location?Would a fork of uncrustify maintained as a repo under TianoCore work as well?There are CI checks (including extensive unit tests) and release generation that are built into uncrustify repo and I do not know if those will be functional if it is maintained as a submodule.Thanks,Mike
From: Leif Lindholm <leif@...>
Sent: Tuesday, November 9, 2021 4:37 AM
To: Gerd Hoffmann <kraxel@...>
Cc: firstname.lastname@example.org; Kinney, Michael D <michael.d.kinney@...>; Andrew Fish <afish@...>; Marvin Häuser
<mhaeuser@...>; Michael Kubacki <Michael.Kubacki@...>; mikuback@...; rebecca@...;
Bret Barkelew <Bret.Barkelew@...>
Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2?
On Tue, Nov 09, 2021 at 09:40:02 +0100, Gerd Hoffmann wrote:
Hi,the changes can be upstreamed.
3. Require use of uncrustify tool before submitting patch review emails or PRs.
* The required version would be a formally released version from the fork maintained by Michael Kubacki until
Can we please *first* get the changes merged to upstream uncrustify?
That'll make the whole process much less painful because the usual
software repositories (linux distro packages, macos homebrew, ...)
can be used to install uncrustify then, and it's also less confusing if
developers don't have to juggle with different uncrustify variants
(upstream vs. edk2).
Whilst I agree in principle...
This means postponing automated coding style changes until 2023
(Debian stable), 2025 (Ubuntu LTS), ??? (RHEL10), or even later
... and I'd rather not.
I like Marvin's suggestion of a submodule. Which we could drop once
no longer needed.