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/ >
