Learn more about these different git repos.
Other Git URLs
My message to the mailing list didn't get a response so moving to a pagure issue and tagging with meeting keyword.
I've been told recently that we can use include statements within pungi to include variables/definitions in other files into our current configuration file we are working on.
Can we start to use this model for our pungi-fedora repo? One example is that the fedora-atomic.conf file has a bunch of configuration at the top of it that is very cryptic to know what's relevant to atomic host image/iso creation and what is not. It would be much better if, for a particular branch, we can have a file that has most common definitions in it for all pungi configs for that branch. Then we can make the individual pungi configs much more lightweight and less confusing.
If this is acceptable we can start with the Rawhide branch and when we branch for future releases this will propagate.
By the way the test compose that compares yum and dnf resolving is using the include statement to change a single option from regular rawhide: https://pagure.io/pungi-fedora/blob/master/f/fedora-dnf.conf
Metadata Update from @mohanboddu: - Issue tagged with: meeting
To add some clarity, I am roughly proposing that we do something like this: take the top part of fedora.conf and put it into a global config file for the entire branch. We then include that global config file in all other files: fedora.conf, fedora-atomic.conf, etc. and only add in extra config that is not in global or tweak parts of the global config that we need to override before adding in the parts that tell pungi what to do like image_builds, live_media, live_images, ostree, ostree_installer.
fedora.conf
fedora-atomic.conf
image_builds
live_media
live_images
ostree
ostree_installer
It was also requested that we get the include functionality of pungi documented. I have opened a request for that here.
include
@dustymabe I would like to see exactly what you are proposing in the form of a PR, with enough description so that it ca be managed going forward. Better would be a SOP for updating the configs. to use or not use includes was never a conscious choice, as its not documented we started with a single config I wrote and organically grew from it. I am all for making things better, I am honestly not 100% sure what you are wanting even still. We likely want to keep complete configs for Alpha, Beta and Final as we currently have no way to know what was used outside of the unique files.
14:44 < dgilmore> #info waiting on a PR from dustymabe to show how he would like to see things changed
Metadata Update from @ausil: - Issue untagged with: meeting - Issue assigned to dustymabe - Issue tagged with: f27
yes, please, for the love of god, do this.
@dustymabe, what's the latest on this ticket?
still would like it to happen as I think it would make things easier to maintain but I don't have any time to put into it. I think @mohanboddu and @kellin would get benefits from it, but we can close this if they want.
@kellin suggests we put this into an RFE and schedule it. Idea is to convert one a month. Slow and steady and get it done.
@mohanboddu reports that this will help but it's a lot of restructuring. He doesn't have time to work on this at the moment. It would be less work if this ticket is resolved before F30 branching on Feb 19, 2019. However it is unlikely he'll get to this by then.
@humaton will talk to @mohanboddu about this.
Metadata Update from @syeghiay: - Issue untagged with: f27 - Issue tagged with: meeting
From our grooming discussion on #fedora-releng channel on Apr 12 2019
proposal: close, revisit if we want later
Metadata Update from @mohanboddu: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @mohanboddu: - Issue status updated to: Open (was: Closed)
Metadata Update from @mohanboddu: - Issue close_status updated to: Get back later - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.