Miro Hrončok wrote:
> 1. Untested changes
>
> Packager pushes a "simple update" to dist git without checking if it even
> builds. It doesn't. Packager has no time to fix this, so they move on for
> now. Or they submit a build but never check if it actually built.
> Provenpackagers who need to rebuild the package need to figure this out
> and fix the problem if it is trivial, or revert the recent commit, when
> the failure blocks them.
>
> IMHO Provenpackagers should not need to worry about this. Changes should
> be at least smoke tested by a mock/scratch build and installation check
> before shipping them.
Requiring to do a scratch build or local build before any change in Rawhide
really does not scale. It takes too long to get anything done in that
setting. It means 1 extra build in all cases (if it takes n build attempts
to get a successful build, your proposed workflow requires n+1 builds
instead of n), which can take hours.
The suggested alternative workflow of using self pull requests (together
with CI on pull requests) also does not scale, it adds a lot of steps to the
process.
IMHO, the real issue is the one Robbie Harwood pointed out: It should NOT be
a common occurrence for a provenpackager to have to rebuild a package, and
in particular, provenpackagers should NOT do scripted mass changes. A
provenpackager should always check what the latest package in Rawhide
actually is before blindly rebuilding dist-git HEAD. (As a provenpackager, I
always do that before I do anything to a package owned by someone else.)
The root cause of the issue is that we have recently had way too many
incompatible changes in the distribution that required mass changing
thousands of packages in Fedora. Changes such as the BuildRequires: make
requirement, the changes to the Python and CMake specfile macros, etc. come
to my mind. Not only do such changes introduce a need for a mass change that
would otherwise not be there, but they also break many third-party specfiles
that the mass-changing scripts cannot possibly catch because they are not in
Fedora dist-git. Compatibility with existing specfiles should be a given.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
