On Tue, Jan 26, 2021 at 4:45 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > 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.) Just responding to this one point (and in light of the parent's post as well).... ...is there a way that the Python bump can be done alongside the usual (and pre-scheduled) mass-rebuild of Fedora packages? I realize Python release bumps are becoming a regular occurrence but I'd rather we piggy-back off an existing deadline (mass-rebuild) than impose other artificial restrictions. I bring this up because, for a week, dogtag-pki was FTBFS in Rawhide (and, your scripts caught it) but I couldn't understand _why_: my local builds were succeeding just fine, it was only remote scratch/non-scratch builds that were failing. It turns out to be a change in my local pki-core (which was installed), but which wasn't yet updated in the dependency in Fedora. This is, admittedly, a case for simplifying PKI's deliverables (and perhaps, make it a single source package), but still: even well-intentioned packagers occasionally get stumped and unknowingly push bad updates. If we instead schedule time around mass-rebuild, I think this would reduce stress for all parties. My 2c. - A > > > 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 _______________________________________________ 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
