Re: What is the most time consuming task for you as packager?

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

 




Dne 16. 12. 20 v 21:56 Neal Gompa napsal(a):
On Wed, Dec 16, 2020 at 3:34 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
On Wed, Dec 16, 2020 at 07:15:21PM +0000, Jonathan Wakely wrote:
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.
You actually can use a side tag, but it's not very streamlined.
1. make side-tag
2. push your changes to a whatever branch on the package that you are
changing.
3. build package from that branch into the sidetag
4. scratch build all the dependent packages in the sidetag and they will
use the changed package. Get them all working.
5. merge your branch back on the package, bump release again
5. actually bump and officially rebuild all the packages in the side tag
6. merge sidetag
7. ask releng to delete the branch you made (or not if you don't care)

But I agree thats not great. ;(

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.
Yeah, all this ^

So I've written tools for doing this, and Igor has written tools for
doing this, but it seems like people think that this is "impossible"
and so the effort goes nowhere despite several PoCs.

If we're interested in this again for real this time, I could try to
dig out my old code for it, but we might be better off just pulling
out Koschei's code and turning it into something that Koji's
chain-build command and Mock's --chain option use to sort through
package sets and build them correctly.

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?
Thats worth considering in the new year. I would like that. :)


I would appreciate if Koschei kept more results. It is almost unuseful these days if one does not have time to check the issue right after it appears :(


Vít


Yes please!




--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
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

Attachment: OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
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