RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changel...
== Summary ==
redhat-rpm-config will be updated so users of the auto framework get
automated release and changelog bumping.
== Owner ==
* Name: [[User:nim| Nicolas Mailhot]]
* Email: <nicolas.mailhot at laposte.net>
== Detailed Description ==
This is a system-wide change because all packages build with
redhat-rpm-config, but it only concerns packages that opted to use
this part of redhat-rpm-config (auto framework).
The change will make those packages auto-bump and auto-changelog at
the rpm level, in an infrastructure-independent way.
== Benefit to Fedora ==
Autobumping removes a huge packager shore and makes timestamping in
changelogs more reliable.
== Scope ==
* Proposal owners: The feature is coded and works at the rpm level.
Unfortunately, mock filters away the srpms containing the bump state,
so it does not work in upper layers.
* Other developers: The feature requires buy-in by mock developers
(and probably koji developers) to lift the restrictions that block it
above the rpm level. Also, it requires a mechanism to pass the user
name and email that will be used in bumped changelogs (defining two
variables in ~/.rpmmacros is sufficient at rpm level)
* Mock issue: https://github.com/rpm-software-management/mock/issues/599
* Release engineering: https://pagure.io/releng/issue/9567
* Policies and guidelines: maybe eventually if things work out on the
technical level
* FPC issue: https://pagure.io/packaging-committee/issue/998
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This is a pure build tooling update, it changes how things are built
not what is built.
== How To Test ==
A redhat-rpm-config packages with the changes and some example
packages are available in
https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-aut...
Since the mock/copr layer is currently blocking the feature, you need
to install the redhat-rpm-config and forge macro packages available in
this repo locally. Afterwards you can take any of the example packages
in the repo and rebuild them with rpmbuild -ba to your heart content,
and see the releases bump and the changelogs being updated
accordingly.
To get beautiful changelogs, you also need to add
<pre>
%buildsys_name Your name
%buildsys_email Your email
</pre>
in ~/.rpmmacros
== User Experience ==
N/A Packager experience change only
== Dependencies ==
The change is a spin-off of
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_mac...
Therefore, it depends on the success of that other change and will
probably need rebasing if the code in this other change evolves during
the redhat-rpm-config merge.
It also depends on mock / copr/ koji buy-in and changes, that may add
their own requirements.
== Contingency Plan ==
There is no contingency plan because the change will happen or not at all.
== Documentation ==
There is as much documentation as the average redhat-rpm-config change
(ie comments in the macro files themselves)
== Release Notes ==
N/A Packager productivity change only
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 days, 10 hours
Re: Important changes to software license information in Fedora packages (SPDX and more!)
by Maxwell G
Kevin Kofler via devel wrote:
> Now you have to compare every word of the MIT license
> with the very similar templates such as MIT, MIT-CMU, MIT-feh, etc., and
> then figure out which one it actually is. If it is even one of these and not
> some random mix of several variants (one sentence from here, one sentence
> from there, …).
You're right. MIT/BSD License variants are a pain to deal with. In
practice, they are mostly equivalent, so having to identify is a burden
without a lot of benefit.
Currently, there's MIT variants such as the HPND that aren't even part
of the new license list, despite being explicitly listed on the old list
and being used by packages like libX11[1]. As that license deprecated,
it's not likely to cause issues when importing new packages, but it is
still used by older packages. There are other examples of licenses
missing from the new list that are already blocking new packages[2].
[1]: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/1#note_96957...
[2]: https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/12#n...
> But that is how things work in practice. It is just impossible to read
> through every source file and scan for copied snippets. They can even appear
> in the middle of a file, with the license attached right there. So the
> packager and the reviewer will both check the COPYING/LICENSE/LICENCE file
> provided by upstream, then go exemplarily through a handful source files to
> check that the copyright header and/or SPDX REUSE header matches that
> license, and then declare that as the one License.
This is onerous if you do it manually, but there are tools to make it a
bit easier. You can use scancode-toolkit or licencecheck to scan the
entire codebase. I believe the RH legal folks recommended the former at
some point, but licensecheck is used by fedora-review and actually
packaged in Fedora[^1]. The Legal docs recommend SPDX license-diff[3]
and [4] to see if a certain license text exists in SPDX.
[^1]: I wish luck to anyone who tries to package tries to package scancode.
There are quite a few unpackaged dependencies...
[3]: https://addons.mozilla.org/en-US/firefox/addon/spdx-license-diff/
[4]: https://tools.spdx.org/app/check_license/
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
2 weeks, 1 day