This is a matter of style isn't it?

I'd rather get https://pagure.io/packaging-committee/pull-request/903 in first.

I'd rather get https://pagure.io/packaging-committee/pull-request/903 in first.

They don't conflict.

This is a matter of style isn't it?

rpmbuild doesn't care, so it's certainly a matter of style only. Nevertheless, I think the change is warranted: most python packages now build python3, and this means that the BR "for the python3 subpackage" are really BRs for the whole package. And if we suggest to people to put BR:python3-devel there, they'll most likely put other BRs there, so there'll be BR:gcc, BR:some-other-tool there. I think it's better to the BRs at the top.

Can I get some kind of decision here? Yay or nay on each of the two paches. This isn't important enough to keep open forever.

python: recommend %{expand:} trick to avoid duplicating description - +1 from me
python: move BuildRequires to the top - I abstain. I like them where they are but I don't mind them at the top

I know it is bikeshedding, but I prefer subpackage-specific buildrequires in subpackage section (like python3-devel) and things like gcc on top. But that's just my preference.

Using expand trick is definitely +1.

prefer subpackage-specific buildrequires in subpackage section (like python3-devel) and things like gcc on top.

In general, I'd agree. But in python packages we have the unusual situation that the "main" binary package name is always different from the srpm name. Splitting the BR in two would mean that there would be two BR blocks, even though there's (often) just one binary package.

Pushed the description commit as https://pagure.io/packaging-committee/c/1812431136db0e8caf315614e0ccf0b164545baf?branch=master