On 12/22/2015 11:18 AM, Adam Miller wrote:
On Tue, Dec 22, 2015 at 10:10 AM, Dusty Mabe
> On 12/22/2015 10:41 AM, Adam Miller wrote:
>> On Tue, Dec 15, 2015 at 7:34 PM, Dusty Mabe <dusty(a)dustymabe.com> wrote:
>>> 2 - Can we not overwrite the previous download location with the new
>>> one? I'd prefer for there to be sub directories for each release.
>> I might be reading this wrong but this sounds like two different
>> things. You'd like the same location overwritten *and* different
>> subdirectories populated for each release?
> No, I definitely don't want the same location overwritten. I'd prefer
> to use subdirectories of /stable/ and then update the download links
> on the release page to point to the latest one when we do a release.
It was originally requested from the upstream project atomic team to
just have the stable location be overwritten in-place (which is what
happens now) so that the latest is what is there. We keep old test
composes around but trim off the tail end for storage conservation
because they need to persist for at least a two-week release cycle.
I don't have any real preference as long as we have a policy to ensure
we aren't just collecting data forever. However, I don't have a lot of
motivation to keep older versions laying around when the point of the
Two-Week Atomic is to deliver newer bits more rapidly than Fedora has
Not wanting to keep them around forever is reasonable, but I'd say for
a particular release it would be fine to keep the 2-week-atomic
released images available for the duration of that release.
I am curious what the motivation behind wanting old releases around is.
Various reasons. If we just found a critical bug in the last released
Atomic it would be nice to easily go back. If we overwrite the
download location then that is a lot harder to do.
Some people also like sticking to a baseline. so they may choose the
atomic host that was released every month and not every two weeks. So
if we overwrite the download location, after two weeks their download
link is broken. They can still get "back" using `ostree deploy`, but
that is a pain in the ass in a cloud environment where you should be
just booting what you want rather than having to "boot, deploy, reboot".
I'd also be curious if mmcgrath and/or jzb have an opinion on the topic.