the repo for a compose

[Gene Czarcinski]

On 11/28/2014 11:06 PM, Adam Williamson wrote:
> On Fri, 2014-11-28 at 21:22 -0600, Mike Chambers wrote:
>> On Fri, 2014-11-28 at 21:50 -0500, Gene Czarcinski wrote:
>>> Currently, the packages for Fedora 21 are in development/21 and
>>> updates/testing/21.  Based on my current understanding of how kojo and
>>> the compose process works, all of kojo's current packages are collected
>>> into a single yum repository which is used to compose as well as create
>>> the Live images and that single repo may or may not be the same as the
>>> two repos/
>>>
>>> Are all of kojo's "current" (or more recent) packages also in
>>> development/21 and updates/testing/21?  That is, could we use the two
>>> repos as input to create the equivalent of RC1, etc.
>>>
>>> Gene
>> Yes for now they are in testing and development/21.  Once in testing, at
>> some point, instead of going straight to development/21 they will go to
>> updates, but haven't as of yet.
> Well, it's called koji, not kojo.
Okay, okay ... so I are a injunear and spelling is not one of my strengths.
>
> The current 'stable' packages for a Branched release - that is, the last
> build of a given package that was given the 'stable' tag, which is
> always 'fXX', e.g. 'f21' for 21 - always live in development/(release),
> so development/21. I don't know where you get the term 'current', it
> isn't used by koji or Bodhi so far as I know. 'testing' packages -
> packages with the 'f21-updates-testing' tag, that have been submitted
> via Bodhi - live in updates/testing .
>
> TCs and RCs do not use packages from updates/testing at all, so forget
> about it, if you're trying to generate images that approximate the
> 'official' ones. But they *do* use packages from bleed:
>
> http://kojipkgs.fedoraproject.org/mash/bleed/
>
> because we like to pull in Blocker and FE bug fixes before they go all
> the way through the Bodhi and mash process and show up in
> development/21. bleed is the side repo into which Blocker/FE fixes that
> are requested for a given TC/RC compose are put. So, when I do a TC/RC
> compose here:
>
> https://fedorahosted.org/rel-eng/ticket/6031
>
> and say "Please pull (list of packages)", releng puts the packages from
> that list into the bleed repository before they run the compose.
>
> So, if you're trying to match the package set of the current TC/RC, the
> repos for your compose should be 'fedora' (which is the 'stable' repo)
> and bleed. Do not use updates-testing. You also will want to make sure
> you have the f21 branch of spin-kickstarts, and try to use the git
> commit that was the latest at the time the compose was run.
I can see some pluses to what you are doing but also some minuses. The 
pluses are that you are geting some critical stuff tested sooner rather 
than later.  The minuses are that anyone doing a netinstall will not get 
any of these packages.  Only those fixes that are on the Fedora-Server 
DVD or on a Live CD/DVD will get more testing.

Also, I am not trying to duplicate what will be in the final release so 
much as to create Live images which include potential updates.  I am 
still testing and if something out in updates-testing is going to break 
things, I want to know that so I can report it and, if possible, propose 
a fix.

Also, I have bought into this Workstation product as well as the other 
Live "nonproducts"  (really, I consider them to be "semi-products").  I 
am trying to figure out my new install/reinstall process ... should I 
create my own Live image which has everything I want or use a standard 
Live install followed by a post-install script to add in the rest of the 
stuff I want.

I will still b e creating my own Live images because there are some 
packages I have locally updated which need to be there for the install.  
For example, my version of grubby updated to support booting off a btrfs 
subvolume.

Gene