On 23.04.25 15:05, Simon Glass wrote:
Hi Mattijs,
On Wed, 23 Apr 2025 at 06:43, Mattijs Korpershoek
<mkorpersh...@redhat.com> wrote:
Hi Simon,
On mer., avril 23, 2025 at 06:28, Simon Glass <s...@chromium.org> wrote:
Hi Mattijs,
On Wed, 23 Apr 2025 at 01:07, Mattijs Korpershoek
<mkorpersh...@kernel.org> wrote:
Hi Simon,
On mar., avril 22, 2025 at 17:39, Simon Glass <s...@chromium.org> wrote:
Hi,
Tom has indicated that he would like Patman to move out of his tree. I
suggested on another thread[1] that I maintain it in my 'sjg' tree, so
here is a new thread to discuss this.
I have already done this for the qemu/efi/coreboot scripts as Tom has
NAK'ed patches for those.
For the other tools there is going to be quite a bit of churn, as I
would like to resolve most of the many Python warnings.
Given the shared source between the tools, it would be easier for me
to do the same for buildman, binman and qconfig. I am thinking that I
might try a move to allow Gitlab pull-requests for reviews on these as
well as the mailing list, if that is useful.
For tools which need to sync back to Tom's tree (i.e. not patman), I
or Tom could do a pull request every now and then, omitting any
changes that relate to pylint.
Please let me know your thoughts. The timing is good as I am going to
be sending out a new Patman feature in the next few weeks and it is a
few thousand more lines of code.
I have a preference for binman staying in the U-Boot upstream (Tom's)
tree. AFAIK, binman is used by the CI and is also very useful for composing
"complex" bootloader images (For example for the TI k3 architecture).
I don't know a good replacement of binman and I'm afraid that people
will go back to ad-hoc scripts if binman gets removed from the tree :(
On the other hand, patman is a workflow tool that's not (I think) that
specific to U-Boot and is (to me) replaceable by b4.
I understand that code sharing makes it more difficult to only move
buildman out of upstream, but in a perfect world, I'd like binman to
stay in upstream.
Just to clarify this, I'm not suggesting removing binman. It's just
the maintenance and development of new features that I'm referring to.
We would still sync source back to Tom's tree.
Got it, thanks.
Wouldn't moving the binman development out of upstream reduce
contributions/visibility?
Or do you think that proposing alternative development process (like
Gitlab merge requests) would attract more folks?
I'm not sure, which is why I am asking about it here, to get feedback.
I like patches on the mailing list myself, but perhaps others don't?
What would be the policy for development/syncing back to upstream?
What happens if binman evolves in a way that's not aligned/practical for
upstream (Tom's tree) ?
Would that mean that we would have to maintain a fork in upstream?
My thinking here is that U-Boot would simply use binman / buildman as
they are, similar to how dts-upstream (91MB), lwip (9MB) and mbedtls
(48MB) work. But yes, if Tom decides that Binman (3MB) / Buildman
(700KB) / other tools (small) have hared off in an undesirable
direction, then it would be tricky.
Regards,
Simon
[1]
https://lore.kernel.org/u-boot/caflsztg7-ym0l8uujyn7jpsb1lbvoyo76cuwj+h719mfc97...@mail.gmail.com/
Which projects beyond U-Boot use buildman or binman?
* If there are none, we should maintain the tools inside the U-Boot
code.
* If there are other uses, we should still keep a copy inside U-Boot to
ensure that we can build U-Boot no matter what the upstream
maintainer decides to change.
Patman is not needed for maintaining the U-Boot project and can be used
for other purposes. Moving it out makes sense.
Best regards
Heinrich
