On 15/12/20 23:46 +0100, Miro Hrončok wrote:
On 12/15/20 11:29 PM, Miroslav Suchý wrote:
I am looking for challenges for upcoming year - what I and my team should enhance. I have some ideas, but I want to hear
yours.
Thanks for doing this!
What you - as Fedora packager - find most time consuming on packaging?
Coordination and communication ;)
Where you will welcome more simplicity or automation?
In testing an impact of a change. E.g. a simple "upgrade to newer
version" change might be a problem if it breaks other packages. I
usually spin up a copr repo and try to rebuild every dependent package
^ This.
The individual steps of doing a single package are insignificant
compared to the days or WEEKS it takes for a systemwide change that
requires rebuilding hundreds of dependencies. I know not many of us
actually have this problem, but for those who do, it's very, very time
consuming.
Since we're apparently not allowed to use a side tag to do a test
rebuild for this kind of thing, I end up doing it locally on my own
machines. Copr is another option, but I don't think it would be any
quicker or simpler.
What I'd really like would be a "test mass rebuild" process, where a
prospective package is uploaded and everything that depends on it is
automatically rebuilt (ideally after creating the dependency graph so
each individual package doesn't get rebuilt until its dependencies are
finished building).
Creating the dependency graph by hand is fairly tedious, but maybe I'm
missing an automated way. The point of creating that graph is to avoid
wasting time and power doing and redoing builds that will fail until
something else has been built (which is the problem with mock's
--chain command, if I understand correctly).
Once I have that graph, I use Make to control the process, because it
handles the dependency graph, as well as parallelism, and not
rebuilding things unnecessarily.
in it. However, there are time consuming challenges with this:
1) False failures. Sometimes, the copr build fails for random reason
(Koji repo is not available, etc.). I need to read the logs and figure
it out, resubmit the build.
2) Unrelated failures. Many packages FTBFS for unrelated reasons. I
need to spin up another (control) copr and rebuild all failures there
as well to make sure it's indeed unrelated.
Yes, that's a real pain. Can we just add everything to Koschei instead
of having it opt-in?
3) Cross-related failures. Some packages only fail in the test copr
because they "see" other packages from that test copr and some of them
are different from what Fedora rawhide offers (e.g. because git HEAD
is newer than what has been built in Koji / passed CI in github). I
sometimes need to create more isolated coprs with my change to rule
this out.
Ideally, I'd like to see a CI job for this that handles this on the
background. If you'd like to hear more about the manual workflow, I'd
be happy to meet over video.
(The workflow is heavily based on https://github.com/fedora-stewardship/fedora-stewardship.github.io/blob/master/scripts/review_pr.py
but recently, I prefer the new Copr's dist-git option.)
_______________________________________________
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
