KDE x86_64 live in the 28 Beta composes is oversize: KDE live x86_64, size 2069889024, max 2000000000 (that's from Beta-1.1, 1.2 is similar, 1.3 likely will be too) Note - the 2GB target size was agreed on during F26 cycle, last time we had this problem. See https://bugzilla.redhat.com/show_bug.cgi?id=1457645 . This is technically an automatic Beta blocker, but I'm going to make it proposed for now so we can kick this around a bit. Do we just want to arbitrarily bump the size again? Should we re-consider the criteria? I could, for instance, suggest that we only block *on limits that are related to optical media sizes* at Beta; I can see blocking Beta for 'the "DVD" image is bigger than a DVD', or even 'the netinst is bigger than a CD', but blocking for "KDE live is bigger than some arbitrary size we chose at some point" seems a bit of a stretch. (We should've reported this earlier, sorry; I'll try and get a better process in place for ensuring oversize images are reported quickly).
I'd be in favor of only blocking on the netinstall is larger than cd sized, and dvd image is bigger than dvd (which is only the server DVD at this point). I do think it would be great if folks could reduce sizes in general for live media, but blocking on some arbitrary number we just change anyhow is silly.
I'd say maybe the rule should be 'block if any release-blocking ISO is under DVD size, except release-blocking network install ISOs, which must be under CD size'...thoughts?
well, uh, I obviously messed up the syntax there: 'block if any release-blocking ISO is over DVD size, or if any release-blocking network install ISO is over CD size'
I'd probably modify it *slightly*. I'd use 4GB (in the base-10 definition storage manufacturers use, so more like 3.7GiB formatted) as the cutoff for release-blocking ISOs for the simple reason that this will also keep us fitting on 4GB thumbdrives which are increasingly the preferred way to install Fedora from downloaded media. Obviously, since this is a lower maximum, this also meets the requirement to be able to produce physical DVDs for handing out at conferences. For the record, I'm guessing that the 2GB limit was at least partially chosen because of the relative expense of mass-purchasing thumbdrives for Ambassadors. So it would still be likely a good idea to have a stretch goal of keeping under that number for *Final* release as well. I agree that we should keep the netinst images small enough to fit on a 700 MiB CDROM.
The size limits are chosen on a per-media basis. The reason for choosing 2GB for KDE was really just what Kevin wrote in the bug I linked to: "The next highest size that makes sense to me would be 2GB (to fit on 2GB flash drives... if any of those still exist or are being handed out)." at the go/no-go meeting, Rex said: "<rdieter> adamw: 2gb as nirik suggested worksforme" and that was it. There was no particular consideration of Ambassadors or anyone else.
ISO 9660 has a limit of 4GiB which would only apply to LiveOS/rootfs.img and it's even a bit challenging to find 8G flash drives these days, so I think 4G is a reasonable upper limit for now. Subjectively it could be made 3G so we get flagged before actually doing that to users and mirrors without further consideration.
I believe the criterion should stay, but be moved to the Final milestone. We no longer block on optical media for Beta, and with flash drives, you can always use a larger one. So it no longer makes sense to have this on Beta. If a particular Fedora edition doesn't want to have size limits, we can simply avoid checking that edition (or use a sufficiently high number if that's easier). It would be nice to have these limits officially documented somewhere and link to it, because our current test case shows different numbers than OpenQA checks. KDE Live is currently set to 1.4GB at: https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size#Expected_Results
I agree with https://bugzilla.redhat.com/show_bug.cgi?id=1561763#c3 but providing some actual values (like 4GB or 3.7GiB for DVD) and documenting it somewhere. Also, we should not block Beta for this instead add the criterion as a FE for Beta and Blocker for Final. The reason for suggesting as a FE for Beta is, we would wont forget it in our testing for Beta and if we find it, we will fix it for Final, rather than neglecting it for Beta and all of a sudden we find it in Final and either we change the criterion again or block the release which I think we should avoid.
We tracked down the main source of the bloat, and the fix is an easy kickstart fix: https://www.spinics.net/lists/fedora-devel/msg243043.html See also https://bugzilla.redhat.com/show_bug.cgi?id=1530006#c6 and following.
Kamil: "It would be nice to have these limits officially documented somewhere" They are: https://fedoraproject.org/wiki/Releases/28/Spins that page didn't get created for a couple of releases, but I've been bugging people about doing it properly lately. That page is supposed to be the canonical reference.
In fact I'm lying, that page is only for Spins. I think the test case is the only record of the size limits for release-blocking images that aren't spins, unless I'm forgetting something.
Time to remove the artificial distinction between "Editions" and "Spins" and have everything be a Spin, with equal treatment?
Discussed at 2018-03-29 go/no-go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting/2018-03-29/f28-beta-go-no-go-meeting.2018-03-29-16.04.html . We agreed that we don't think it makes sense to block Beta on size limits that aren't really associated with common physical media, or ISO format limitations. We will draft more specific criteria changes on the test@ list. On the basis of this agreement, we rejected this bug as a Beta blocker.
Kevin: it's not an artificial distinction. An Edition is a significantly different thing from a Spin. Beyond that, not really part of this bug, anyhow.
Kalev notes that https://pagure.io/fedora-workstation/issue/46 has a significant impact on this, it will likely reduce the KDE image size to under its target again.
Discussed during the 2018-04-09 blocker review meeting: [1] The decision to classify this bug as an AcceptedBlocker was made as it violates the following blocker criteria: "The release-blocking images must meet current size requirements" Note: this is still a blocker under the current proposed revision to that criterion. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-04-09/f28-blocker-review.2018-04-09-16.01.txt
https://pagure.io/fedora-comps/pull-request/255 was merged
As per https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180415.n.0_Installation , in recent composes the KDE image is under its specified size. The only oversize images are LXDE, MATE and SoaS, none of which is blocking.