Hi Tom, On Wed, 30 Apr 2025 at 08:21, 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. > > 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.
It would have to be gitlab, I think. The common files in u_boot_pylib would be a bit annoying (would need to be a fourth repo I suppose). Yes, I could set up an automatic release instead of typing 'make pip_release', which would be nice. Regards, Simon
