@mohanboddu @ausil PTAL

We should not use Everything repo for Workstation deliverables. IIRC, @ausil didn't approve a similar request before.

Workstation is supposed to be Workstation, everything in it must come from workstation, the two options are add packages to workstation or drop them from atomic workstation.

                  Workstation is supposed to be Workstation, everything in it must come from workstation, the two options are add packages to workstation or drop them from atomic workstation.

Up until this point I still don't understand the point of this artificial limitation. Could someone explain it to me in dumb people terms? I understand that if we were to run a Workstation compose by itself then it would go faster if we limit the package set, but there is no case where we actually do run a workstation compose by itself. In rawhide/f27 it's done with everything else including the Everything repo for pre-release and in updates.

@ausil, @mohanboddu can you explain the technical benefits of having a separate Workstation tree and all of the complication around that? How do we do the KDE and Xfce spins, and what are the downsides if we were to do Workstation in that same way?

Disclaimer: I'm sure there are things I don't know about and that's is why I asked and want to be educated on them.

The only thing that I can think of that would make sense is to have a separate package set that is for anaconda/installer only. The only composes that we have that run individually like that is Cloud/Docker/Atomic (and some for modularity??) and only one of those composes make an installer which would be the only reason I can think of to actually create a new repo.

The Atomic compose makes an installer, so yes, create a new repo so that you can create an updated installer and it probably would benefit from having a smaller package set.

The Cloud and Docker composes don't create an installer (i.e. no anaconda) so they can just re-use the installer from release day (or we could possibly look at releasing updated installer images periodicially and pulling from those if necessary). Also, the Cloud and Docker composes that run daily could just pull from updates (I think the Docker ones already do), so why not just do that?

The only thing that I can think of that would make sense is to have a separate package set that is for anaconda/installer only.

Yep, agree with this; we definitely need it - respinning the FA{H,W} ISOs without pulling in potentially risky changes to gtk3 or whatever is really important and necessary.

That said though...in the end this is almost equivalent to the "gold" repos i.e. the fedora rpm-md repo (as distinct from including fedora-updates) right? Although I guess as we determined we want the ability to cherry-pick newer things like ostree into it.

That said though...in the end this is almost equivalent to the "gold" repos i.e. the fedora rpm-md repo (as distinct from including fedora-updates) right? Although I guess as we determined we want the ability to cherry-pick newer things like ostree into it.

right we would choose not to update anaconda unless there is something new we need. As we do today we would mostly stick with the "gold" fedora repos, and then cherry-pick on a case by case basis.

If we broke this out to be more generic than for atomic basically we would have an f27-anaconda pungi compose/repo that we would run whenever we made a change to the package set (probably would happen less than once a month) and all of the broken out composes would use that.

If we broke this out to be more generic than for atomic basically we would have an f27-anaconda pungi compose/repo that we would run whenever we made a change to the package set (probably would happen less than once a month) and all of the broken out composes would use that.

This seems like a great direction to me — we should pull the Anaconda team into the discussion. Probably not something realistic for F28 timeframe, but maybe F29?

f27-anaconda

I am a fan of that idea, though it seems to rather change the whole idea of what a "compose" is. AIUI releng people really like the concept that "everything" in the compose has the same version. Making Anaconda not follow that is a pretty fundamental change.

I am a fan of that idea, though it seems to rather change the whole idea of what a "compose" is. AIUI releng people really like the concept that "everything" in the compose has the same version. Making Anaconda not follow that is a pretty fundamental change.

On the anaconda topic I'm not proposing we change pre-release. We would still have one big compose for pre-release. post-release is when we would have an f27-anaconda compose that we pull from and only update when we add something new. It would not differ from release day much.

For the "everything" in the compose has the same version comment, we already do that today with Fedora Atomic, which is the only case we have where we ship updated ISOs.

yeah, FWIW after talking this over with @dustymabe , I don't think I see any issues with it. The f27-anaconda compose would be a kind of sausage factory implementation detail; the Fedora-Atomic, Fedora-Cloud and Fedora-Docker composes would still be complete in themselves in the ways we care about, I think. At least, in the ways I care about, for testing and fedfind purposes, which is how I usually think about these things.

Might be some implications I haven't thought through, though.

oh, but I dunno whether f27-anaconda was supposed to be the 'name' of the compose in any way, but if it was, please don't. I will hunt down anyone who puts a dash in the shortname for a compose and disembowel them with a rusty spoon. In fact, please just don't put dashes in any productmd value anywhere ever, thanks. Just use the letters and the numbers. No spaces. No dashes. No dots. Nothing else. :P

actually, i already have to deal with dashes in the shortname. I do always expect the shortname to start with 'Fedora', though.