[releng] Issue #6577 `Fedora 26 mass rebuild`
by Dennis Gilmore
ausil added a new comment to an issue you are following:
``
The mass rebuild will start once we are sure we have all dependencies ready. do you want to ensure that glibc 2.25 was included in the rebuild? if so we have a little time afaik, however your change should have been submitted and ready to go already
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6577
7 years, 3 months
[releng] Issue #6545 `Atomic Host release process is not based on primary
Atomic Host technology`
by Colin Walters
walters added a new comment to an issue you are following:
``
Oh, now I remember the main reason I switched CAHC over to do-release-tags - it was making static delta management easier. We want static deltas between the last release commit to the current. If one does a "retag", the information "what was the previous release commit" isn't stored in the repo. Which means a command like `ostree static-delta generate fedora-atomic/25/x86_64/docker-host` will do the wrong thing.
Now obviously, we could keep this information out-of-band (JSON file, database, or a fedora-atomic/25/x86_64/previous-stable/docker-host ref), and explicitly do `ostree static-delta generate --from PREVIOUS --to fedora-atomic/25/x86_64/docker-host`, but it's messier. And static deltas won't be the only tool that wants to know what the previous stable commit was. Hence I'd still push for do-release-tags.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6545
7 years, 3 months
[releng] Issue #6545 `Atomic Host release process is not based on primary
Atomic Host technology`
by Dusty Mabe
dustymabe added a new comment to an issue you are following:
``
> Basically, do-release-tags will give us different commit history. The main goal of that is avoiding the noise from the devel stream. Most production users won't care about all of the intermediate development commits we make.
> As we move to speed up development (i.e. more than once a day, like we do in CAHC), the "retagging" approach means the commit history on the release branch will get noisier. Whereas with do-release-tags, we don't have that problem.
I agree we don't want noisy history long term so we can work on this for next release maybe. I will point out that until we make it easier for our users to [browse the history of a repo](https://github.com/projectatomic/rpm-ostree/issues/558) then it doesn't really matter that it is noisy.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6545
7 years, 3 months
[releng] Issue #6545 `Atomic Host release process is not based on primary
Atomic Host technology`
by Colin Walters
walters added a new comment to an issue you are following:
``
I'd probably say the lowest risk thing here is to stand up a separate repository and start writing the integration/code that operates on it, e.g. if we we choose to use do-release-tags (and I think we should).
One thing that's really unclear to me is - what process would this be? It's not pungi or fedmsg-atomic-composer, is it? Conceptually it's like a new jenkins job, but we don't really have such a concept AFAIK.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6545
7 years, 3 months