On Tue, 27 Aug 2019, Alessio wrote: i checked a number of STATUS files, and all the ones i looked at said either FINISHED_INCOMPLETE or DOOMED. that does not fill me with confidence. does that suggest that none of those ISOs are usable? rday

On Tue, 27 Aug 2019, Alessio wrote: status files aside, i would have thought that the most recent ISO (here) would be the obvious choice: https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-31/comp... as i recall, that will allow updating and eventually let me upgrade to official fedora 31, yes? rday

On Tue, 27 Aug 2019, Alessio wrote: i mean that if i install this pre-release form of fedora 31, i will eventually be able to upgrade to full, official fedora 31. isn't that what "dnf system-upgrade" is for? rday

On Tue, 27 Aug 2019, stan via test wrote: i'm confused ... are you saying there will be no difference between this release: https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-31/comp... and the final, official release of f31? also, since today is the official "beta freeze" day: https://fedoraproject.org/wiki/Releases/31/Schedule what does *that* mean in terms of a downloadable ISO? i'm not *trying* to be confused, i am merely succeeding. rday

On Tue, 2019-08-27 at 17:15 -0400, Robert P. J. Day wrote: This page may possibly be useful to you in understanding the details of this stuff: https://docs.fedoraproject.org/en-US/quick-docs/repositories/ There are three things to keep in mind, broadly speaking: the Bodhi 'update' process, Koji tags, and the compose process. When we do an F31 compose what we're basically doing is taking all the packages that have the tag 'f31' in Koji and producing some repositories and some 'deliverables' (i.e. images, basically) from them, all bundled up in this thing called a 'compose'. If that compose is a nightly compose, and it's successful, the symlink you linked above will point to it. Also, its contents will be synced out to https://dl.fedoraproject.org/pub/fedora/linux/development/31/ ... which is where the 'fedora' repository on an installed system goes looking for stuff. How packages get that 'f31' tag is (after the Bodhi enablement point) via Bodhi. A packager does a build in Koji first; at that point it doesn't get the 'f31' tag. Then they submit an update to Bodhi, at which point the build gets the 'f31-updates-testing' tag and is included in the next f31 updates-testing compose, and goes to the updates-testing repository. Once the update meets the requirements in the updates policy and is "submitted for stable" (either manually or automatically), it is given the 'f31' tag - when Bodhi "pushes an update to stable", what it really *does* is apply the 'f31' tag to it. (This is during the pre-release Branched phase, note; after release it works a bit differently). So once an update has been 'pushed stable', it gets the 'f31' tag; the next time a compose is run that package will be installed, and if that compose is successful, that package will appear (soon afterwards) in the 'fedora' repository for an installed Fedora 31 system. When we do what's called a 'candidate' compose - the ones that are candidates to be released as Beta or Final - we do more or less the same thing, though the compose gets a slightly different compose ID and gets a 'label' (like Beta-1.1 or RC-1.2) which nightly composes don't get. But for a 'candidate' compose we may include some packages that are only in updates-testing at the time, if those packages fix blocker or freeze exception bugs. So 'candidate' composes may have a few packages that a 'nightly' compose run on the same date do not have. However, once we sign off on a candidate compose to be released, we then push any such additional packages it contained to stable as soon as possible. We also push them stable a day or two *before* we push any later updates stable. So as a practical matter, for both Beta and Final there are usually two or three nightly composes shortly after a candidate compose is accepted for release that are effectively identical to the candidate compose. So to answer your initial question - from a day or two after the Final release candidate is signed off, the compose you find at the location you linked will be practically identical to it. It won't be *literally* identical, but it should contain all the same packages. Nightly Branched composes appear here: https://kojipkgs.fedoraproject.org/compose/branched/ and are run automatically every day (occasionally we manually fire respins). The most recent successful one is automatically symlinked to the URL you gave shortly after it completes. Candidate composes will appear here: https://kojipkgs.fedoraproject.org/compose/31 (that location doesn't exist yet and won't until the first Beta candidate compose is requested). They are done on request (requests made by the QA team to release engineering, per https://fedoraproject.org/wiki/QA:SOP_compose_request ). Freeze doesn't mean anything in particular in terms of composes (i.e. ISOs). Nightly composes happen every day after branching, regardless of anything else. What the freeze means is that the usual rules for updates to be 'pushed stable' (i.e. given the f31 tag and included automatically in subsequent nightly and candidate composes) are suspended until the Beta release; instead updates can only be 'pushed stable' manually during the freeze period, and *only* updates which fix blocker or freeze exception bugs will be pushed stable. That process again is handled by QA filing requests for releng: I filed the first one for the F31 Beta freeze earlier today, here: https://pagure.io/releng/issue/8702 Pending updates that don't fix blocker or FE bugs just get to sit in updates-testing during freezes. Once the Beta release candidate is signed off, a day or two later we 'unfreeze' and all queued updates that were submitted for stable but not pushed stable due to the freeze get pushed stable in one big dump. One thing to keep in mind during all this is that if you have an *installed F31 system*, the updates-testing repository will be enabled by default, which means that when you update the system you won't only get packages that have been 'pushed stable' and are showing up in the composes - you'll get all packages that have been submitted to Bodhi, even before they are 'pushed stable'. Your installed system will usually be 'ahead of' the nightly composes and even the candidate composes. If you want to stay in sync with what's been 'pushed stable' you can disable the updates-testing repository. The reason we do this is essentially that this whole process relies on people to test the packages that are submitted as updates and provide feedback to help decide whether or not they should be 'pushed stable'; if you install a pre-release we assume you're basically volunteering to help testing, so you get updates-testing enabled. Hope that made things more rather than less clear! Do ask if you have any further questions. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

On Wed, 28 Aug 2019, alciregi(a)gmail.com wrote: i was just about to say ... :-) also, i'm sure there is a more comprehensive document describing koji and bodhi and other related bits and pieces and how they all hang together ... anyone got a link? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

On Tue, 27 Aug 2019 13:49:38 -0400 (EDT) "Robert P. J. Day" <rpjday(a)crashcourse.ca&gt; wrote: If you are going to upgrade, why not use an F30 image? There will be an official upgrade path after F31 is released. You might also find what you are looking for here: https://www.happyassassin.net/nightlies.html Lots of images, and seems to be both very old and very new images there. But it gives a date of the last good compose. Note the disclaimer that these are not official release images.

On 8/28/19 7:13 PM, Robert P. J. Day wrote: Wasn't this answer in an earlier part of the thread sufficient? DOOMED should mean that something has gone very bad, and no images were produced. FINISHED_INCOMPLETE should mean that not all the expected images have been built. So, if you find the ISO you are looking for, it should boot. So, you found a good Fedora-Workstation-Live ISO, but maybe if you looked for say the Xfce ISO it isn't available or some other ISO that is part of the build. -- If simple questions can be answered with a simple google query then why are there so many of them?

Sure there are better explanations but... DOOMED: a mandatory step for our blocking deliverables failed. x86_64 workstation dvd iso can't build for example FINISHED_INCOMPLETE: a non blocking deliverable failed. x86_64 xfce dvd iso for example FINISHED (i'm not sure, didn't see it for a while): all was built On August 28, 2019 1:13:09 PM GMT+02:00, "Robert P. J. Day" <rpjday(a)crashcourse.ca&gt; wrote: Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;

On Sat, 2019-09-07 at 14:43 +0200, Alessio wrote: That's actually a great question! The answer is basically this ticket: https://pagure.io/fedora-workstation/issue/45 i.e., we just don't make the Workstation install tree at all any more. Which means no Workstation-specific network install image is even attempted to be generated; so composes don't die because it "fails", because we don't even try to build it. However, the list of release-blocking deliverables clearly needs to be updated for this change. I'm CCing Ben Cotton and Michael Catanzaro just to be sure, but I assume everyone would be fine with just dropping the Workstation netinst from the release-blocking images list, based on the conversation in the ticket. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net