till reported a new issue against the project: `releng` that you are following:
``
Currently the Final Freeze is the deadline to remove packages with broken deps in Fedora Branched (see https://fedorapeople.org/groups/schedule/f-26/f-26-releng-tasks.html)
In the past there are still packages with broken deps or depending on broken deps on some architectures that are important for the release. Retiring these packages at the Final Freeze will cause problems for the actual release (examples for F26: java-1.8.0-openjdk, python-etcd). Only skipping these packages from the cleanup process is an error-prone task since there is no canonical list of packages that are important for the release. Also the addition of previous secondary archs to the primary archs created more broken deps. These broken deps could be fixed trivially by excluding the packages from the respective archs but there seems to be too little incentive for package maintainers to do this in time for the final freeze. I see several possible alternatives:
1) Do not cleanup packages with broken deps anymore. This will not cause any direct problems but will cause the distribution to pile up with more broken packages. Also it will create a bad user experience when people try to install packages from the repos and it just fails
2) Remove packages with broken deps at a seperate milestone: This would allow for more time to re-introduce removed packages after cleanup when people discover that they miss them. Possible dates are for example for branching. The downside is that there might be new broken deps at final freeze again. To address this there could be a second round at final freeze.
3) Remove packages with broken deps more regulary. for example whenever a packages has broken deps for six weeks they get retired. This has the advantage that it is a continuous process and therefore keeps the set of affected packages small and distributes the work over a longer period of time. The disadvantages are that there might be less time to fix packages with broken deps and it might be too much work after a mass rebuild breaks a lot of packages. Also we do not yet keep track of how long packages have broken deps. And this might still allow for packages with broken deps to slip into the final release.
Other possibilities are to refine the set of packages that are cleaned-up.
1) We could do this only for packages with broken deps in release blocking archs. This might contribute to people not caring enough about the other archs to actually fix their package there.
2) We could do this only for packages with broken deps in all archs. Similar disadvantage as 1).
3) We could do this only for packages where some criteria on the type of the package fits (e.g. only if is not a leaf subpackage that has a broken deps). This might be hard to express in code for automation, though.
4) Do not do this for packages that are important for the release. This might also be hard to express in code.
Another option that came to my mind would be to change the cleanup method by not retiring the pkgs directly but by orphaning them and then let the orphan cleanup process take care of them eventually. Then other packagers that the original maintainers get a chance to fix the package and the grace period could be easily extended by packagers if they need more time until they get to fix a broken package.
Also we could only retire the actual packages with broken deps and then use the fallout reports to retire the addtional packages with broken deps after a grace period to allow for packagers to remove optional dependencies from their packages. Depending on the grace period this might mean that it might take too long to cleanup branches of packages with broken deps nobody cares about anymore.
Additionally if we continue with cleaning up broken deps it might a good idea to also notify the owner of packagers that depend on packages with broken deps more often about their package possibly being affected. For example when python-etcd has a broken dependency, the maintainers of custodia and freeipa did not get as many notifications as the python-etcd maintainres. However, daily notifications for all depending packages might also be too much when packages such as java get broken.
I am currently in favor of doing more regular cleanups to distribute the workload of the full development cycle with additional cleanups at important milestones. I am not yet decided about which cleanup procedure I would favor (direct retirement vs. first orphaning) and whether to direclty cleanup depending packages as well.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6877
mohanboddu opened a new pull-request against the project: `pungi-fedora` that you are following:
``
Setup for fedora modular 26 final RC
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/290
ralph opened a new pull-request against the project: `pungi-fedora` that you are following:
``
Use TLS when talking to PDC.
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/277
ralph opened a new pull-request against the project: `pungi-fedora` that you are following:
``
A target for modular images.
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/289
mohanboddu opened a new pull-request against the project: `pungi-fedora` that you are following:
``
Setup for Fedora Modular 26 RC 1.3 final
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/288
ralph opened a new pull-request against the project: `pungi-fedora` that you are following:
``
Add a qcow and raw image build for the modular server.
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/287
ralph opened a new pull-request against the project: `pungi-fedora` that you are following:
``
Specify the correct variant in the image_build phase.
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/286
mohanboddu opened a new pull-request against the project: `pungi-fedora` that you are following:
``
Setup for F26 Modular Final 1.2
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/285
dustymabe opened a new pull-request against the project: `releng` that you are following:
``
prepare push-two-week-atomic for f26 first release
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/6897
ralph opened a new pull-request against the project: `pungi-fedora` that you are following:
``
Set global_version appropriately for the modular compose.
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/284