Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Sat, Jun 23, 2012 at 01:15:14AM +0200, Kevin Kofler wrote: Michael Cronenworth wrote: Kevin Kofler wrote: How would you suggest we implement this? rm -rf the stuff in %post? (Yuck!!!) As I understand it, the symbols will be bloating the main packages and not be in subpackages. (Debuginfo subpackages are what we have now.) It would be nice if the minidebuginfo data was stored similar to debuginfo data. That way spins could easily rm -rf the minidebuginfo folder to keep images smaller. You apparently didn't get it: running rm -rf on files owned by a package on the spin is NOT a serious option! Among other things, it will break DeltaRPMs and rpm -Va, it does not persist on package updates and thus creates inconsistencies when (inevitably) some packages are updated and others are not, and it's just wrong. A pie in the sky option might be to have minidebuginfo/debuginfo reside in the same package as the binaries it belongs to but in separate files which are marked in the rpm filelist. Then rpm could have a --nodebuginfo similar to how it has --nodoc now. Not sure if that's either (1) something the rpm team would go for or (2) something that could be available in a time frame that the minidebuginfo authors would find acceptable. -Toshio pgpBEUsswYAeI.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/26/2012 02:50 PM, Toshio Kuratomi wrote: A pie in the sky option might be to have minidebuginfo/debuginfo reside in the same package as the binaries it belongs to but in separate files which are marked in the rpm filelist. Then rpm could have a --nodebuginfo similar to how it has --nodoc now. Not sure if that's either (1) something the rpm team would go for or (2) something that could be available in a time frame that the minidebuginfo authors would find acceptable. Please, please no. --nodoc is a travesty. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Toshio Kuratomi wrote: A pie in the sky option might be to have minidebuginfo/debuginfo reside in the same package as the binaries it belongs to but in separate files which are marked in the rpm filelist. Then rpm could have a --nodebuginfo similar to how it has --nodoc now. Not sure if that's either (1) something the rpm team would go for or (2) something that could be available in a time frame that the minidebuginfo authors would find acceptable. 1. it'd have to be available at the kickstart level too to be useful for us and 2. I don't think it's that great a solution, either. (It'd still cause trouble for DeltaRPMs, plus it's not that great to have RPM just not install some files, we stopped using that RPM feature for translations long ago because of the problems it caused, I don't think going back to doing things that way would be a great idea.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Jun 2012 17:10:08 -0500 Dennis Gilmore den...@ausil.us wrote: El Tue, 19 Jun 2012 12:19:35 -0400 (EDT) Jaroslav Reznik jrez...@redhat.com escribió: As reaction to approved MiniDebugInfo feature, we agreed on KDE SIG meeting that we would have to break CD size limit (and the breaking of CD size image was used as argument to accept this feature). We agreed that 800 MiB is achievable target: - all spins will still fit Multi Desktop Live DVD - there's still space available for overlay for USB disks - you can still get 800 MiB CD-Rs (may hit HW constraints...) Other possibility is to go directly to 1 GiB but we are not sure there's advantage (at least not now). Contingency plan - at least for one release we'd like to have a 700 MiB KS (with more compromises). So we'd like to hear from rel-engs, QA etc. what's theirs position here. from Relengs perspective it doesnt matter what size it is. so long as it meets the release criteria then its ok. Personally i have a serious concern over dropping cd sized media. One big issue is that the OLPC XO-1 only has 1gb storage for both the OS and user data. any size increase in the OS reduces the room for user data. http://en.wikipedia.org/wiki/One_Laptop_Per_Child#Deployment_of_XO_laptops lists over 2.5 million XOs deployed a large number of which a xo-1 most of which run fedora. I spoke with some OLPC people, they really would prefer that we be able to disable the installation of the mini debuginfo. As the devices are all space constrained. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/oZckACgkQkSxm47BaWfdh7gCeKivoQfentzSjTgtZhc7VM0CZ jB8AnRZHltsyiHcufN1AxLeNhZFJFA/6 =7Z0j -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
inode0 wrote: The quota for these would need to be much higher already as the Multi-Desktop is now 6.1GB The Multi Desktop Live DVD is dual-layer, it's not expected to fit 4.7 GB. But dual-layer DVDs also have a finite capacity. ;-) So we can allow each spin to grow to a certain extent, but not to an arbitrarily high size or to a full DVD. We need arbitrary quota which sum up to at most the size of a dual-layer DVD. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Adam Williamson wrote: I don't believe there's currently any requirement that target sizes match some form of physical media. So far they always _have_, but if there's a requirement that they _must_, I've never seen it. It might have been a misunderstanding, but I read Jóhann B. Guðmundsson as proposing such a requirement (which would IMHO be a bad idea). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Mon, Jun 25, 2012 at 6:53 PM, Kevin Kofler kevin.kof...@chello.at wrote: inode0 wrote: The quota for these would need to be much higher already as the Multi-Desktop is now 6.1GB The Multi Desktop Live DVD is dual-layer, it's not expected to fit 4.7 GB. But dual-layer DVDs also have a finite capacity. ;-) So we can allow each spin to grow to a certain extent, but not to an arbitrarily high size or to a full DVD. We need arbitrary quota which sum up to at most the size of a dual-layer DVD. Right. We should note also that there is no requirement that the Multi Desktop include the desktops that it currently includes. Right now it includes 5 desktops and while I hope it can continue to include all 5 there is no requirement for it to. And it really would not be the end of the world for the Multi Desktop to not be dual architecture in the future, this is convenient but at some point 32 bit will be dropped anyway and it could just be split into arch specific DVDs if necessary. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Sat, Jun 23, 2012 at 2:51 AM, Kevin Kofler kevin.kof...@chello.at wrote: [..] So I really wonder whether it isn't more practical to set an arbitrary limit and let the user find a suitable medium to burn it on (if in doubt, a DVD; we'll probably call it a Live DVD in the first place). Well using a DVD if you intend to burn has always been a good idea. You get better seek times for free (empty dvd costs little to no more then a cd now days). As for your exotic CD sizes ... the likelihood of the user having a DVD burner or BIOS that could just boot from USB media is way higher then a burner that can deal with them. So I'd just opt for not worrying about CDs anymore. The only real argument for CD sized images is download time but using Fedora without a proper internet connection is no fun anyway (updates) so not sure that matters either ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
drago01 wrote: (empty dvd costs little to no more then a cd now days) FWIW, a CD-R90 actually costs more than a DVD-R or a DVD+R around here these days. (It used to cost significantly less back in the day.) So I'd just opt for not worrying about CDs anymore. The only real argument for CD sized images is download time but using Fedora without a proper internet connection is no fun anyway (updates) so not sure that matters either ... Download times are not the only reason for not going up to the full ( 4 GiB) DVD size, though IMHO they are also a valid reason. There's also the Multi Desktop Live DVD distributed by the ambassadors, which needs to fit all the spins in both 32-bit and 64-bit versions on one dual-layer DVD. So going up to 4 GiB per spin is a no go. Combined with your point above, this means we really need to allow arbitrary target sizes, not just a list of maximum sizes of hardware media. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Kevin Kofler kevin.kofler at chello.at writes: Download times are not the only reason for not going up to the full ( 4 GiB) DVD size, though IMHO they are also a valid reason. There's also the Multi Desktop Live DVD distributed by the ambassadors, which needs to fit all the spins in both 32-bit and 64-bit versions on one dual-layer DVD. So going up to 4 GiB per spin is a no go. Would it be possible for QA to get access to the Multi Desktops before release and test those directly against a media-determined hard limit? Also, I think the limit for DVDs should be the media size, 4.7 GB, not 4 GiB. OpenSUSE for one has released DVDs larger than 4 GiB for a while now and I haven't heard of problems. Thumb drives are cheap, and if they need to be formatted with a non-FAT filesystem to hold such images, that can be documented. And the size difference between 4 GiB and 4.7 GB is about 9.4%, which is over 3 times the difference between 700 MiB and 736970752 bytes* (assuming this latter size, approximately 702.83 MiB, is safe, which it may not be - there is at least one brand with a slightly lower limit, for example see http://www.berklix.com/~jhs/txt/cdroms.html , simply sticking to the advertised size, 700 MiB, would avoid the real risk of releasing non-burnable images). Also, while it's good to keep images small to reduce download time, that doesn't need to be a hard limit either. * See http://lists.fedoraproject.org/pipermail/test/2010-April/089943.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Sat, Jun 23, 2012 at 14:29:28 +, Andre Robatino robat...@fedoraproject.org wrote: Would it be possible for QA to get access to the Multi Desktops before release and test those directly against a media-determined hard limit? Also, I think the limit for DVDs should be the media size, 4.7 GB, not 4 GiB. OpenSUSE for one has released DVDs larger than 4 GiB for a while now and I haven't heard of problems. Some file systems don't handle files greater than 4 GiB. That is why the spins sig limited spins published as ISOs to that size. livemedia-creator does support larger sizes. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Bruno Wolff III bruno at wolff.to writes: Some file systems don't handle files greater than 4 GiB. That is why the spins sig limited spins published as ISOs to that size. livemedia-creator does support larger sizes. Which is why immediately afterwards I wrote the following (I'm aware that files on FAT are limited to 4 GiB): Thumb drives are cheap, and if they need to be formatted with a non-FAT filesystem to hold such images, that can be documented. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Andre Robatino wrote: Would it be possible for QA to get access to the Multi Desktops before release and test those directly against a media-determined hard limit? That makes sense, though the problem then is which spin gets the blame if the overall quota is exceeded? We probably need to define per-spin quota. Also, I think the limit for DVDs should be the media size, 4.7 GB, not 4 GiB. I agree, I only wrote 4 GiB because I didn't want to look up the exact limit nor to deal with the fact that DVD-R and DVD+R media have a different capacity. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Sat, Jun 23, 2012 at 12:57 PM, Kevin Kofler kevin.kof...@chello.at wrote: Andre Robatino wrote: Would it be possible for QA to get access to the Multi Desktops before release and test those directly against a media-determined hard limit? That makes sense, though the problem then is which spin gets the blame if the overall quota is exceeded? We probably need to define per-spin quota. The quota for these would need to be much higher already as the Multi-Desktop is now 6.1GB and the Multi-Install is 7.3GB. These images are also dual architecture and are generally not intended for direct download although that is allowed from alt. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Sat, 2012-06-23 at 12:29 +0200, Kevin Kofler wrote: drago01 wrote: (empty dvd costs little to no more then a cd now days) FWIW, a CD-R90 actually costs more than a DVD-R or a DVD+R around here these days. (It used to cost significantly less back in the day.) So I'd just opt for not worrying about CDs anymore. The only real argument for CD sized images is download time but using Fedora without a proper internet connection is no fun anyway (updates) so not sure that matters either ... Download times are not the only reason for not going up to the full ( 4 GiB) DVD size, though IMHO they are also a valid reason. There's also the Multi Desktop Live DVD distributed by the ambassadors, which needs to fit all the spins in both 32-bit and 64-bit versions on one dual-layer DVD. So going up to 4 GiB per spin is a no go. Combined with your point above, this means we really need to allow arbitrary target sizes, not just a list of maximum sizes of hardware media. I don't believe there's currently any requirement that target sizes match some form of physical media. So far they always _have_, but if there's a requirement that they _must_, I've never seen it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Michael Cronenworth wrote: Kevin Kofler wrote: How would you suggest we implement this? rm -rf the stuff in %post? (Yuck!!!) As I understand it, the symbols will be bloating the main packages and not be in subpackages. (Debuginfo subpackages are what we have now.) It would be nice if the minidebuginfo data was stored similar to debuginfo data. That way spins could easily rm -rf the minidebuginfo folder to keep images smaller. You apparently didn't get it: running rm -rf on files owned by a package on the spin is NOT a serious option! Among other things, it will break DeltaRPMs and rpm -Va, it does not persist on package updates and thus creates inconsistencies when (inevitably) some packages are updated and others are not, and it's just wrong. The only reasonable solution is to not add bloat to the main packages in the first place. It should be in subpackages or just not there at all. (IMHO, the latter. We already have debuginfo in subpackages, we don't need a redundant subset of it.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Jóhann B. Guðmundsson wrote: In any case Kevin K. probably can comment on what landed the KDE distribution on the Relengs DVD and on the release blocker in the first place. A long fight by KDE SIG. It took several releases (including one or two releases which shipped a KDE live image with bugs which would probably have been considered blockers if the blocker process hadn't been arbitrarily restricted to GNOME) and repeated complaints by us for them to finally make KDE a release-blocking desktop. Now if you ask me about my opinion about the other desktops: IMHO, all the desktops on the Multi Desktop Live DVD should be considered release- blocking. I don't see why a blocker bug in, say, Xfce shouldn't be treated the same way as a blocker bug in GNOME. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Adam Williamson wrote: As a personal comment, though, doesn't this seem a little fast to make the decision? Wouldn't it at least make sense to wait for minidebuginfo to be implemented, then spin a test KDE image and see exactly how big it turns out with the current package set? We will have to check what size we hit exactly (my guess is something between 700 and 800 MiB, which is why we're discussing an 800 MiB target), but what we know is that F17 was at 695 MiB, and the numbers the MiniDebugInfo feature page is quoting are way above the 5 MiB we have left. (And in addition, those 5 MiB are likely to be taken up by other creeping bloat. Everything just gets larger and larger at every release, usually without anything concrete to pinpoint.) So it is not possible to ship a KDE spin with MiniDebugInfo without increasing the size target, dropping some applications or both. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Jóhann B. Guðmundsson wrote: Arguably we should not have any specific target image size but rather a list of valid image sizes ( cd/dvd/usb keys ) for spins to aim at which SIG's themselves choose to use each release cycle and can adjust accordingly which gives them the ability to shrink/expand to suit *their* targets audience needs at any given time. A good target size would be the size of a CD-R90. The problem there is that it's ill-specified: the media usually say 90 min / 800 MB, but 800 decimal MB of data are less than 90 minutes of audio, 800 MiB are more. There's also no standard which specifies a minimum capacity in sectors as for the 80 min / 700 MB case (where you actually get 703 MiB of guaranteed capacity). Add to that that you need to use the overburn option even to use the medium's advertised (to humans) capacity (as it advertises only the standard 80 minutes to the burner), so it is really hard to figure out how much space the manufacturers really are providing you. It probably also depends on the manufacturer. Some manufacturers give instructions saying to set the limit to 89:30, while at the same time advertising 90 minutes on the label, and even then it doesn't necessarily mean you can't actually burn 90:00 or maybe even 800 MiB on the medium. And then it can also depend on the burner. The reasonably safe target size would probably be somewhere around 700 * 89.5 / 80 = 783 ⅛ MiB (matching the 89:30 recommendation). (The exact computation would have to take the overheads into account.) Whether that'd be enough for the KDE spin after MiniDebugInfo, I don't know yet, we'll have to wait and see. The next higher capacity is CD-R99, but there too, the size is poorly specified and burner support even more lackluster. (You can expect most current burners to burn CD-R90s just fine, but not necessarily CD-R99s.) So I really wonder whether it isn't more practical to set an arbitrary limit and let the user find a suitable medium to burn it on (if in doubt, a DVD; we'll probably call it a Live DVD in the first place). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
- Original Message - On Tue, 2012-06-19 at 22:14 +, Jóhann B. Guðmundsson wrote: On 06/19/2012 09:03 PM, Kevin Fenzi wrote: I'll add to that to note that we now have Xfce, LXDE and Sugar all on the DVD. Which should have been added to the release blocker process when it got added there. From my point of view any handed out media at various events etc and what's on it should be considered release blocker. I've considered asking about making Xfce a blocking desktop, but I have no idea how the LXDE and Sugar communities are with helping testing, etc. It would mean added burden on QA folks to test more stuff, and added burden on maintainers of those desktops to create timely fixes for any blocker issues that come up. There is no such thing as added burden on QA + Me and James had already solved that problem long ago but never found the time to implement it like so many other things because we both where a bit busy with our $dayjobs. The solution was more or less this way If an manpower to cover anything else then critical path became a concern we should fetch that manpower from the relevant SIG's community. Basically the plan was to reach out for example to the Gnome/KDE/XFCE/LXDE/Sugar community's to ask for assistant to cover their relevant part of required testing if that was the case. If you think about it who are better qualified and more willing to test those components other then the people that are using it on daily bases... This is fine in theory, but it doesn't hold up terribly well in practice. Just about every time we roll a TC/RC, I mail the lists for each desktop - GNOME, KDE, Xfce, LXDE, and Sugar - and ask for help in filling out the validation matrix. And thank you very much for this email notification! We get help fairly often for GNOME and KDE, and satellit_ usually covers Sugar, but we very rarely get anything for Xfce or LXDE. The main issue here is - the TC/RC images are released too fast to be able to fill in the matrix for all DE and all TCs/RCs. The idea could be - fill in the Matrix when first TC/RC is created, then follow closely the changes (to test only stuff that could be affected - hah, could be tricky) - not to fill the whole matrix and go through the all tests that even do not test the real change and then we can have one full matrix test for last one in the series of images and let some amount of time to do it (to mark it - done). Otherwise we will never have all DEs filled in as it's impossible in a time we have. And I have to thank you Fedora QA guys for helping us to cover KDE test, I always try my maximum but sometimes... R. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
- Original Message - It's worth noting that we certainly have shipped non-blocking spins in completely broken states in past releases, and there is at present nothing to prevent this happening. There is zero guarantee of testing for non-blocking spins. QA did no formal validation of any spins besides Desktop, KDE, LXDE, Xfce and Sugar for F17. In Milan we talked a little bit about this - to require ack for every spin for every release (even the default one) - to prove, the spin is in a good shape, it's working etc to avoid this situation. Question is, if we can make it (especially in timely manner)... R. Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
- Original Message - As far as QA is concerned it's entirely your decision (as a personal note to self, I'll have to update the Deliverables SOP draft). We just need to know so we know what limit to check against in testing. As a personal comment, though, doesn't this seem a little fast to make the decision? Wouldn't it at least make sense to wait for minidebuginfo to be implemented, then spin a test KDE image and see exactly how big it turns out with the current package set? Note that spins are not absolutely required to hit their target size at Alpha; it becomes a hard requirement at Beta stage. So you have up until Beta release to make the decision, really. The reason why we start *talking* about it now is that we are quite sure it's going to a problem for the KDE spin. As QA you know that we are on the edge of current size limit with every release - we already did a lot of compromises and with every release more and more stuff is pulled into the image :( So MiniDebugInfos aren't the only problem, just a kick off to move on :) R. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Wed, 2012-06-20 at 04:46 -0400, Jaroslav Reznik wrote: We get help fairly often for GNOME and KDE, and satellit_ usually covers Sugar, but we very rarely get anything for Xfce or LXDE. The main issue here is - the TC/RC images are released too fast to be able to fill in the matrix for all DE and all TCs/RCs. The idea could be - fill in the Matrix when first TC/RC is created, then follow closely the changes (to test only stuff that could be affected - hah, could be tricky) - not to fill the whole matrix and go through the all tests that even do not test the real change and then we can have one full matrix test for last one in the series of images and let some amount of time to do it (to mark it - done). Otherwise we will never have all DEs filled in as it's impossible in a time we have. And I have to thank you Fedora QA guys for helping us to cover KDE test, I always try my maximum but sometimes... I know they iterate fast :/ When a candidate doesn't likely change anything significant wrt. a desktop I try to say so, but the thing is, it's possible for really weird stuff to happen, and we have to try and exclude that possibility as much as possible. So instead of trying to do something like you propose above and run the risk of dropping the ball somewhere and declaring that a test has passed which actually fails for the latest compose, I'd prefer to always have a fresh matrix for each compose. What we can do when we're *almost* sure the results for, say, TC2 will hold for TC3 so far as KDE is concerned, is copy the results across; we do do that sometimes. It has the advantage that it's clear we're relying on a previous candidate test, rather than giving the false assurance that we've actually tested it directly with the latest build. Unfortunately the fast iteration is a fact of life on the release cycle we use, there's no possible other way to do it so far as I can see :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Tue, 19 Jun 2012 16:25:50 -0700 Jesse Keating jkeat...@j2solutions.net escribió: On 06/19/2012 03:59 PM, Jef Spaleta wrote: On Tue, Jun 19, 2012 at 2:47 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Again anything that gets handed out at various events should be considered release blockers since the quality of that product reflects back at us as a community thus if an relevant SIG cannot cover it's own release testing apart from what we consider core and QA handles ( which in essence is what those spins build upon ) it should be removed from anything we officially hand out thus no longer be considered release blockers. At what point in the process would you place the go-no-go as to the release of a specific deliverable as an official spin? In an effort to not beatup an existing subgroup that is perhaps shorthanded I'll talk about a hypthetical situation. For the sake of argument lets assume I and a small group of heroic people were able to beat CDE into shape as a new fedora spin. Retro is the new hotness right... We get a spin out the door we get on the spins page for a release or twowe are rocking the world. And then for some reason on the next release we all fall behind and we don't keep up with the necessary integration changes. And CDE is just horribly broken for months. A lot of bugs get set as release blockers and we are pinged...but we just don't get the work done. At one point in the pre-release process does our Spin get culled from the herd and we are told..sorry..this release won't have a CDE spin? At what point does the QA and release team just punt? -jef We already have a go/ no go line built into the schedule. It's the Feature Freeze line. Things are supposed to be in a testable state by that point. If your desktop is so broken as to not even be testable, that's reason to drop it. I believe that's the transition from Alpha to Beta. Feature freeze is at Alpha, it has to be testable in the Alpha release. it doesnt have to be complete until Beta though. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/iR0QACgkQkSxm47BaWfdSYwCdEQwc1tbbn5YJcnxEmMwiQx4A IBkAn1eoQkfYSatDbAIkBeeTzsuIw2QC =M1u/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Tue, 19 Jun 2012 12:19:35 -0400 (EDT) Jaroslav Reznik jrez...@redhat.com escribió: As reaction to approved MiniDebugInfo feature, we agreed on KDE SIG meeting that we would have to break CD size limit (and the breaking of CD size image was used as argument to accept this feature). We agreed that 800 MiB is achievable target: - all spins will still fit Multi Desktop Live DVD - there's still space available for overlay for USB disks - you can still get 800 MiB CD-Rs (may hit HW constraints...) Other possibility is to go directly to 1 GiB but we are not sure there's advantage (at least not now). Contingency plan - at least for one release we'd like to have a 700 MiB KS (with more compromises). So we'd like to hear from rel-engs, QA etc. what's theirs position here. from Relengs perspective it doesnt matter what size it is. so long as it meets the release criteria then its ok. Personally i have a serious concern over dropping cd sized media. One big issue is that the OLPC XO-1 only has 1gb storage for both the OS and user data. any size increase in the OS reduces the room for user data. http://en.wikipedia.org/wiki/One_Laptop_Per_Child#Deployment_of_XO_laptops lists over 2.5 million XOs deployed a large number of which a xo-1 most of which run fedora. my other concer is for portions of the world without great internet access. making everything bigger slows down download time and increases costs of getting fedora. im honestly not sure what kind of numbers this would effect Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/iSkAACgkQkSxm47BaWfesggCdFn1tL0G4yeeU9rbDoTupnkfC YHQAnRTnJGq2qTOoq1IH0wZeuDC0Zgcj =qmNI -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
As reaction to approved MiniDebugInfo feature, we agreed on KDE SIG meeting that we would have to break CD size limit (and the breaking of CD size image was used as argument to accept this feature). We agreed that 800 MiB is achievable target: - all spins will still fit Multi Desktop Live DVD - there's still space available for overlay for USB disks - you can still get 800 MiB CD-Rs (may hit HW constraints...) Other possibility is to go directly to 1 GiB but we are not sure there's advantage (at least not now). Contingency plan - at least for one release we'd like to have a 700 MiB KS (with more compromises). So we'd like to hear from rel-engs, QA etc. what's theirs position here. R. - Original Message - Kevin Fenzi wrote: 18:23:37 nirik #topic ticket 868 F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo 18:23:37 nirik .fesco 868 18:23:42 zodbot nirik: #868 (F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo) – FESCo - https://fedorahosted.org/fesco/ticket/868 18:24:03 nirik mmaslano was 0 in ticket. 18:24:24 nirik I'm -1. First of all, thank you Kevin for having been the only one stepping up against this nonsense! 18:24:28 limburgher Seemed. . .mildly contentious. . . 18:24:34 mitr I think the only technical objection was that spins won't fit on a CD, The only technical objection which is a blocker as far as we're concerned. Image sizes are even a release blocker! Nobody decided that spins should NOT be CD-sized. There was also the additional objection that the feature brings no practical gain, because -debuginfo is already available and the Retrace Server is available. Later in the discussion, you also pointed out that ABRT probably won't even use this information! So why ship it? Bloat just for the sake of bloat? but when repeatedly asked nobody came up with an example user/ambassador saying that CDs are needed Huh? Examples have been given in the mailing list threads. There's also the constraint that all the spins in both 32-bit and 64-bit editions need to fit on one DVD (the Multi DVD), which very much does matter to the ambassadors. 18:24:54 mezcalero nirik: out of curiosity, why do you say -1? 18:25:17 notting i am +1. obviously would need to be coordinated with any dmz-related rebuilding 18:25:21 * pjones is also +1 18:25:33 nirik I don't think the extra size is worth the gain. I think we can/should work on making abrt better. Right. 18:25:34 hughsie i don't know if i should comment, but from my role as an upstream maintainer, this would be really useful for real life debugging from end users... That's what -debuginfo packages are for! 18:25:44 limburgher mitr: Would dwarf compression help that? 18:25:48 jwb i'm marginally +1 18:25:55 pjones limburgher: no - different set of fields Even if it were affecting the mini-debuginfo fields (it doesn't), compression wouldn't help at all because the live images are already compressed. Even special-case compression has at best a very small effect after xz is run on it. 18:25:56 mitr limburgher: jakub said above that it is orthogonal 18:25:57 t8m as long as it does not replace full backtraces reported in ABRT I'm ok with it so marginally +1 18:26:11 mitr AFAICS this only benefits developers and reading crashes in unexpected components, but given Fedora's target arudence, +21 18:26:14 mitr +1 that is 18:26:16 limburgher mitr, pjones: Missed that, thanks. 18:26:22 limburgher Ok. +1 18:26:24 mjg59 I lean +1 18:26:43 mitr nirik: My best guess is that abrt will just ignore this. So just useless bloat. 18:26:57 nirik #agreed Feature is approved. (+7/-1/0) 18:27:01 _jakub_ I don't see what minidebuginfo gives us as advantage for bugreporting, in theory all you need is addresses (relative to start of DSOs) and their build-ids, everything can be recomputed from that So there, THE expert on the domain tells you the bloat is totally useless, but it's too late, you already rushed out a vote of a bunch of marginal +1s. :-/ 18:27:03 limburgher I wish spins could stay on CDs, but then I still want CD and floppy install media. stares wistfully into the past Floppies are clearly too small. CDs are not. They'd fit all we need if it weren't for the completely useless bloat added by features such as this. I also object to the fact that the feature owners have spun the feature proposal in a deliberately misleading way: * increase quality of bug reports? – ABRT won't even use this! * allow easier support for profiling and user space tracing? – Why wouldn't one just install -debuginfo for those tasks? It's not what a user needs to do every day. * misleading percentages – see Talk page * Also note that for shared objects, we already HAVE symbols for the exported functions (for free!), which is often
Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Jaroslav Reznik wrote: Other possibility is to go directly to 1 GiB but we are not sure there's advantage (at least not now). You would probably want to make the target 1 GB (SI units), not 1 GiB. The capacity of thumb drives is measured in SI units, so a 1 GB thumb drive really is 1000^3 bytes, not 1024^3. (They start out with the binary capacity, but some fraction of that is used for overhead, leaving some amount between the SI and binary size. Hence the advertising refers to the SI size.) So we'd like to hear from rel-engs, QA etc. what's theirs position here. AFAIK the only QA issue would be getting notified as to what the new target is, so the size tests can be modified. You probably also want to create a page https://fedoraproject.org/wiki/Releases/18/Spins with the new size. The corresponding page currently exists for 16, but not 17 or 18. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 19.06.12 16:42, Andre Robatino (robat...@fedoraproject.org) wrote: Jaroslav Reznik wrote: Other possibility is to go directly to 1 GiB but we are not sure there's advantage (at least not now). You would probably want to make the target 1 GB (SI units), not 1 GiB. The capacity of thumb drives is measured in SI units, so a 1 GB thumb drive really is 1000^3 bytes, not 1024^3. (They start out with the binary capacity, but some fraction of that is used for overhead, leaving some amount between the SI and binary size. Hence the advertising refers to the SI size.) For those too lazy to calculate the difference between 1 GB and 1 GiB: 1 GB equals 953 MiB. We hence should probably stick to to 950 MiB as new target image size. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 04:19 PM, Jaroslav Reznik wrote: So we'd like to hear from rel-engs, QA etc. what's theirs position here. First and foremost each SIG sets and choose what is on the spin they ship so if you dont want to ship the bloat that gets added with the MiniDebugInfo then simply don't atleast afaik now there is nothing forcing spins to ship something that they don't want to. With my QA hat on I can tell you that we test components that make up the spin(s) but do not care anything about the size of the spins nor should we since as I said before that decision should be made/handled by the SIG since they are the ones creating the spins to suit *their* target audience as best as they can. And given that releng is a community service like QA I guess the only concern they might have if there are enough resources available to host the spin... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Jóhann B. Guðmundsson wrote: First and foremost each SIG sets and choose what is on the spin they ship so if you dont want to ship the bloat that gets added with the MiniDebugInfo then simply don't atleast afaik now there is nothing forcing spins to ship something that they don't want to. How would you suggest we implement this? rm -rf the stuff in %post? (Yuck!!!) As I understand it, the symbols will be bloating the main packages and not be in subpackages. (Debuginfo subpackages are what we have now.) With my QA hat on I can tell you that we test components that make up the spin(s) but do not care anything about the size of the spins nor should we since as I said before that decision should be made/handled by the SIG since they are the ones creating the spins to suit *their* target audience as best as they can. The target size is one of the release-blocking criteria you're supposed to validate. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 05:02 PM, Lennart Poettering wrote: 950 MiB as new target image size. Arguably we should not have any specific target image size but rather a list of valid image sizes ( cd/dvd/usb keys ) for spins to aim at which SIG's themselves choose to use each release cycle and can adjust accordingly which gives them the ability to shrink/expand to suit *their* targets audience needs at any given time. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Kevin Kofler wrote: How would you suggest we implement this? rm -rf the stuff in %post? (Yuck!!!) As I understand it, the symbols will be bloating the main packages and not be in subpackages. (Debuginfo subpackages are what we have now.) It would be nice if the minidebuginfo data was stored similar to debuginfo data. That way spins could easily rm -rf the minidebuginfo folder to keep images smaller. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Michael Cronenworth wrote: It would be nice if the minidebuginfo data was stored similar to debuginfo data. That way spins could easily rm -rf the minidebuginfo folder to keep images smaller. The only similarity being the separated symbol data from the binary. I do not mean sub-packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Lennart Poettering mzerqung at 0pointer.de writes: For those too lazy to calculate the difference between 1 GB and 1 GiB: 1 GB equals 953 MiB. We hence should probably stick to to 950 MiB as new target image size. To avoid confusion over units or rounding/truncation (1 GB isn't *exactly* 953 MiB, for example), the QA size tests are expressed in bytes - see https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 05:15 PM, Kevin Kofler wrote: The target size is one of the release-blocking criteria you're supposed to validate. Yeah but that's just for the Default spin not spins in general which is the Gnome Desktop environment. If we did not have the so called Default we would be validating that spins would fit the valid image size it has chosen for *their* target audience. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 2012-06-19 at 12:19 -0400, Jaroslav Reznik wrote: As reaction to approved MiniDebugInfo feature, we agreed on KDE SIG meeting that we would have to break CD size limit (and the breaking of CD size image was used as argument to accept this feature). We agreed that 800 MiB is achievable target: - all spins will still fit Multi Desktop Live DVD - there's still space available for overlay for USB disks - you can still get 800 MiB CD-Rs (may hit HW constraints...) Other possibility is to go directly to 1 GiB but we are not sure there's advantage (at least not now). Contingency plan - at least for one release we'd like to have a 700 MiB KS (with more compromises). So we'd like to hear from rel-engs, QA etc. what's theirs position here. As far as QA is concerned it's entirely your decision (as a personal note to self, I'll have to update the Deliverables SOP draft). We just need to know so we know what limit to check against in testing. As a personal comment, though, doesn't this seem a little fast to make the decision? Wouldn't it at least make sense to wait for minidebuginfo to be implemented, then spin a test KDE image and see exactly how big it turns out with the current package set? Note that spins are not absolutely required to hit their target size at Alpha; it becomes a hard requirement at Beta stage. So you have up until Beta release to make the decision, really. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 2012-06-19 at 17:26 +, Andre Robatino wrote: Lennart Poettering mzerqung at 0pointer.de writes: For those too lazy to calculate the difference between 1 GB and 1 GiB: 1 GB equals 953 MiB. We hence should probably stick to to 950 MiB as new target image size. To avoid confusion over units or rounding/truncation (1 GB isn't *exactly* 953 MiB, for example), the QA size tests are expressed in bytes - see https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size . FWIW, in the Deliverables SOP I've been working on for a bit - https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables - I went with KiB, at least so far. (The SOP is still under heavy revision, btw.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 2012-06-19 at 17:33 +, Jóhann B. Guðmundsson wrote: On 06/19/2012 05:15 PM, Kevin Kofler wrote: The target size is one of the release-blocking criteria you're supposed to validate. Yeah but that's just for the Default spin not spins in general which is the Gnome Desktop environment. If we did not have the so called Default we would be validating that spins would fit the valid image size it has chosen for *their* target audience. As KDE is a release-blocking desktop, if it fails to meet its size target, that would be a blocker bug, in my estimation. But it remains the case that it's the KDE spin SIG's choice what that target size should be, AFAIK. The criterion says The network installation image, DVD image, and live images for release-blocking desktops must meet current size requirements -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, Jun 19, 2012 at 1:30 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-06-19 at 17:26 +, Andre Robatino wrote: Lennart Poettering mzerqung at 0pointer.de writes: For those too lazy to calculate the difference between 1 GB and 1 GiB: 1 GB equals 953 MiB. We hence should probably stick to to 950 MiB as new target image size. To avoid confusion over units or rounding/truncation (1 GB isn't *exactly* 953 MiB, for example), the QA size tests are expressed in bytes - see https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size . FWIW, in the Deliverables SOP I've been working on for a bit - https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables - I went with KiB, at least so far. (The SOP is still under heavy revision, btw.) Not sure if it's too early, but keep in mind that ARM images will have utterly difference size constraints. -J -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 2012-06-19 at 13:32 -0500, Jon Ciesla wrote: On Tue, Jun 19, 2012 at 1:30 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-06-19 at 17:26 +, Andre Robatino wrote: Lennart Poettering mzerqung at 0pointer.de writes: For those too lazy to calculate the difference between 1 GB and 1 GiB: 1 GB equals 953 MiB. We hence should probably stick to to 950 MiB as new target image size. To avoid confusion over units or rounding/truncation (1 GB isn't *exactly* 953 MiB, for example), the QA size tests are expressed in bytes - see https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size . FWIW, in the Deliverables SOP I've been working on for a bit - https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables - I went with KiB, at least so far. (The SOP is still under heavy revision, btw.) Not sure if it's too early, but keep in mind that ARM images will have utterly difference size constraints. Well, as I'm writing the SOP ARM is still not a primary arch and so it's not considered at all in that draft. If you read it, it mentions specifically the stuff that's delivered as part of the primary arch release and makes no mention of non-primary arch images. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, Jun 19, 2012 at 1:40 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-06-19 at 13:32 -0500, Jon Ciesla wrote: On Tue, Jun 19, 2012 at 1:30 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-06-19 at 17:26 +, Andre Robatino wrote: Lennart Poettering mzerqung at 0pointer.de writes: For those too lazy to calculate the difference between 1 GB and 1 GiB: 1 GB equals 953 MiB. We hence should probably stick to to 950 MiB as new target image size. To avoid confusion over units or rounding/truncation (1 GB isn't *exactly* 953 MiB, for example), the QA size tests are expressed in bytes - see https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size . FWIW, in the Deliverables SOP I've been working on for a bit - https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables - I went with KiB, at least so far. (The SOP is still under heavy revision, btw.) Not sure if it's too early, but keep in mind that ARM images will have utterly difference size constraints. Well, as I'm writing the SOP ARM is still not a primary arch and so it's not considered at all in that draft. If you read it, it mentions specifically the stuff that's delivered as part of the primary arch release and makes no mention of non-primary arch images. I did, and that's entirely appropriate, I just wanted to plant the seed. -J -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 06:32 PM, Adam Williamson wrote: The criterion says The network installation image, DVD image, and live images for release-blocking desktops must meet current size requirements Yup and as usual what is actually considered release blocking desktops question needs to be answered which is something the boards need to clarify and set the criteria for other spins to be able to become one that is if they wont remove Default from it. Something that we in QA need to get clarification on so this wont interfere with our blocker bug process yet again for yet another release cycle... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 2012-06-19 at 18:41 +, Jóhann B. Guðmundsson wrote: On 06/19/2012 06:32 PM, Adam Williamson wrote: The criterion says The network installation image, DVD image, and live images for release-blocking desktops must meet current size requirements Yup and as usual what is actually considered release blocking desktops question needs to be answered which is something the boards need to clarify and set the criteria for other spins to be able to become one that is if they wont remove Default from it. Something that we in QA need to get clarification on so this wont interfere with our blocker bug process yet again for yet another release cycle... I don't believe it does. At present it is clearly understood by everyone that the phrase 'release blocking desktops' refers to GNOME and KDE. This can of course be changed, but the current meaning of the phrase is not in question. This is in fact stated in the preamble to the criteria, on each criteria page: The term 'release-blocking desktops' should be understood to mean all the desktop environments in which bugs are currently considered capable of blocking a Fedora release. The current set of release-blocking desktops is GNOME and KDE. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 07:00 PM, Adam Williamson wrote: The term 'release-blocking desktops' should be understood to mean all the desktop environments in which bugs are currently considered capable of blocking a Fedora release. The current set of release-blocking desktops is GNOME and KDE. The reason for KDE being there is for historic reason at least that what was mentioned when we in QA discussed this and you yourself are well aware of the times we have had to make a chose should we block the release for something that is not considered the default or should we not. The board has yet to clarify what categorizes them as release blocking desktops for other *de and spins to be able to reach that status and probably as well what is required for other spins to get a place on the official dvd as well along with Gnome and KDE. The reason that KDE is there in the first place was probably done at the time to calm down the community without having to remove the default label and the project has evolved quite a much since then as in we have significantly more amounts of spins then just KDE and Gnome. In any case Kevin K. probably can comment on what landed the KDE distribution on the Relengs DVD and on the release blocker in the first place. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 19 Jun 2012 14:00:46 -0700 Jesse Keating jkeat...@j2solutions.net wrote: On 06/19/2012 12:16 PM, Jóhann B. Guðmundsson wrote: In any case Kevin K. probably can comment on what landed the KDE distribution on the Relengs DVD and on the release blocker in the first place. Gnome and KDE were both on the release DVD/CDs since pre-Fedora. They were the only desktops on the release media of note. When we created Fedora Core and then Fedora Extras, KDE remained in Core to continue to be on the release media. When we merged Core and Extras KDE remained on the release DVD, partly because of historical status, and partly because of general sentiment that it was the #1 alternative desktop to the Gnome default. When the Release Blocking Desktops set was decided, it was likely based on what was on the DVD. I'll add to that to note that we now have Xfce, LXDE and Sugar all on the DVD. I've considered asking about making Xfce a blocking desktop, but I have no idea how the LXDE and Sugar communities are with helping testing, etc. It would mean added burden on QA folks to test more stuff, and added burden on maintainers of those desktops to create timely fixes for any blocker issues that come up. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 02:03 PM, Kevin Fenzi wrote: On Tue, 19 Jun 2012 14:00:46 -0700 Jesse Keating jkeat...@j2solutions.net wrote: On 06/19/2012 12:16 PM, Jóhann B. Guðmundsson wrote: In any case Kevin K. probably can comment on what landed the KDE distribution on the Relengs DVD and on the release blocker in the first place. Gnome and KDE were both on the release DVD/CDs since pre-Fedora. They were the only desktops on the release media of note. When we created Fedora Core and then Fedora Extras, KDE remained in Core to continue to be on the release media. When we merged Core and Extras KDE remained on the release DVD, partly because of historical status, and partly because of general sentiment that it was the #1 alternative desktop to the Gnome default. When the Release Blocking Desktops set was decided, it was likely based on what was on the DVD. I'll add to that to note that we now have Xfce, LXDE and Sugar all on the DVD. I've considered asking about making Xfce a blocking desktop, but I have no idea how the LXDE and Sugar communities are with helping testing, etc. It would mean added burden on QA folks to test more stuff, and added burden on maintainers of those desktops to create timely fixes for any blocker issues that come up. kevin Having a desktop be a blocking desktop also somewhat assumes you'll be getting QA volunteer time to run through your test cases, whereas when it's not blocking there isn't that assumption. The SIG can still create and validate their own test and release criteria, and propose something as a blocker, but it's not guaranteed to be accepted. At least that's how I see it from when I was involved in the release process. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 2012-06-19 at 19:16 +, Jóhann B. Guðmundsson wrote: On 06/19/2012 07:00 PM, Adam Williamson wrote: The term 'release-blocking desktops' should be understood to mean all the desktop environments in which bugs are currently considered capable of blocking a Fedora release. The current set of release-blocking desktops is GNOME and KDE. The reason for KDE being there is for historic reason at least that what was mentioned when we in QA discussed this and you yourself are well aware of the times we have had to make a chose should we block the release for something that is not considered the default or should we not. The board has yet to clarify what categorizes them as release blocking desktops for other *de and spins to be able to reach that status and probably as well what is required for other spins to get a place on the official dvd as well along with Gnome and KDE. The reason that KDE is there in the first place was probably done at the time to calm down the community without having to remove the default label and the project has evolved quite a much since then as in we have significantly more amounts of spins then just KDE and Gnome. In any case Kevin K. probably can comment on what landed the KDE distribution on the Relengs DVD and on the release blocker in the first place. Sure. The process needs some cleaning up. But my point is that there is no confusion about the actual facts of the current situation: KDE and GNOME are considered to have equal status as far as release validation is concerned. Note that Xfce, LXDE and Sugar are all also on the DVD at present. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 2012-06-19 at 14:10 -0700, Jesse Keating wrote: Having a desktop be a blocking desktop also somewhat assumes you'll be getting QA volunteer time to run through your test cases, whereas when it's not blocking there isn't that assumption. The SIG can still create and validate their own test and release criteria, and propose something as a blocker, but it's not guaranteed to be accepted. At least that's how I see it from when I was involved in the release process. More or less, except we never take issues specific to non-blocking desktops as blockers; it's not a discretionary thing, it's just a straight line. By policy, a bug specific to Xfce or LXDE (or any other desktop beside KDE/GNOME) cannot block release. Bugs in non-blocking desktops that would block release if they were in blocking desktops are automatically given NTH status. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 09:03 PM, Kevin Fenzi wrote: I'll add to that to note that we now have Xfce, LXDE and Sugar all on the DVD. Which should have been added to the release blocker process when it got added there. From my point of view any handed out media at various events etc and what's on it should be considered release blocker. I've considered asking about making Xfce a blocking desktop, but I have no idea how the LXDE and Sugar communities are with helping testing, etc. It would mean added burden on QA folks to test more stuff, and added burden on maintainers of those desktops to create timely fixes for any blocker issues that come up. There is no such thing as added burden on QA + Me and James had already solved that problem long ago but never found the time to implement it like so many other things because we both where a bit busy with our $dayjobs. The solution was more or less this way If an manpower to cover anything else then critical path became a concern we should fetch that manpower from the relevant SIG's community. Basically the plan was to reach out for example to the Gnome/KDE/XFCE/LXDE/Sugar community's to ask for assistant to cover their relevant part of required testing if that was the case. If you think about it who are better qualified and more willing to test those components other then the people that are using it on daily bases... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 2012-06-19 at 22:14 +, Jóhann B. Guðmundsson wrote: On 06/19/2012 09:03 PM, Kevin Fenzi wrote: I'll add to that to note that we now have Xfce, LXDE and Sugar all on the DVD. Which should have been added to the release blocker process when it got added there. From my point of view any handed out media at various events etc and what's on it should be considered release blocker. I've considered asking about making Xfce a blocking desktop, but I have no idea how the LXDE and Sugar communities are with helping testing, etc. It would mean added burden on QA folks to test more stuff, and added burden on maintainers of those desktops to create timely fixes for any blocker issues that come up. There is no such thing as added burden on QA + Me and James had already solved that problem long ago but never found the time to implement it like so many other things because we both where a bit busy with our $dayjobs. The solution was more or less this way If an manpower to cover anything else then critical path became a concern we should fetch that manpower from the relevant SIG's community. Basically the plan was to reach out for example to the Gnome/KDE/XFCE/LXDE/Sugar community's to ask for assistant to cover their relevant part of required testing if that was the case. If you think about it who are better qualified and more willing to test those components other then the people that are using it on daily bases... This is fine in theory, but it doesn't hold up terribly well in practice. Just about every time we roll a TC/RC, I mail the lists for each desktop - GNOME, KDE, Xfce, LXDE, and Sugar - and ask for help in filling out the validation matrix. We get help fairly often for GNOME and KDE, and satellit_ usually covers Sugar, but we very rarely get anything for Xfce or LXDE. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 03:19 PM, Adam Williamson wrote: If an manpower to cover anything else then critical path became a concern we should fetch that manpower from the relevant SIG's community. Basically the plan was to reach out for example to the Gnome/KDE/XFCE/LXDE/Sugar community's to ask for assistant to cover their relevant part of required testing if that was the case. If you think about it who are better qualified and more willing to test those components other then the people that are using it on daily bases... This is fine in theory, but it doesn't hold up terribly well in practice. Just about every time we roll a TC/RC, I mail the lists for each desktop - GNOME, KDE, Xfce, LXDE, and Sugar - and ask for help in filling out the validation matrix. We get help fairly often for GNOME and KDE, and satellit_ usually covers Sugar, but we very rarely get anything for Xfce or LXDE. At which point you have to decide If nobody is willing to test it, can we really call it a blocker? or you just block the whole release until somebody comes along and tests it (usually yourself). Ultimatums that require people to do work don't often fly here in Fedora land. Ultimatums that are arranged in do this, or you lose that status tend to work better, because the failure case is easier to handle. They lose $status and life moves on. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 10:19 PM, Adam Williamson wrote: Basically the plan was to reach out for example to the Gnome/KDE/XFCE/LXDE/Sugar community's to ask for assistant to cover their relevant part of required testing if that was the case. If you think about it who are better qualified and more willing to test those components other then the people that are using it on daily bases... This is fine in theory, but it doesn't hold up terribly well in practice. Just about every time we roll a TC/RC, I mail the lists for each desktop - GNOME, KDE, Xfce, LXDE, and Sugar - and ask for help in filling out the validation matrix. We get help fairly often for GNOME and KDE, and satellit_ usually covers Sugar, but we very rarely get anything for Xfce or LXDE. Oh I'm pretty sure our solution works as well on paper as it does on the field. What's happening in the XFCE/LXDE community's is that the head of those SIG's aren't doing a great job of mobilizing their community to increase activities and participation in them which means that we ( QA ) might have to step up and be more visible in those community ( that is if they cant increase more activities in them ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 2012-06-19 at 15:31 -0700, Jesse Keating wrote: On 06/19/2012 03:19 PM, Adam Williamson wrote: If an manpower to cover anything else then critical path became a concern we should fetch that manpower from the relevant SIG's community. Basically the plan was to reach out for example to the Gnome/KDE/XFCE/LXDE/Sugar community's to ask for assistant to cover their relevant part of required testing if that was the case. If you think about it who are better qualified and more willing to test those components other then the people that are using it on daily bases... This is fine in theory, but it doesn't hold up terribly well in practice. Just about every time we roll a TC/RC, I mail the lists for each desktop - GNOME, KDE, Xfce, LXDE, and Sugar - and ask for help in filling out the validation matrix. We get help fairly often for GNOME and KDE, and satellit_ usually covers Sugar, but we very rarely get anything for Xfce or LXDE. At which point you have to decide If nobody is willing to test it, can we really call it a blocker? or you just block the whole release until somebody comes along and tests it (usually yourself). Ultimatums that require people to do work don't often fly here in Fedora land. Ultimatums that are arranged in do this, or you lose that status tend to work better, because the failure case is easier to handle. They lose $status and life moves on. Sure. My concern with the Xfce/LXDE case is that I'm sure it's worth going through a 'declare them blockers and expecting testing to come from the community, find that testing doesn't happen, declare them not blockers any more' cycle if we're 95% sure that's what would happen. I'd be happier either just committing QA to finding the time to test them if necessary, or not making them blockers at all. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 2012-06-19 at 22:33 +, Jóhann B. Guðmundsson wrote: On 06/19/2012 10:19 PM, Adam Williamson wrote: Basically the plan was to reach out for example to the Gnome/KDE/XFCE/LXDE/Sugar community's to ask for assistant to cover their relevant part of required testing if that was the case. If you think about it who are better qualified and more willing to test those components other then the people that are using it on daily bases... This is fine in theory, but it doesn't hold up terribly well in practice. Just about every time we roll a TC/RC, I mail the lists for each desktop - GNOME, KDE, Xfce, LXDE, and Sugar - and ask for help in filling out the validation matrix. We get help fairly often for GNOME and KDE, and satellit_ usually covers Sugar, but we very rarely get anything for Xfce or LXDE. Oh I'm pretty sure our solution works as well on paper as it does on the field. What's happening in the XFCE/LXDE community's is that the head of those SIG's aren't doing a great job of mobilizing their community to increase activities and participation in them which means that we ( QA ) might have to step up and be more visible in those community ( that is if they cant increase more activities in them ). I'm not entirely sure your perception of these 'communities' is accurate. The LXDE list had one mail in the entirety of May, for instance. (It's had a staggering four so far this month). Xfce is substantially more active, and we might have more success in getting testing if we make a stronger effort there, I guess. But I am not sure the Fedora LXDE 'community' is strong enough that we can reasonably expect contributed testing on a regular basis. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 10:36 PM, Adam Williamson wrote: On Tue, 2012-06-19 at 15:31 -0700, Jesse Keating wrote: On 06/19/2012 03:19 PM, Adam Williamson wrote: If an manpower to cover anything else then critical path became a concern we should fetch that manpower from the relevant SIG's community. Basically the plan was to reach out for example to the Gnome/KDE/XFCE/LXDE/Sugar community's to ask for assistant to cover their relevant part of required testing if that was the case. If you think about it who are better qualified and more willing to test those components other then the people that are using it on daily bases... This is fine in theory, but it doesn't hold up terribly well in practice. Just about every time we roll a TC/RC, I mail the lists for each desktop - GNOME, KDE, Xfce, LXDE, and Sugar - and ask for help in filling out the validation matrix. We get help fairly often for GNOME and KDE, and satellit_ usually covers Sugar, but we very rarely get anything for Xfce or LXDE. At which point you have to decide If nobody is willing to test it, can we really call it a blocker? or you just block the whole release until somebody comes along and tests it (usually yourself). Ultimatums that require people to do work don't often fly here in Fedora land. Ultimatums that are arranged in do this, or you lose that status tend to work better, because the failure case is easier to handle. They lose $status and life moves on. Sure. My concern with the Xfce/LXDE case is that I'm sure it's worth going through a 'declare them blockers and expecting testing to come from the community, find that testing doesn't happen, declare them not blockers any more' cycle if we're 95% sure that's what would happen. I'd be happier either just committing QA to finding the time to test them if necessary, or not making them blockers at all. Again anything that gets handed out at various events should be considered release blockers since the quality of that product reflects back at us as a community thus if an relevant SIG cannot cover it's own release testing apart from what we consider core and QA handles ( which in essence is what those spins build upon ) it should be removed from anything we officially hand out thus no longer be considered release blockers. JBG JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, Jun 19, 2012 at 2:47 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Again anything that gets handed out at various events should be considered release blockers since the quality of that product reflects back at us as a community thus if an relevant SIG cannot cover it's own release testing apart from what we consider core and QA handles ( which in essence is what those spins build upon ) it should be removed from anything we officially hand out thus no longer be considered release blockers. At what point in the process would you place the go-no-go as to the release of a specific deliverable as an official spin? In an effort to not beatup an existing subgroup that is perhaps shorthanded I'll talk about a hypthetical situation. For the sake of argument lets assume I and a small group of heroic people were able to beat CDE into shape as a new fedora spin. Retro is the new hotness right... We get a spin out the door we get on the spins page for a release or twowe are rocking the world. And then for some reason on the next release we all fall behind and we don't keep up with the necessary integration changes. And CDE is just horribly broken for months. A lot of bugs get set as release blockers and we are pinged...but we just don't get the work done. At one point in the pre-release process does our Spin get culled from the herd and we are told..sorry..this release won't have a CDE spin? At what point does the QA and release team just punt? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 2012-06-19 at 22:55 +, Jóhann B. Guðmundsson wrote: I always look at the [1] and the top spins for (potential) contributing base and always when I look there people seem to be downloading LXDE more than XFCE heck I even mention that to Christoph one time and he was not sure if he should laugh or cry since he has put more time in maintaining the XFCE spin than he has with the LXDE one. Looking at mailing list activities is not a good measurement either since participation there is highly depended upon discussion on that list. 'Potential' is right. In this context I'd prefer to look at the _actual_ contributing base, and the best proxy I could think of for that was mailing list participation. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 2012-06-19 at 14:59 -0800, Jef Spaleta wrote: We get a spin out the door we get on the spins page for a release or twowe are rocking the world. And then for some reason on the next release we all fall behind and we don't keep up with the necessary integration changes. And CDE is just horribly broken for months. A lot of bugs get set as release blockers and we are pinged...but we just don't get the work done. At one point in the pre-release process does our Spin get culled from the herd and we are told..sorry..this release won't have a CDE spin? At what point does the QA and release team just punt? We don't have any precedent or process for that, as we've only ever had the two release blocking desktops, and they have always been solidly maintained. In practice, I suspect that our processes are comprehensive enough that we'd notice at Alpha or, at latest, Beta stage that a blocking desktop was horribly broken and not being fixed, and between Alpha and Beta or Beta and Final we'd try and get something done about it; if it wasn't done, we'd take the desktop off the list before the first TC. But that's just a guess. It's worth noting that we certainly have shipped non-blocking spins in completely broken states in past releases, and there is at present nothing to prevent this happening. There is zero guarantee of testing for non-blocking spins. QA did no formal validation of any spins besides Desktop, KDE, LXDE, Xfce and Sugar for F17. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 03:59 PM, Jef Spaleta wrote: On Tue, Jun 19, 2012 at 2:47 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Again anything that gets handed out at various events should be considered release blockers since the quality of that product reflects back at us as a community thus if an relevant SIG cannot cover it's own release testing apart from what we consider core and QA handles ( which in essence is what those spins build upon ) it should be removed from anything we officially hand out thus no longer be considered release blockers. At what point in the process would you place the go-no-go as to the release of a specific deliverable as an official spin? In an effort to not beatup an existing subgroup that is perhaps shorthanded I'll talk about a hypthetical situation. For the sake of argument lets assume I and a small group of heroic people were able to beat CDE into shape as a new fedora spin. Retro is the new hotness right... We get a spin out the door we get on the spins page for a release or twowe are rocking the world. And then for some reason on the next release we all fall behind and we don't keep up with the necessary integration changes. And CDE is just horribly broken for months. A lot of bugs get set as release blockers and we are pinged...but we just don't get the work done. At one point in the pre-release process does our Spin get culled from the herd and we are told..sorry..this release won't have a CDE spin? At what point does the QA and release team just punt? -jef We already have a go/ no go line built into the schedule. It's the Feature Freeze line. Things are supposed to be in a testable state by that point. If your desktop is so broken as to not even be testable, that's reason to drop it. I believe that's the transition from Alpha to Beta. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
