Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux