On 26/01/21 03:12 +0100, Kevin Kofler via devel wrote:
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
Define common. I have to do 150+ rebuilds about once a year, and every
time I do it I find that 5+ packages are already broken when I try to
rebuild them. Is that "common"?
in particular, provenpackagers should NOT do scripted mass changes. A
Should I run rpmdev-bumpspec 150+ times by hand, and fedpkg srpm 150+
times by hand?
Or will you do those 150+ rebuilds for me instead then? Because if I
can't script it, then it will take much longer, or I'll just refuse to
update my packages ever again.
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.)
Can we make that easier to do?
For example, add a fedpkg command that compares the latest build to
the result of `fedpkg verrel` and tells you if they don't match?
That way I don't have to waste my time figuring out if the contents of
dist-git are already broken/untested, and do that 150+ more times.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
