On Wed, 30 Apr 2025 at 15:32, Tom Rini <tr...@konsulko.com> wrote: > > On Wed, Apr 30, 2025 at 07:54:11AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Tue, 29 Apr 2025 at 08:53, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Tue, Apr 29, 2025 at 08:35:24AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Tue, 29 Apr 2025 at 07:48, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > > > On Tue, Apr 29, 2025 at 07:21:57AM -0600, Simon Glass wrote: > > > > > > > > > > > This series moves patman to use asyncio instead of > > > > > > ThreadPoolExecutor > > > > > > since it makes it easier to handle requests sent from different > > > > > > parts > > > > > > of the code. > > > > > > > > > > > > It also includes some updates to bring patman in line with the other > > > > > > major Python tools (buildman and binman). > > > > > > > > > > > > With this series, we have a better basis to add support for syncing > > > > > > more > > > > > > data from a patchwork server. > > > > > > > > > > > > After this, the next step it to add a new 'patman series' > > > > > > subcommand, to > > > > > > track and manage series workflow. > > > > > > > > > > This conflicts with master, please rebase this if you intend for it to > > > > > be merged to mainline. > > > > > > > > I will take a look and see what patches my tree is missing. > > > > > > > > > And to avoid confusion, while I think managing > > > > > these python projects in this manner (and not AFAICT following python > > > > > best practices) makes life harder for everyone else, that is not me > > > > > NAK'ing taking more patches, I continue to be compromising and "Saying > > > > > Yes" to things you do that I disagree with on non-arbitrary technical > > > > > grounds. > > > > > > > > I'm open to managing them in my tree if that helps. For now it seems > > > > like too much work to manage them separately, but if someone wants to > > > > volunteer to help, I could do it. > > > > > > Again, if you won't manage them standalone as seems to be normal best > > > practice, > > > > I wonder whether that was intended to throw shade at my approach, but > > if so I'll let it go. > > > > Anyway, I don't completely understand the best-practice argument, > > although I am open to it. It is extra work to set up CI, etc, but > > probably not a huge amount. If I get keen one day perhaps I will take > > a look. Just so many things on my plate already, as you know. > > I'm the one who approved putting all of these tools in the main > repository initially. And I've griped in public more than once about > Python (not, you, Python) being less than ideal at times due to seeingly > ever-shifting best practices. I however make the "Python best practices" > argument because if we want to attract more developers to help with a > thing, we need to develop the thing following language specific best > practices.
I believe having the tools in their own repos outside of the U-Boot repo makes sense for many reasons. A few that come to mind: 1) Tools like patman are generally useful tools on their own outside of U-Boot 2) they're more easily consumable for non U-Boot stuff 3) they're more easily discoverable 4) if they're python they're easier to push to pypi and hence installable via pip (see also option 3) 5) easier to maintain, releasable independently, easier to deal with CVEs etc 6) build a community independent of U-Boot (see option 3) > And I honestly believe it would be *less* work for you overall since > there's countless tutorials on setting up all of the automated CI/CD > stuff and you could just put it on public git forge and use their > regular CI/CD flows. Especially for python projects where things like github actions and the like enable things like automated publishing on tagging etc, you can get automated vulnerability scanning etc and most of the CI setup is a one off task.
