On Mon, Jan 25, 2021 at 10:00 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > Hello, > > When we work on rebuilding Python packages with new Python version and when > other provenpackagers rebuild multiple packages at once, I've seen several > problems with packages failing to build from source and/or creating unexpected > breakage in rawhide when built. Usually, some of the following happens: > > > 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. > > > 2. Changes that work but are waiting on external factors > > Packager pushes a breaking change to dist git (such as a soname bump) before > coordinating the change with the dependent packages, not intending to > immediately build it. A provenpackager rebuilds the package for a different > reason (such as a different soname bump), accidentally shipping the > not-yet-wanted upgrade to rawhide. > > IMHO Provenpackagers should not need to worry about this. Commits should land in > dist git only when they are intended to be built (close to) immediately. The > only reasonable exception is when building the pushed changes in a side tag and > even then, packagers should communicate their intentions. > > > 3. Work-in-progress changes > > Packager works on a package. They have a work in progress solution to their > problem, but no time to finish. They push a "WIP" commit that either breaks the > build or produces a broken package. The symptoms are similar to (1) or (2). I've > heard packagers saying "but this is rawhide, this is where development happens, > so this is expected" - I disagree. > > --- > > I'd like to explicitly say that neither of this is considered a good behavior. > I'd like to have a policy that more or less says: > > 1. Packagers MUST NOT push changes that are not considered ready to be built and > shipped at the time of the push. Using Pull Requests (clearly marked as not > ready to be merged) is a better place to present/save changes that are not ready > yet. > > 2. Packagers SHOULD preemptively check if the changes they intend to push work. > At least checking if the intended change builds and the package installs with it > is strongly recommended. In cases where the check is skipped for time reasons > (e.g. when a testing build takes several hours and the changes are urgent), > packagers SHOULD be ready to fix the build/installation failure in timely manner > after it is discovered by the actual build. > > > Before I try to word it more carefully I'd like to hear some feedback on this. > What do you think? > I'm fully in favor of this and I'd really like to see us add some degree of CI gating to support it. _______________________________________________ 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
