On Fri, 2017-06-23 at 13:26 -0400, Colin Walters wrote:
On Fri, Jun 23, 2017, at 10:12 AM, Krzesimir Nowak wrote:Storing it in commit metadata means that the collection ref is signed as a part of the commit, so we can trust it from the start. But it also means that we need to specify the collection ref from the beginning and it can never change (that would change the commit's checksum) - that makes the --orphan flag a whole lot less useful. Also it is not fine when ostree refs have discontinuous history (ref pointed to commit 1, then later it points to commit 2 which is not a child of commit 1, so commit 1 is not a part of ref's history).I've been advocating for doing content and not commit promotion, like https://github.com/cgwalters/ostree-releng-scripts/blob/master/d o-release-tags It does mean commit checksums become a bit less meaningful in general, but I think there's a big difference between "production" repos and transient commits in a testing pipeline that humans may never run. So think storing it in the commit metadata itself is best to so we don't need yet another signature mechanism.
That all makes sense. Are you happy with the fact that putting refs in the commit metadata basically makes `ostree refs --delete` worthless, since those ref references in the commit metadata can never be deleted? I guess we could sidestep that by defining the commit metadata as “the list of refs the commit belonged to *when it was written*” which makes the potential lack of freshness obvious.
1. Do we want to store not one collection ref, but many of them in the commit metadata? I wasn't sure whether we should allow for many collection refs there or rather for one collection id and many refs. Philip argued for the former.Supporting multiple may make sense...though it feels like the use case would overlap a lot with the endoflife rebase?
Not sure how it overlaps much with EOL rebase. With EOL rebase, two branches which were previously separate are merged at one point, and then one of them dies. So there’s only going to be at most one commit which is on both branches (and, more likely, zero commits, since the EOLed branch will end with an empty commit containing the rebase metadata). Support for multiple refs in the commit metadata is more about the situation where a series of commits belong to two branches. For example, when branching off a version, there might be several commits which are shared between $version_branch and master before they diverge. Is that realistic use case?
2. As a part of the metadata we store the timestamp, which tells when this particular piece of metadata was modified. I guess that the only useful check we can perform with it is to compare it with the timestamp from the older detached metadata of the commit (if we had it before). Anything else comes to your mind?This and below aren't necessary if the metadata is inline, right?
Correct, I think. Philip
3. I wasn't sure if we want to bail out when the detached metadata is invalid or just skip this commit. Bailing out is easier, so this is what I went with for now. 4. If we set the collection ref for a commit, should we also set it for all its parent commits too?_______________________________________________ ostree-list mailing list ostree-list gnome org https://mail.gnome.org/mailman/listinfo/ostree-list
Attachment:
signature.asc
Description: This is a digitally signed message part