On Mon, 2 Sept 2024 at 09:51, Daniel P. Berrangé <berra...@redhat.com> wrote:
>
> On Fri, Aug 30, 2024 at 02:22:50PM -0400, John Snow wrote:
> > Gave Dan a related answer. For you, my explanation is:
> >
> > - It's nice to have just one configuration for static analysis in just one
> > place
> > - It's nice to have that configuration follow python ecosystem norms
> > - It's nice to use standard python management tools to configure and test
> > the supported versions of static analysis tools, again kept in one place.
> > - Just moving the folder costs virtually nothing.
> > - Moving it here makes it easier for me to test the eventual integration
> > with make check in one place.
> > - I like being able to say that anything under `python/` is fiercely
> > guarded by high standards (and the gitlab pipelines) and everything else is
> > not. I consider this to be organizationally simple and easy to communicate.
> > i.e., I find it attractive to say that "python is maintained, scripts are
> > YMMV." I am *not* willing to maintain everything under `scripts/` with the
> > same level of effort I apply to `python/`. I think it's important to allow
> > people to commit low-development-cost scripts ("contrib quality") that they
> > can run from time to time and not everything needs to be held to a
> > crystalline perfect standard, but some stuff does.
>
> FYI, I was NOT suggesting that you maintain anything under scripts/.
>
> Rather I'm saying that if we want to apply python code standards, we
> should (ultimately) apply them to all python code in the tree, and
> that *ALL* maintainers and contributors should comply.To be clear up front: this is more of a tangential musing than anything else, and I'm not making a concrete proposal wrt this patchset. scripts/, like contrib/, is a bit of an odd directory structure from my point of view. I don't think something happening to be a script ought to affect where we put it in our source tree -- scripts/ is really more like "tooling used at build time and by developers". If we had a user-facing utility that happened to be written in python or in shell, that ought to go in tools/ I think, for instance. To the extent that our standards are lower in scripts/ it should be because we know that the audience and usage pattern for those utilities is limited and so it's not necessarily worth the effort to bring them up to the standards we'd apply to user-facing code. (Similarly we're a bit sloppier in C code in tests/ than we are in C code that goes into QEMU proper.) IMHO half of contrib/ ought to be in tools/, and for contrib/ I'm particularly not a fan of having a bit of the directory tree that's labelled as "put stuff here that we don't care about". Either we care about it and it should go in the appropriate place in the tree for what it is, or else we don't care about it and it should live out-of-tree... -- PMM
