<puiterwijk> For example: this means we need to maintain every single RPM that has ever went into an ostree commit or people won't be able to re-assemble it. And in the same repo

Personally I'm not concerned about supporting a really long history chain. This depends on the release cadence too...but I don't see a need to by default maintain (and mirror) more than a month (say 4 updates). That's not a lot of data at all, right?

Also of note here is that say for updates-testing it'd probably be fine to just do N+N-1 at most.

Personally I'm not concerned about supporting a really long history chain. This depends on the release cadence too...but I don't see a need to by default maintain (and mirror) more than a month (say 4 updates). That's not a lot of data at all, right?

It depends on who you are. I personally like the history and being able to go back in time. How necessary is it? Not really necessary.

Discussed this in today's releng meeting.

Should we schedule a meeting to kickstart this discussion and get down the baseline of requirements?

@dustymabe @ausil @puiterwijk @mohanboddu @walters @kevin

@mohanboddu reports that jigdo has been renamed to rojig and Releng is waiting on Atomic working group to complete their work.

From our grooming discussion on #fedora-releng channel on Apr 12 2019

[16:21:17] <+nirik> I think this can be closed. It was decided to not go with this, instead use cloudfront in front of our storage
[16:21:23] <+mboddu> Is it rojig now or something like that?
[16:21:35] <+nirik> yes, but we aren't going to use it... so doesn't matter
[16:22:29] <+nirik> https://github.com/ostreedev/ostree/issues/1541 is the upstream discussion I think