Maintenance of Python tools
Heinrich Schuchardt
xypron.glpk at gmx.de
Wed Apr 23 15:36:47 CEST 2025
On 23.04.25 15:05, Simon Glass wrote:
> Hi Mattijs,
>
> On Wed, 23 Apr 2025 at 06:43, Mattijs Korpershoek
> <mkorpershoek at redhat.com> wrote:
>>
>> 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?
>
> 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+H719mfc97mMQ@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
More information about the U-Boot
mailing list