On 11/06/14 17:30 -0400, Andy Grimm wrote:
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
See also `git checkout --orphan`
Attachment:
pgpEuc5WfdQPc.pgp
Description: PGP signature