Re: Fedora 23 Final RC10 status is GO !
On Mon, 2015-11-09 at 17:11 -0800, Adam Williamson wrote: > On Mon, 2015-11-09 at 13:56 +0100, Kevin Kofler wrote: > > Kamil Paral wrote: > > > So we could ignore freeze just for packages not being on any install > > > medium. But then I'm not sure how much that is helpful and it might be > > > difficult to implement this in Bodhi. > > > > In the old manual process, I just had to ask rel-eng and they'd blanket-OK > > freeze overrides for such packages (with the same arguments as yours, i.e., > > it cannot really break anything). > > Yes - and that frequently went wrong. That's precisely why we ditched > that process and came up with a better one, where the decision isn't > made on-the-fly by whoever happens to be reading the tickets in releng, > but is made according to an established process, by a sensible group of > stakeholders, with proper tracking and a paper trail. Sorry, I missed that you were talking about packages not on the release media. Yeah, those are kind of odd because you can argue them either way: on the one hand pulling them in is unlikely to break anything, on the other hand, what's the point of doing it? I'd usually still err on the side of caution and leave them out, just in case they somehow break the buildroot or do something else strange, if there's no actual particular reason to push them. And yes, there is an obvious technical problem - we don't actually have the ability, right now, to know for sure exactly what packages are somehow directly involved in building the media. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Mon, 2015-11-09 at 13:56 +0100, Kevin Kofler wrote: > Kamil Paral wrote: > > So we could ignore freeze just for packages not being on any install > > medium. But then I'm not sure how much that is helpful and it might be > > difficult to implement this in Bodhi. > > In the old manual process, I just had to ask rel-eng and they'd blanket-OK > freeze overrides for such packages (with the same arguments as yours, i.e., > it cannot really break anything). Yes - and that frequently went wrong. That's precisely why we ditched that process and came up with a better one, where the decision isn't made on-the-fly by whoever happens to be reading the tickets in releng, but is made according to an established process, by a sensible group of stakeholders, with proper tracking and a paper trail. > These days, such freeze override requests > get blanket-rejected instead (because it doesn't make much of a difference, > so they don't see any reason to make exceptions to the processes). Nothing gets blanket rejected. Each FE proposal is evaluated individually on its merits. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
Kamil Paral wrote: > So we could ignore freeze just for packages not being on any install > medium. But then I'm not sure how much that is helpful and it might be > difficult to implement this in Bodhi. In the old manual process, I just had to ask rel-eng and they'd blanket-OK freeze overrides for such packages (with the same arguments as yours, i.e., it cannot really break anything). These days, such freeze override requests get blanket-rejected instead (because it doesn't make much of a difference, so they don't see any reason to make exceptions to the processes). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
> Very frequently in such cases the entire test matrix is not completely > retested. A lot of prior tests a carried over because they're known > (or strongly suspected) of not having been touched in any way by the > fix of one or two blocker bugs. > > If hundreds of packages get unfrozen and sync'd all bets are off. The > state of the release is now sufficiently non-determinstic that it > means all testing has to be started completely from scratch. So I > would say no, this isn't a good idea, just because the resources > aren't there to do this additional amount of testing. > > The goal isn't to have a release that's super current. It's to have a > release that's stable and works. I think that Chris described it very well. I'm quite skeptical that such a proposal would work in practice because of these reasons. It's quite demanding for us to just fix and test the outstanding blockers. Updating everything would mean: a) retesting everything from scratch, and of course our testing covers only a few selected areas, we rely on many people from community to report blockers when they find them -- that takes time, not just a few days of testing crunch b) potentially breaking anything, from boot to installer to desktop environment to apps Of course if things break immediately after first system update, our users are not much better off. But at least the install medium booted and installer worked. The broken updates can be fixed, they are not baked into the install medium. Maybe we could consider some middle approach, where things not in the critical path (not directly affecting the core system and installer) would not be affected by freeze. That shouldn't break much and would help many pre-release users and maintainers. It can still introduce new blockers, though, if those apps are e.g. on Live medium or are installed by Server by default (and then don't start). So we could ignore freeze just for packages not being on any install medium. But then I'm not sure how much that is helpful and it might be difficult to implement this in Bodhi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Wed, Nov 4, 2015 at 3:30 PM, Kevin Fenzi wrote: > On Tue, 3 Nov 2015 09:23:49 +0100 > Petr Spacek wrote: > >> On 3.11.2015 01:56, Kevin Kofler wrote: >> > And with my proposed change to the release >> > policy (slip = unfreeze, sync all updates, refreeze), you could >> > also use the time to get fixes/improvements in that would have >> > otherwise missed the release. >> >> +1, this seems like a very reasonable proposal to me. > > The problem here is that a slip is a week. > > Right now, if we slip it's usually just a bug or two and those get > worked on and we spin a new RC and test, etc. > > If we did this it could mean potentially lots more blockers, so it > could leed to longer slips. Also, it could make changes such that > things don't even compose. > > But it's an interesting idea. > I'd love to hear what QA folks think about it. Very frequently in such cases the entire test matrix is not completely retested. A lot of prior tests a carried over because they're known (or strongly suspected) of not having been touched in any way by the fix of one or two blocker bugs. If hundreds of packages get unfrozen and sync'd all bets are off. The state of the release is now sufficiently non-determinstic that it means all testing has to be started completely from scratch. So I would say no, this isn't a good idea, just because the resources aren't there to do this additional amount of testing. The goal isn't to have a release that's super current. It's to have a release that's stable and works. The proposal could be attempted for alpha to see what happens in a less detrimental fashion. But for final, it's already enough of whack a mole, and this would be like putting the moles on fertility drugs. Or throwing a deck of cards up into the air to shuffle it. Or... -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Tue, 3 Nov 2015 09:23:49 +0100 Petr Spacek wrote: > On 3.11.2015 01:56, Kevin Kofler wrote: > > And with my proposed change to the release > > policy (slip = unfreeze, sync all updates, refreeze), you could > > also use the time to get fixes/improvements in that would have > > otherwise missed the release. > > +1, this seems like a very reasonable proposal to me. The problem here is that a slip is a week. Right now, if we slip it's usually just a bug or two and those get worked on and we spin a new RC and test, etc. If we did this it could mean potentially lots more blockers, so it could leed to longer slips. Also, it could make changes such that things don't even compose. But it's an interesting idea. I'd love to hear what QA folks think about it. kevin pgpsJhhVjxSB1.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Tue, 2015-11-03 at 02:28 +0100, Kevin Kofler wrote: > (And to those people who want to do "service packs": please focus > your > "service pack" testing on the respins instead, and don't break the > existing > update system that works fine.) Yeah, there's really no reason service packs would have to be mandatory. It could definitely be layered on top of the existing system. Well, someone would have to implement it that way, of course Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On 3.11.2015 01:56, Kevin Kofler wrote: > And with my proposed change to the release > policy (slip = unfreeze, sync all updates, refreeze), you could also use the > time to get fixes/improvements in that would have otherwise missed the > release. +1, this seems like a very reasonable proposal to me. -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Mon, 2015-11-02 at 20:27 -0500, Eric Griffith wrote: > Hey all, hate to be a downer but we might have a bug in the installer > > Just installed F23 Workstation via RC10. Encryption with btrfs across > two > drives. Intel graphics (Lenovo t450s if anyone has access to one). > Installed the system, rebooted into system. I get met with a black > screen > and the text > > "Error: Can't find the command: /dev/mapper/luks-0be > > Press any key to continue" > > Boot continues forward without any action on users behalf, despite > what is > displayed. Plymouth never loads, text based loading. I got prompted > for > encryption passphrase, supply it, boot continues. > > I get "A start job is running for dev-mapper-luks\(random > characters).device ( (timer counter) / no limit)" > > And then boot stalls with the counter incrementing. Will try a > reinstall > later tonight, but before I do that does anyone need / want debug > info? > Adam? File a bug, I guess. I don't think we test encrypted btrfs - we test btrfs, and we test encryption, but the brtfs tests don't specify encryption and the encryption tests just use the default filesystem (so ext4 or xfs). The installer has lots of bugs. We know about some of them. ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
I think official respins are a good idea, indeed. But: Kevin Fenzi wrote: > So, in order to do what you are wanting we need (at least) 3 things: > > 1) releng has to make every daily compose a full compose of all > deliverables. We have actually been working toward this, and perhaps [snip] > 2) QA would need to be able to do a full release validation on a set of > deliverables _every day_. Again, we are making progress here, we have Who said we'd have to do a respin every day? Having weekly, biweekly or monthly respins would be enough, as long as the updates keep flowing daily. Just do the respins only as often as resources (including QA) allow. (And to those people who want to do "service packs": please focus your "service pack" testing on the respins instead, and don't break the existing update system that works fine.) I found the existing live respins to be very helpful even though they are not done anywhere near daily. A simple yum/dnf update gets you fully up to date, and the respins decrease the amount of needed updates significantly. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
Hey all, hate to be a downer but we might have a bug in the installer Just installed F23 Workstation via RC10. Encryption with btrfs across two drives. Intel graphics (Lenovo t450s if anyone has access to one). Installed the system, rebooted into system. I get met with a black screen and the text "Error: Can't find the command: /dev/mapper/luks-0be Press any key to continue" Boot continues forward without any action on users behalf, despite what is displayed. Plymouth never loads, text based loading. I got prompted for encryption passphrase, supply it, boot continues. I get "A start job is running for dev-mapper-luks\(random characters).device ( (timer counter) / no limit)" And then boot stalls with the counter incrementing. Will try a reinstall later tonight, but before I do that does anyone need / want debug info? Adam? --Eric On Nov 2, 2015 19:56, "Kevin Kofler" wrote: > Michael Catanzaro wrote: > > My recommendation is the opposite of what Kevin would say, though. I'd > > like to see a third party responsible for giving final approval on all > > updates, charged with reducing the size of the updates pipe dramatically. > > Maintainers should not have final say on updates except in the event of a > > serious regression (in which case we need a revert button to skip > > updates-testing). > > No thanks! If I wanted a distribution with such a strict control on > updates, > I'd use RHEL/CentOS, not Fedora! The fact that bugs actually get fixed in > Fedora (whereas in conservative distributions, they often tell you to wait > for the next release that comes months to years later) and that we even get > new improved versions of applications is a huge advantage of Fedora, and > also part of what Fedora is about (see "First"). Throwing it away would be > a > very bad idea. > > I actually think we need a MORE update-friendly policy, where we recommend > always pushing new versions unless there is a good reason not to. (The > current policies are written the other way round, they recommend NOT > pushing > new feature releases unless there is a good reason to. I have been > complaining about that right from the day it was written down.) > > > An alternative we've been throwing around in the Workstation group is > > service packs (or "update packs") -- all non-security updates get bundled > > together, QAed, and released every 4-8 weeks. If you want to get your > > update out faster than that, you need a CVE or a special exception. > > All that this accomplishes is delaying much needed fixes, it doesn't really > solve any problem. It just creates new ones, such as dumping a huge set of > updates on the user all at once, leading to bandwidth bottlenecks, and a > higher risk of breakage on the flag days. > > > Then we need to have separate release cycles for each product, since I > > don't want Workstation blocked indefinitely on everything > > Cloud/Server/KDE want to fix, and presumably those groups don't want to > > block on us... it's frankly annoying to me that we risk blocking > > Workstation on such issues, but it's a compromise we need to make to > > ensure the other releases are good. (And that vice-versa when the other > > releases get blocked on Workstation issues.) As long as we have four > > separate releases on the same cycle, it makes sense that QA gets final > > say. > > This egoistical attitude is what is preventing us from shipping quality > releases. The sky is not going to fall if your product/edition/spin gets > released a couple weeks later. And with my proposed change to the release > policy (slip = unfreeze, sync all updates, refreeze), you could also use > the > time to get fixes/improvements in that would have otherwise missed the > release. > > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
Michael Catanzaro wrote: > My recommendation is the opposite of what Kevin would say, though. I'd > like to see a third party responsible for giving final approval on all > updates, charged with reducing the size of the updates pipe dramatically. > Maintainers should not have final say on updates except in the event of a > serious regression (in which case we need a revert button to skip > updates-testing). No thanks! If I wanted a distribution with such a strict control on updates, I'd use RHEL/CentOS, not Fedora! The fact that bugs actually get fixed in Fedora (whereas in conservative distributions, they often tell you to wait for the next release that comes months to years later) and that we even get new improved versions of applications is a huge advantage of Fedora, and also part of what Fedora is about (see "First"). Throwing it away would be a very bad idea. I actually think we need a MORE update-friendly policy, where we recommend always pushing new versions unless there is a good reason not to. (The current policies are written the other way round, they recommend NOT pushing new feature releases unless there is a good reason to. I have been complaining about that right from the day it was written down.) > An alternative we've been throwing around in the Workstation group is > service packs (or "update packs") -- all non-security updates get bundled > together, QAed, and released every 4-8 weeks. If you want to get your > update out faster than that, you need a CVE or a special exception. All that this accomplishes is delaying much needed fixes, it doesn't really solve any problem. It just creates new ones, such as dumping a huge set of updates on the user all at once, leading to bandwidth bottlenecks, and a higher risk of breakage on the flag days. > Then we need to have separate release cycles for each product, since I > don't want Workstation blocked indefinitely on everything > Cloud/Server/KDE want to fix, and presumably those groups don't want to > block on us... it's frankly annoying to me that we risk blocking > Workstation on such issues, but it's a compromise we need to make to > ensure the other releases are good. (And that vice-versa when the other > releases get blocked on Workstation issues.) As long as we have four > separate releases on the same cycle, it makes sense that QA gets final > say. This egoistical attitude is what is preventing us from shipping quality releases. The sky is not going to fall if your product/edition/spin gets released a couple weeks later. And with my proposed change to the release policy (slip = unfreeze, sync all updates, refreeze), you could also use the time to get fixes/improvements in that would have otherwise missed the release. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
2015-11-02 21:36 GMT-03:00 Kevin Fenzi : > On Mon, 2 Nov 2015 21:33:45 -0300 > Adrian Soliard wrote: > >> 've a question: >> >> Installing F23 RC10 is the same that wait to the final release? I'm >> planning to install it now, tomorrow I will not have time to download >> and install it. > > yes, rc10 was the exact release candidate that is the final release. > Thanks, Kevin. Downloading... > kevin > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Adrian Soliard asoli...@fedoraproject.org https://fedoraproject.org/wiki/User:Asoliard http://www.adriansoliard.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Mon, 2 Nov 2015 21:33:45 -0300 Adrian Soliard wrote: > 've a question: > > Installing F23 RC10 is the same that wait to the final release? I'm > planning to install it now, tomorrow I will not have time to download > and install it. yes, rc10 was the exact release candidate that is the final release. kevin pgptpyrl9Isee.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
've a question: Installing F23 RC10 is the same that wait to the final release? I'm planning to install it now, tomorrow I will not have time to download and install it. 2015-11-02 19:57 GMT-03:00 Adam Williamson : > On Mon, 2015-11-02 at 10:52 -0700, Kevin Fenzi wrote: >> >> > Perhaps full release validation could occur on composes every two >> > weeks for branched releases? Or is that still too demanding? >> >> No idea. I don't want to speak for the QA folks. > > So to put it simply and broadly: there's a trade-off between how often > we want to release, and how heavily we can test those releases. > > Frankly, no, I don't think it's viable to do the entire current five- > ring circus release validation process every two weeks. It's not just a > question of QA doing the testing, because of course testing without > fixes is meaningless: it's a question of QA, releng, and maintainers > all being perpetually in the 'ah crap it's two weeks before release' > frame of mind. Which isn't really sustainable on the current level, I > don't think. > > But then, that doesn't mean we can't change things, it just means we > re-calibrate our expectations. We can release more often if we want to, > sure: we just have to be okay with each of those releases getting > somewhat less testing. > > As Kevin noted upthread there *are* various ways in which we're > tackling automation of testing, which does help here. You can sketch a > beautiful picture where we build the distribution on CI principles: we > run a whole bunch of automated tests any time anyone sneezes on a > package, and anything that breaks gets rejected, and we can thus spin a > new release from the 'approved' bits any damn time we please and be > sure that it'd work. But, also as Kevin noted, I don't think we can > ever really achieve that perfectly; there's just too much in > distribution testing which isn't fully susceptible to automation, I > think at least in practical terms in the medium-term future there's > always gonna need to be some humans in the loop to some degree. > > That doesn't mean we can't try and move in that direction, though. We > can keep building out the automation efforts to the point where we can > be pushing out 'releases' that we're fairly sure are at least basically > working very frequently. They wouldn't be as heavily tested as our > current traditional heavy 'releases' are, but they also wouldn't be > unknown quantities. In fact, since Flock, we've more or less been doing > this - any time you see a 'compose check report' email with a pretty > small number of openQA failures, you can grab that nightly build and be > reasonably sure that it will at least install and let you log in, > hardware issues excepted (openQA is all virt testing). There are short- > term plans already in place to improve this general area continuously: > releng is moving towards the nightly composes being much more like TCs > and RCs, QA is working to move openQA public, give it more resources, > and add more tests, Taskotron is definitely coming to a point soon > where it'll be feasible to do more forms of release testing in it, and > there are other mechanisms we're looking at too. > > So yeah, if we want to start in *some* form releasing stuff more > frequently, it's possible. We have the technology, and we're making it > better quite frequently. I believe there are plans this cycle to > regularly publish updated Cloud (including Atomic host) images, which > will certainly form a starting point. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Adrian Soliard asoli...@fedoraproject.org https://fedoraproject.org/wiki/User:Asoliard http://www.adriansoliard.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Mon, 2015-11-02 at 10:52 -0700, Kevin Fenzi wrote: > > > Perhaps full release validation could occur on composes every two > > weeks for branched releases? Or is that still too demanding? > > No idea. I don't want to speak for the QA folks. So to put it simply and broadly: there's a trade-off between how often we want to release, and how heavily we can test those releases. Frankly, no, I don't think it's viable to do the entire current five- ring circus release validation process every two weeks. It's not just a question of QA doing the testing, because of course testing without fixes is meaningless: it's a question of QA, releng, and maintainers all being perpetually in the 'ah crap it's two weeks before release' frame of mind. Which isn't really sustainable on the current level, I don't think. But then, that doesn't mean we can't change things, it just means we re-calibrate our expectations. We can release more often if we want to, sure: we just have to be okay with each of those releases getting somewhat less testing. As Kevin noted upthread there *are* various ways in which we're tackling automation of testing, which does help here. You can sketch a beautiful picture where we build the distribution on CI principles: we run a whole bunch of automated tests any time anyone sneezes on a package, and anything that breaks gets rejected, and we can thus spin a new release from the 'approved' bits any damn time we please and be sure that it'd work. But, also as Kevin noted, I don't think we can ever really achieve that perfectly; there's just too much in distribution testing which isn't fully susceptible to automation, I think at least in practical terms in the medium-term future there's always gonna need to be some humans in the loop to some degree. That doesn't mean we can't try and move in that direction, though. We can keep building out the automation efforts to the point where we can be pushing out 'releases' that we're fairly sure are at least basically working very frequently. They wouldn't be as heavily tested as our current traditional heavy 'releases' are, but they also wouldn't be unknown quantities. In fact, since Flock, we've more or less been doing this - any time you see a 'compose check report' email with a pretty small number of openQA failures, you can grab that nightly build and be reasonably sure that it will at least install and let you log in, hardware issues excepted (openQA is all virt testing). There are short- term plans already in place to improve this general area continuously: releng is moving towards the nightly composes being much more like TCs and RCs, QA is working to move openQA public, give it more resources, and add more tests, Taskotron is definitely coming to a point soon where it'll be feasible to do more forms of release testing in it, and there are other mechanisms we're looking at too. So yeah, if we want to start in *some* form releasing stuff more frequently, it's possible. We have the technology, and we're making it better quite frequently. I believe there are plans this cycle to regularly publish updated Cloud (including Atomic host) images, which will certainly form a starting point. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Mon, 2 Nov 2015 12:45:36 -0500 Neal Gompa wrote: ...snip... > I'm hopeful we can get to this with Rawhide prior to the branching > point, but can our infrastructure handle it? I'm somewhat ignorant > of the capabilities of the Fedora infrastructure... Yes, as I noted we are working on it. > Perhaps full release validation could occur on composes every two > weeks for branched releases? Or is that still too demanding? No idea. I don't want to speak for the QA folks. > Could we slip in some settings for TCs that trigger distro-sync > behavior by default on "dnf upgrade"? Or would this still be > undesirable? 90% of the time you can just downgrade a package and it's fine. However, the other 10% of the time it just won't work. Your postgresql database will have a different format. Your package will move a directory to a link or vice versa. The package will have migrated your settings to the new version and the old version will crash. > I think it'd be pretty nice if we could use our mix of automated > tests and checks for composing weekly snapshots of rawhide that would > be "installable" and "usable". This is not a particularly new > idea[0], but in light of the openSUSE guys being able to pull it off > with Tumbleweed, I don't see why we can't get there too. It might be > a little more "raw" than Tumbleweed and serve somewhat a different > purpose, but I think it would make testing the state of the > development tree far easier. Absolutely. We already are. OpenQA has been detecting problems, and we have been fixing them. I think this will result in a increased amount of time that rawhide images are installable. Thats only sort of related to discussions about releases and updates tho. ;) kevin pgpgB0hxvF2sO.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Mon, Nov 2, 2015 at 12:33 PM, Kevin Fenzi wrote: > On Mon, 02 Nov 2015 01:28:07 + > Sérgio Basto wrote: > > > On Dom, 2015-11-01 at 17:53 +, Peter Robinson wrote: > > > On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto > > > wrote: > > > > On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote: > > > >> At the third round of Fedora 23 Final Go/No-Go Meeting, that just > > > >> ends, has been Fedora 23 Final-RC10 declared as GOLD. > > > >> GA of this release is planed on Tuesday 2015-Nov-03. > > > >> > > > > Today we got 531 updates for F23 , IMO, you should include it on > > > > Fedora 23 Final before GA , doesn't make sense (to me) after > > > > download an ISO have 1/2 Giga of updates, but this happens since > > > > RedHad 9 at least . IMO, testing team should respin ISO with > > > > updates and testing again . I have some difficulty in following > > > > all development, fortunately Fedora is always at great speed, but > > > > it is not easy to follow. And do more tests we not lose anything, > > > > IMHO. > > > > > > The problem is we have to freeze sometime to ensure stability in the > > > installer platform, the live and other images which are static. If > > > not it's too much of a moving target to try and QA and ensure > > > everything works as expected. To freeze is a fairly standard > > > procedure for all distro development. > > > > Make an respin for F23 with stable updates, IMHO, should not break > > anything, because at this stage, just stable things are being pushed. > > So it should be just one more loop in testing phase, anyway if breaks > > something test team can freeze process again, until provide a fix. > > This is not new !, respins of fedoraunity was an example and we > > already have living respins [1], so we just need do new respin > > officially!. Shouldn't be a big deal, If I'm not mistaken. > > You are. ;) > > So, in order to do what you are wanting we need (at least) 3 things: > > 1) releng has to make every daily compose a full compose of all > deliverables. We have actually been working toward this, and perhaps > for f24 we will get there. However, even if we do that, we can't make > the daily composes ready for release unless we change our processes > (test composes/daily composes now have some flags where they do things > like pop up the 'this is a test release' dialog in the installer, and > they are called "TC" in the image names). > > I'm hopeful we can get to this with Rawhide prior to the branching point, but can our infrastructure handle it? I'm somewhat ignorant of the capabilities of the Fedora infrastructure... > 2) QA would need to be able to do a full release validation on a set of > deliverables _every day_. Again, we are making progress here, we have > openQA now doing a lot of daily install testing, and taskotron doing a > bunch of testing of things to keep broken packages out of composes. > That said, there's a lot of stuff that just cannot be automated: > testing with specific hardware, looking at issues that aren't in test > cases (like the last minute help in anaconda issue), etc. > Additionally, while I know QA folks have done hero testing and > validated a RC in a day, I think they would revolt if you told them > they had to do this every single day, and I would not blame them at > all. > > Perhaps full release validation could occur on composes every two weeks for branched releases? Or is that still too demanding? > 3) Finally we would need some way to roll back broken things. We have > distro-sync right now, but it cannot always downgrade things. If/when > problems are found sometimes a specific package can be found that > causes the problem, but sometimes it's a lot more complex. Humans need > to dig in and figure out what happened and how to fix it. We could just > say "always use distro-sync in a pre-release, and if you run into > problems, too bad, just re-install" but I think many of our testers > would find this unacceptable. > > Could we slip in some settings for TCs that trigger distro-sync behavior by default on "dnf upgrade"? Or would this still be undesirable? > While I am very happy someone is doing live-respins, I don't think they > go through a complete release validation cycle. There's been talk in > the past of doing updated deliverables on a "well, they composed" > basis, but the idea never got too far. > > I think it'd be pretty nice if we could use our mix of automated tests and checks for composing weekly snapshots of rawhide that would be "installable" and "usable". This is not a particularly new idea[0], but in light of the openSUSE guys being able to pull it off with Tumbleweed, I don't see why we can't get there too. It might be a little more "raw" than Tumbleweed and serve somewhat a different purpose, but I think it would make testing the state of the development tree far easier. > kevin > [0]: https://fedoraproject.org/wiki/Israwhidebroken.com_Proposal -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Fedora 23 Final RC10 status is GO !
On Mon, 02 Nov 2015 01:28:07 + Sérgio Basto wrote: > On Dom, 2015-11-01 at 17:53 +, Peter Robinson wrote: > > On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto > > wrote: > > > On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote: > > >> At the third round of Fedora 23 Final Go/No-Go Meeting, that just > > >> ends, has been Fedora 23 Final-RC10 declared as GOLD. > > >> GA of this release is planed on Tuesday 2015-Nov-03. > > >> > > > Today we got 531 updates for F23 , IMO, you should include it on > > > Fedora 23 Final before GA , doesn't make sense (to me) after > > > download an ISO have 1/2 Giga of updates, but this happens since > > > RedHad 9 at least . IMO, testing team should respin ISO with > > > updates and testing again . I have some difficulty in following > > > all development, fortunately Fedora is always at great speed, but > > > it is not easy to follow. And do more tests we not lose anything, > > > IMHO. > > > > The problem is we have to freeze sometime to ensure stability in the > > installer platform, the live and other images which are static. If > > not it's too much of a moving target to try and QA and ensure > > everything works as expected. To freeze is a fairly standard > > procedure for all distro development. > > Make an respin for F23 with stable updates, IMHO, should not break > anything, because at this stage, just stable things are being pushed. > So it should be just one more loop in testing phase, anyway if breaks > something test team can freeze process again, until provide a fix. > This is not new !, respins of fedoraunity was an example and we > already have living respins [1], so we just need do new respin > officially!. Shouldn't be a big deal, If I'm not mistaken. You are. ;) So, in order to do what you are wanting we need (at least) 3 things: 1) releng has to make every daily compose a full compose of all deliverables. We have actually been working toward this, and perhaps for f24 we will get there. However, even if we do that, we can't make the daily composes ready for release unless we change our processes (test composes/daily composes now have some flags where they do things like pop up the 'this is a test release' dialog in the installer, and they are called "TC" in the image names). 2) QA would need to be able to do a full release validation on a set of deliverables _every day_. Again, we are making progress here, we have openQA now doing a lot of daily install testing, and taskotron doing a bunch of testing of things to keep broken packages out of composes. That said, there's a lot of stuff that just cannot be automated: testing with specific hardware, looking at issues that aren't in test cases (like the last minute help in anaconda issue), etc. Additionally, while I know QA folks have done hero testing and validated a RC in a day, I think they would revolt if you told them they had to do this every single day, and I would not blame them at all. 3) Finally we would need some way to roll back broken things. We have distro-sync right now, but it cannot always downgrade things. If/when problems are found sometimes a specific package can be found that causes the problem, but sometimes it's a lot more complex. Humans need to dig in and figure out what happened and how to fix it. We could just say "always use distro-sync in a pre-release, and if you run into problems, too bad, just re-install" but I think many of our testers would find this unacceptable. While I am very happy someone is doing live-respins, I don't think they go through a complete release validation cycle. There's been talk in the past of doing updated deliverables on a "well, they composed" basis, but the idea never got too far. kevin pgpWfjRfEZQPi.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Mon, Nov 2, 2015 at 9:07 AM, Jonathan Underwood < jonathan.underw...@gmail.com> wrote: > I think it is to some extent a question of what we are QA'ing for. As > I see it (and I may be in the minority), the QA process is a process > put in place to ensure the *install and live media* function > correctly, and produce a working installed system from which the user > can move forward with updates. > Exactly. The purpose of the install and live media is to have a system that functions. Regarding the 500+ updates... No one is forcing you to update your system - and if you do, as another person pointed out, deltarpms will reduce the amount of bandwidth required. If you wait for updates to stop before you decide to go GA, you're going to be waiting forever. Additionally, artificially manipulating the process more than it already is serves no real purpose. It just adds additional work with no real benefit. Eventually there are going to be updates. This seems to me about coming up with additional arbitrary criteria for a system that by its nature is always going to be arbitrary. I think there are more pressing issues and better ways for the community to spend it's resources. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On 1 November 2015 at 22:14, Michael Catanzaro wrote: [snip] > On Sun, 2015-11-01 at 20:03 +0100, Kevin Kofler wrote: >> IMHO, we should have at most 1 week of strict freeze. If we decide >> that we >> have to slip anyway, then we should pull in ALL updates pending >> stable and >> restart the release process (freeze, spin RCs, test) from there. >> >> (That would also make it less painful to slip multiple times and thus >> decrease the pressure to rush out quick hacks to work around blockers >> instead of clean fixes.) > > I think Kevin is closer to right on this. It's unreasonable to have 500 > updates queued for users on release day. Yeah, freeze is required to do > QA on the release, but QA on the release is not worth so much if it all > goes out the door the first time someone clicks update. (Well, it's > essential for the installation process, but beyond that) > [snip] I think it is to some extent a question of what we are QA'ing for. As I see it (and I may be in the minority), the QA process is a process put in place to ensure the *install and live media* function correctly, and produce a working installed system from which the user can move forward with updates. QA has never made any efforts to QA updates, presumably because there's just not sufficient resource. So, in a resource limited world, I think the QA team are doing the most sensible thing they can do with their limited resources. In lieu of QA resource for updates, we have imperfect community processes which we hope provide QA for subsequent updates, though unfortunately the community base that has tested those 500 updates that are available on release day are probably far less than for updates produced after release, when more folks have the release distro installed and are using it and testing updates. I think that's the issue that we could address by engaging the community more though. Any other proposal requiring more from the QA team has to identify where that extra resource comes from. Cheers, Jonathan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
As I found this discussion interesting and I believe FESCo is the right authority to help with this, I have opened a ticket https://fedorahosted.org/fesco/ticket/1495 for the FESCo meeting on Wednesday, to discuss it. Regards, Jan On Mon, Nov 2, 2015 at 10:10 AM, Reindl Harald wrote: > > > Am 02.11.2015 um 02:28 schrieb Sérgio Basto: > >> On Dom, 2015-11-01 at 17:53 +, Peter Robinson wrote: >> >>> On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto wrote: >>> On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote: > At the third round of Fedora 23 Final Go/No-Go Meeting, that just > ends, has been Fedora 23 Final-RC10 declared as GOLD. > GA of this release is planed on Tuesday 2015-Nov-03. > > Today we got 531 updates for F23 , IMO, you should include it on Fedora 23 Final before GA , doesn't make sense (to me) after download an ISO have 1/2 Giga of updates, but this happens since RedHad 9 at least . IMO, testing team should respin ISO with updates and testing again . I have some difficulty in following all development, fortunately Fedora is always at great speed, but it is not easy to follow. And do more tests we not lose anything, IMHO. >>> >>> The problem is we have to freeze sometime to ensure stability in the >>> installer platform, the live and other images which are static. If not >>> it's too much of a moving target to try and QA and ensure everything >>> works as expected. To freeze is a fairly standard procedure for all >>> distro development. >>> >> >> Make an respin for F23 with stable updates, IMHO, should not break >> anything, because at this stage, just stable things are being pushed >> > > in theory > > it should be just one more loop in testing phase, anyway if breaks >> something test team can freeze process again, until provide a fix. >> > > who does the work for *what* benefit? > it's just wasting ressources and manpower > > who cares about the install ISO when you ave anyways to apply updates > after or in the best case *due* setup > > This is not new !, respins of fedoraunity was an example and we already >> have living respins [1], so we just need do new respin officially!. >> Shouldn't be a big deal, If I'm not mistaken. >> > > and fedoraunity finally gave up because lack of ressources > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
Am 02.11.2015 um 02:28 schrieb Sérgio Basto: On Dom, 2015-11-01 at 17:53 +, Peter Robinson wrote: On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto wrote: On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote: At the third round of Fedora 23 Final Go/No-Go Meeting, that just ends, has been Fedora 23 Final-RC10 declared as GOLD. GA of this release is planed on Tuesday 2015-Nov-03. Today we got 531 updates for F23 , IMO, you should include it on Fedora 23 Final before GA , doesn't make sense (to me) after download an ISO have 1/2 Giga of updates, but this happens since RedHad 9 at least . IMO, testing team should respin ISO with updates and testing again . I have some difficulty in following all development, fortunately Fedora is always at great speed, but it is not easy to follow. And do more tests we not lose anything, IMHO. The problem is we have to freeze sometime to ensure stability in the installer platform, the live and other images which are static. If not it's too much of a moving target to try and QA and ensure everything works as expected. To freeze is a fairly standard procedure for all distro development. Make an respin for F23 with stable updates, IMHO, should not break anything, because at this stage, just stable things are being pushed in theory it should be just one more loop in testing phase, anyway if breaks something test team can freeze process again, until provide a fix. who does the work for *what* benefit? it's just wasting ressources and manpower who cares about the install ISO when you ave anyways to apply updates after or in the best case *due* setup This is not new !, respins of fedoraunity was an example and we already have living respins [1], so we just need do new respin officially!. Shouldn't be a big deal, If I'm not mistaken. and fedoraunity finally gave up because lack of ressources signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On 11/01/2015 09:06 AM, Sérgio Basto wrote: > Today we got 531 updates for F23 , IMO, you should include it on Fedora > 23 Final before GA , doesn't make sense (to me) after download an ISO > have 1/2 Giga of updates, but this happens since RedHad 9 at least . > IMO, testing team should respin ISO with updates and testing again . > I have some difficulty in following all development, fortunately Fedora > is always at great speed, but it is not easy to follow. And do more > tests we not lose anything, IMHO. Ideally, once the release is GA, deltarpms should mitigate most of the download cost. Alternatively, you can use the netinstall ISO image instead (usually about 450 MB or so), and then the newest versions of packages in the repositories will be download on-demand during install time. (You can also achieve this by adding the updates repository during install time on a regular installer image.) While recreating the installer with more updates may seem like a good idea , unfortunately it requires more server resources and more man-hours during which we'd have to freeze with that set of updates. I feel that if we did that, by the time the testing for that respin is complete, that new release will itself have a huge number of pending updates and it could create a cycle of respin-test-respin-test-etc. that would detract our already-limited community resources from advancing toward the next release. Regards. -- Peter Gordon (codergeek42) Who am I? :: http://thecodergeek.com/about-me signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Dom, 2015-11-01 at 17:53 +, Peter Robinson wrote: > On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto wrote: > > On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote: > >> At the third round of Fedora 23 Final Go/No-Go Meeting, that just > >> ends, has been Fedora 23 Final-RC10 declared as GOLD. > >> GA of this release is planed on Tuesday 2015-Nov-03. > >> > > Today we got 531 updates for F23 , IMO, you should include it on Fedora > > 23 Final before GA , doesn't make sense (to me) after download an ISO > > have 1/2 Giga of updates, but this happens since RedHad 9 at least . > > IMO, testing team should respin ISO with updates and testing again . > > I have some difficulty in following all development, fortunately Fedora > > is always at great speed, but it is not easy to follow. And do more > > tests we not lose anything, IMHO. > > The problem is we have to freeze sometime to ensure stability in the > installer platform, the live and other images which are static. If not > it's too much of a moving target to try and QA and ensure everything > works as expected. To freeze is a fairly standard procedure for all > distro development. Make an respin for F23 with stable updates, IMHO, should not break anything, because at this stage, just stable things are being pushed. So it should be just one more loop in testing phase, anyway if breaks something test team can freeze process again, until provide a fix. This is not new !, respins of fedoraunity was an example and we already have living respins [1], so we just need do new respin officially!. Shouldn't be a big deal, If I'm not mistaken. [1] http://alt.fedoraproject.org/pub/alt/live-respins/ > Peter -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
Am 01.11.2015 um 23:20 schrieb Michael Catanzaro: On Sun, 2015-11-01 at 17:53 +, Peter Robinson wrote: The problem is we have to freeze sometime to ensure stability in the installer platform, the live and other images which are static. If not it's too much of a moving target to try and QA and ensure everything works as expected. To freeze is a fairly standard procedure for all distro development. Yeah, but most distros stay frozen... to unfreeze after release -- let alone with 500 updates on day zero! -- is something uniquely Fedora. Really, only my updates should be allowed out to users. All of yours should have to wait for the next release. Obviously not a serious statement, but we all think our own updates are important, whereas collectively it is important to Fedora to reduce the quantity of updates. That implies individual maintainers shouldn't have final say on updates nonsense if individual should not have final say on updates one could use also Debian and *not* Fedora - the is no perfect reason because issues are different refrain from updates may keep annoying bugs currently in Fedora fixed soon and updates *may* introduce new bugs *who* if not the package maintainer which hopefully uses his own packages should have the final say? some group of people not understanding the issues really? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Sun, 2015-11-01 at 17:53 +, Peter Robinson wrote: > The problem is we have to freeze sometime to ensure stability in the > installer platform, the live and other images which are static. If > not > it's too much of a moving target to try and QA and ensure everything > works as expected. To freeze is a fairly standard procedure for all > distro development. Yeah, but most distros stay frozen... to unfreeze after release -- let alone with 500 updates on day zero! -- is something uniquely Fedora. Really, only my updates should be allowed out to users. All of yours should have to wait for the next release. Obviously not a serious statement, but we all think our own updates are important, whereas collectively it is important to Fedora to reduce the quantity of updates. That implies individual maintainers shouldn't have final say on updates Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Sun, 2015-11-01 at 20:03 +0100, Kevin Kofler wrote: > Peter Robinson wrote: > > The problem is we have to freeze sometime to ensure stability in > > the > > installer platform, the live and other images which are static. If > > not > > it's too much of a moving target to try and QA and ensure > > everything > > works as expected. To freeze is a fairly standard procedure for all > > distro development. > > IMHO, we should have at most 1 week of strict freeze. If we decide > that we > have to slip anyway, then we should pull in ALL updates pending > stable and > restart the release process (freeze, spin RCs, test) from there. > > (That would also make it less painful to slip multiple times and thus > decrease the pressure to rush out quick hacks to work around blockers > instead of clean fixes.) I think Kevin is closer to right on this. It's unreasonable to have 500 updates queued for users on release day. Yeah, freeze is required to do QA on the release, but QA on the release is not worth so much if it all goes out the door the first time someone clicks update. (Well, it's essential for the installation process, but beyond that) I will say: Fedora has the *best* release QA *by far* of any comparable community distro -- maybe even better than Debian! -- but we all know our updates break things all the time. In F22, we had at least two (I think actually three, but I lost count) separate updates that broke the ability to apply further (PackageKit) updates. Come on! We have to fix this for OEMs to have any confidence in shipping Fedora. (At least, I'd like to see Fedora in stores, and I think I'm not the only one) My recommendation is the opposite of what Kevin would say, though. I'd like to see a third party responsible for giving final approval on all updates, charged with reducing the size of the updates pipe dramatically. Maintainers should not have final say on updates except in the event of a serious regression (in which case we need a revert button to skip updates-testing). An alternative we've been throwing around in the Workstation group is service packs (or "update packs") -- all non-security updates get bundled together, QAed, and released every 4-8 weeks. If you want to get your update out faster than that, you need a CVE or a special exception. > I also think that the decision: > * when an image is a Go, > * what issues to consider as blockers and > * what new builds to take as freeze overrides > ought to be made by the WG/SIG responsible for the individual > deliverable. > (And this is NOT a personal power grab attempt. I am no longer a > voting > member of the KDE SIG, for reasons detailed on the kde mailing list.) > The > current process where the SIG/WG has to argue for every single freeze > override they want to take in, and have rel-eng/QA reject some of > them, is > just broken (and there I can speak from experience, with my 8 years > of KDE > SIG involvement). Then we need to have separate release cycles for each product, since I don't want Workstation blocked indefinitely on everything Cloud/Server/KDE want to fix, and presumably those groups don't want to block on us... it's frankly annoying to me that we risk blocking Workstation on such issues, but it's a compromise we need to make to ensure the other releases are good. (And that vice-versa when the other releases get blocked on Workstation issues.) As long as we have four separate releases on the same cycle, it makes sense that QA gets final say. Besides, they're the ones testing the thing. Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
Peter Robinson wrote: > The problem is we have to freeze sometime to ensure stability in the > installer platform, the live and other images which are static. If not > it's too much of a moving target to try and QA and ensure everything > works as expected. To freeze is a fairly standard procedure for all > distro development. IMHO, we should have at most 1 week of strict freeze. If we decide that we have to slip anyway, then we should pull in ALL updates pending stable and restart the release process (freeze, spin RCs, test) from there. (That would also make it less painful to slip multiple times and thus decrease the pressure to rush out quick hacks to work around blockers instead of clean fixes.) I also think that the decision: * when an image is a Go, * what issues to consider as blockers and * what new builds to take as freeze overrides ought to be made by the WG/SIG responsible for the individual deliverable. (And this is NOT a personal power grab attempt. I am no longer a voting member of the KDE SIG, for reasons detailed on the kde mailing list.) The current process where the SIG/WG has to argue for every single freeze override they want to take in, and have rel-eng/QA reject some of them, is just broken (and there I can speak from experience, with my 8 years of KDE SIG involvement). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto wrote: > On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote: >> At the third round of Fedora 23 Final Go/No-Go Meeting, that just >> ends, has been Fedora 23 Final-RC10 declared as GOLD. >> GA of this release is planed on Tuesday 2015-Nov-03. >> > Today we got 531 updates for F23 , IMO, you should include it on Fedora > 23 Final before GA , doesn't make sense (to me) after download an ISO > have 1/2 Giga of updates, but this happens since RedHad 9 at least . > IMO, testing team should respin ISO with updates and testing again . > I have some difficulty in following all development, fortunately Fedora > is always at great speed, but it is not easy to follow. And do more > tests we not lose anything, IMHO. The problem is we have to freeze sometime to ensure stability in the installer platform, the live and other images which are static. If not it's too much of a moving target to try and QA and ensure everything works as expected. To freeze is a fairly standard procedure for all distro development. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On 01/11/15 12:06 PM, Sérgio Basto wrote: > On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote: >> At the third round of Fedora 23 Final Go/No-Go Meeting, that just >> ends, has been Fedora 23 Final-RC10 declared as GOLD. >> GA of this release is planed on Tuesday 2015-Nov-03. >> > Today we got 531 updates for F23 , IMO, you should include it on Fedora > 23 Final before GA , doesn't make sense (to me) after download an ISO > have 1/2 Giga of updates, but this happens since RedHad 9 at least . > IMO, testing team should respin ISO with updates and testing again . > I have some difficulty in following all development, fortunately Fedora > is always at great speed, but it is not easy to follow. And do more > tests we not lose anything, IMHO. > > > Thanks, How does that compare to the normal volume of incoming updates? What I mean is, if they re-rolled and re-tested, would a roughly similar number of updates be waiting again? -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 Final RC10 status is GO !
On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote: > At the third round of Fedora 23 Final Go/No-Go Meeting, that just > ends, has been Fedora 23 Final-RC10 declared as GOLD. > GA of this release is planed on Tuesday 2015-Nov-03. > Today we got 531 updates for F23 , IMO, you should include it on Fedora 23 Final before GA , doesn't make sense (to me) after download an ISO have 1/2 Giga of updates, but this happens since RedHad 9 at least . IMO, testing team should respin ISO with updates and testing again . I have some difficulty in following all development, fortunately Fedora is always at great speed, but it is not easy to follow. And do more tests we not lose anything, IMHO. Thanks, > Meeting details can be seen here: > Minutes: > http://meetbot.fedoraproject.org/fedora-meeting-2/2015-10-30/f23-final-go_no_go-meeting_3.2015-10-30-16.00.html > Log: > http://meetbot.fedoraproject.org/fedora-meeting-2/2015-10-30/f23-final-go_no_go-meeting_3.2015-10-30-16.00.log.html > > Thanks everyone who participated on this release! > > > Regards, > > Jan > > -- > Jan Kuřík > Platform & Fedora Program Manager > Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic > ___ > devel-announce mailing list > devel-annou...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
