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.

Regards,
SImon

> > [1] 
> > https://lore.kernel.org/u-boot/caflsztg7-ym0l8uujyn7jpsb1lbvoyo76cuwj+h719mfc97...@mail.gmail.com/

Reply via email to