From: 15:36:25 <dgilmore> walters: i have it working for the TC/RC process. I need to change up a few things. not yet looked at doing it for rawhide/branched yet
Are there any blockers to setting up the rawhide/branched parts? Anything I can help with? In particular, will these composes write trees to the mirrors?
If we're only doing a tree compose for TC, things are highly likely not to work because it'll be the first time we've run it in prod.
What I'm thinking about for a plan is: Dennis (and any help he needs) work on the mainline rel-eng thread for F21.
In the meantime though, Atomic still needs a mechanism to *try* code that's in development. So I may look at having the internal compose server be a "pull from COPR" type thing and thus be a remix (again), but improve on the current situation by mirroring to dl.fp.org or so.
On Tue, Jul 22, 2014 at 08:07:39AM -0400, Colin Walters wrote:
In the meantime though, Atomic still needs a mechanism to *try* code that's in development. So I may look at having the internal compose server be a "pull from COPR" type thing and thus be a remix (again), but improve on the current situation by mirroring to dl.fp.org or so.
Is Rawhide too divergent, or too fast moving?
On Tue, Jul 22, 2014, at 05:40 PM, Matthew Miller wrote:
On Tue, Jul 22, 2014 at 08:07:39AM -0400, Colin Walters wrote:
In the meantime though, Atomic still needs a mechanism to *try* code that's in development. So I may look at having the internal compose server be a "pull from COPR" type thing and thus be a remix (again), but improve on the current situation by mirroring to dl.fp.org or so.
Is Rawhide too divergent, or too fast moving?
One problem is that Rawhide is still post package review.
For mainline, COPR has been a massive release value for testing inbound code - take the example of etcd that I'm working on right now[1] There are people that are trying to iterate on *actually using* etcd, while I'm simultaneously trying to de-bundle and update the package.
On a mainline system, you can take stock Fedora and add the COPR - it works well.
But for Atomic, the tree has to be composed *as a unit* - and such a tree containing COPR code would then (to my understanding) be required to be a Remix.
This type of thing is yet another reason to support local package layering - the current state is definitely one of the negative tradeoffs for the atomic updates in the current architecture.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1047194 http://copr.fedoraproject.org/coprs/walters/atomic-next/
On 07/22/2014 10:07 PM, Colin Walters wrote:
From: 15:36:25 <dgilmore> walters: i have it working for the TC/RC process. I need to change up a few things. not yet looked at doing it for rawhide/branched yet
Are there any blockers to setting up the rawhide/branched parts? Anything I can help with? In particular, will these composes write trees to the mirrors?
If we're only doing a tree compose for TC, things are highly likely not to work because it'll be the first time we've run it in prod.
What I'm thinking about for a plan is: Dennis (and any help he needs) work on the mainline rel-eng thread for F21.
In the meantime though, Atomic still needs a mechanism to *try* code that's in development. So I may look at having the internal compose server be a "pull from COPR" type thing and thus be a remix (again), but improve on the current situation by mirroring to dl.fp.org or so.
Note that this is also why I'm keen to see a draft compose *somewhere* that we can actually try importing into beaker.fedoraproject.org - so long as it is at least somewhat close to the structure of a regular tree (in terms of Beaker being able to find the kernel and initrd files and be able to generate appropriate netboot files), we should be able to make it available for installation.
Amit also came up with a custom kickstart to let us run the test harness in a container rather than directly on the host, so even though the default kickstarts won't cope with Atomic yet, we would be able to start experimenting to see what works and what breaks.
Cheers, Nick.
infrastructure@lists.fedoraproject.org