Re: Few Fedora 20 ProjectAtomic VM questions

[Andy Grimm <agrimm gmail com>]

On Wed, Jun 11, 2014 at 4:54 PM, Colin Walters <walters verbum org> wrote:
> One other thing to say here is that from discussions with rel-eng type
> people, I think it's clear that most organizations wouldn't want to
> redistribute the entire internal compose history.  And most likely, no
> history at all, i.e. the commits don't have parents.
>
> So the way it would work is that the organization *internally* has a
> repo that's composed as quickly as possible as new git commits come in.
> You could think of this as the "QA/QE" repo.
>
> Then when the software reaches a stable point, those same binaries are
> pulled into a separate "release" ostree repo, and rpm-ostree at that
> point would be configured to make a commit with no parent.  (Such a
> command line option doesn't exist, but could be easily added)
>
> The client doesn't follow history at all by default, so not having a
> parent is fine, it just wants a newer timestamp.
>
> There's a lot of potential though for better tooling around that
> internal QE repo and having the client download the internal history -
> that's where I see yet-to-be-written tools like "ostree bisect" coming
> in.
>
> Fedora of course as a public FOSS project doesn't have this
> internal/external distinction, but even then I think the QE/release
> repository distinction would make a lot of sense - while the QE
> repository might be public, it shouldn't go to mirrors by default I'd
> say.

The analogy may not be 100%, but you basically just described the
purpose of "cvc promote" in conary repositories.  Users typically had
devel/qa/release branches, and only "promoted" certain versions from
one branch to the next.  Usually only the release branch was published
to mirrors; promoting every devel commit would have been far too
expensive.  Definitely a valuable concept.

Andy