please hold off on this patch until we do our 2WA release for this week.

please hold off on this patch until we do our 2WA release for this week.

Why would two packages with no dependencies on a single arch affect the rest of the release? I would like to get them in so I can continue to test. Else I can just fork the whole lot and go off and do my own stuff

Why would two packages with no dependencies on a single arch affect the rest of the release?

Unfortunately I am not familiar with those two packages (obviously I've heard of u-boot before, but not familiar with the specific details of those packages). I just feel it would be safer if we waited to merge this until after we did this week's release, which is currently waiting on the next updates run to happen so we can include a security update. Obviously this change only affects aarch64, but we happen to release aarch64 now so if it were to come up DOA then we'd have to revert this change and also wait for the next updates run to happen.

I would like to get them in so I can continue to test.

I understand that. Here are some options:

• We did merge the rawhide PR, so the the next iteration of that should have the changes.
• We could open a new PR to just update the manifest for updates-testing until the release is out.
• You can use the fedora/27/aarch64/atomic-host ref in this tree I just created using this how-to that has your patch applied to it. You can use an ostreesetup line in your kickstart like:

ostreesetup --osname=fedora-atomic --remote=fedora-atomic --ref=fedora/27/aarch64/atomic-host --url=https://dustymabe.fedorapeople.org/pbrobinson-repo/ --nogpg

Hopefully one of those will do.

Else I can just fork the whole lot and go off and do my own stuff

I really don't feel like that was an appropriate response.

Unfortunately I am not familiar with those two packages (obviously I've heard of u-boot

They are firmware in all cases that add files and nothing more to the compose. If it's not running on the specific hardware, all of which are aarch64 SBCs, it has no affect on anything anywhere, it's no different than installing a set of documentation. Without that knowledge it would be easy enough to query the RPM dependencies/contents and see that. They're also shipped by default in the standard aarch64 composes without issues for all other SBSA supported hardware.

Ultimately you might have to trust an architecture specialist that knows the impact of these and trust that the person wouldn't be requesting it without already having a full understanding of the probable impact of this change.

I really don't feel like that was an appropriate response.

It's been a pretty standard response from the OSTree team over the years to rel-eng....

I don't see much risk in this, if something fails we can revert and try again later.

If things do fail, then we'll have to wait for another bodhi updates run (thursday) and another Fedora Atomic pungi run (Friday) to get another candidate for release. We also typically don't like to release on Friday so if that rule sticks then it will be next week before we do a release when most of us will be whirling around Europe. From the point of view of the person trying to make sure we do the release this week, merging this is riskier than waiting a day.

If things do fail, then we'll have to wait for another bodhi updates run (thursday) and another

Literally the only way this could fail is if there's not enough space on the images for the extra storage (30684076 + 1325786 + 12508912) which is about 40Mb

Fedora Atomic pungi run (Friday) to get another candidate for release. We also typically don't like to release on Friday so if that rule sticks then it will be next week before we do a release when most of us will be whirling around Europe. From the point of view of the person trying to make sure we do the release this week, merging this is riskier than waiting a day.

Sure, and if I can't consume this basically it leaves us from doing a release for those devices until probably late February (I'm traveling for the next 3 weeks which basically means we miss the next 2-3 twoweek cycles). I can test all this stuff locally myself without it being in the tree, what I can't do until it's in the tree is test any of the pungi/koji/imagemagic stuff which would create images that other people could use and test in the interim without me documenting and holding people's hands through a manual process.

good news. testing looks promising for tomorrows release. merging this in anticipation of that happening.

good news. testing looks promising for tomorrows release. merging this in anticipation of that happening.

So when will this land in a tree I can consume with imagefactory?

So when will this land in a tree I can consume with imagefactory?

For official f27 it will be in the next bodhi update run that happens. For rawhide it's already there: logs. Or you could use the f27 aarch64 repo that I created late last night for you just so you could get unblocked:

ostreesetup --osname=fedora-atomic --remote=fedora-atomic --ref=fedora/27/aarch64/atomic-host --url=https://dustymabe.fedorapeople.org/pbrobinson-repo/ --nogpg