On 26. 01. 21 3:12, 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.
That's why it is a SHOULD.
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.
Agreed.
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.)
Well, I understand your sentiment against mass spec changes, but there are
cases, where it currently cannot be avoided (e.-g. when a targeted mass rebuild
is needed for a soname bump). W.g. when we update Python from 3.9 to 3.10 we
will need to rebuild (close to) 4000 packages. How are we supposed to check what
the latest package in rawhide is and how do I act accordingly if it is not
dist-git HEAD? (Also, mass rebuild.)
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.
The root case of this issue is that packagers push broken stuff to dist-git
(knowingly or not) and provenpackagers cannot do what they need to do. It has
nothing to do with adding "make" to BRs (which was absolutely non-invasive and
no builds were attempted). I see your point, but I don't see how "don't make
mass changes" helps with the issue.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
