Maintenance of Python tools

[Mattijs Korpershoek]

Hi Simon,

On mer., avril 23, 2025 at 06:28, Simon Glass <sjg at chromium.org> wrote:

> Hi Mattijs,
>
> On Wed, 23 Apr 2025 at 01:07, Mattijs Korpershoek
> <mkorpershoek at kernel.org> wrote:
>>
>> Hi Simon,
>>
>> On mar., avril 22, 2025 at 17:39, Simon Glass <sjg at 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?

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?

>
> Regards,
> SImon
>
>> > [1] https://lore.kernel.org/u-boot/CAFLszTg7-yM0L8uuJyN7Jpsb1LbvOYO76cUWj+H719mfc97mMQ@mail.gmail.com/