Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 16. 8. 2013 at 15:20:57, Bill Nottingham wrote: Matthias Clasen (mcla...@redhat.com) said: On Fri, 2013-08-16 at 08:42 +0200, Jan Zelený wrote: Actually no, the system is all hacked up and works in a super-abusive way, see https://bugzilla.redhat.com/show_bug.cgi?id=979083 That bug is really an illustration why it is just wrong to keep information about the update history in a semi-private 'db' that only yum gets to access. This information belongs into the journal. We have the change to fix that in the dnf transition. As long as the journal is rotated out at arbitrary times due to space reasons, I really really don't think the information belongs there. Agreed. This information doesn't belong to journal and we have no intentions to put it there. It should still be in a public db for other things to use, though. We already have a plan to extract the db-handling code from dnf to an external library. That should make the situation more developer friendly. Thanks Jan -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Sat, Aug 17, 2013 at 1:41 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 08/15/2013 03:55 PM, Stephen John Smoogen wrote: Some form of middle ground of this is what we have currently implemented in QA and test for but even there we cannot guarantee anything, like if we take the default desktop installation how well can Gnome itself handle upgrades between releases ( think for example *conf schema changes here ) guarantee is a worse word then supported we cannot guarantee that Fedora boots on your system at all. People seem to pay to much attention to the word supported .. it basically means that is what should work, if we find out that it doesn't we fix it before the release or even slip until it gets fixed. It does not mean that works in all cases and is bug free. Not supporting upgrades and putting no effort into it would render Fedora pretty much the most useless distro ever. Re installing every 6 months is simply to inconvenient for many users. -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 16 August 2013 19:41, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 08/15/2013 03:55 PM, Stephen John Smoogen wrote: What's alarming with the decision to officially support upgrades that it was done without consulting the QA community, which are the ones that have to come up with the test cases,make the necessary changes to the release criteria, essentially have to do all the work and above all test it. I am going to have to reverse the question. While I was helping out when I could from Red Hat 7 - Fedora 7, QA always tested upgrades. The basic tests were: 1) Install last release, test an upgrade from that to latest. Report what broke. 2) Install release-2, test an upgrade from that to latest. Report what broke. 3) Install last release, rpm -Uvh (before yum and yum update afterwords), test an upgrade to latest. See what broke. 4) Install release-2 If the install was important for some reason (in the RHL days that would have been something like RHL-5.2, RHL-6.2, RHL-7.3 and before core went away Fedora Core 6). you would do a chain upgrade (RHL-2.1 - whatever now is.) and document what was broken. So sometime after Fedora 7. Support of upgrades was basically that we knew it worked if you did this and it might work if you did that, and it probably won't work outside of that. So my guess is that sometime after F7 (maybe when upgrade was no longer a path in Anaconda?) it was considered not supported anymore? -- Stephen J Smoogen. -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Sat, Aug 17, 2013 at 11:12 PM, Stephen John Smoogen smo...@gmail.com wrote: So my guess is that sometime after F7 (maybe when upgrade was no longer a path in Anaconda?) it was considered not supported anymore? No and anaconda lost support in F18 (and fedup took its place). -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 15. 8. 2013 at 09:37:57, Kevin Fenzi wrote: On Thu, 15 Aug 2013 17:32:27 +0200 Reindl Harald h.rei...@thelounge.net wrote: what does *not* matter in case of yum distro-sync because it does also downgrades and if fedup has a problem with it the people who say yum is not officially supported (while no support in any case exists) should ask theirself who in the world needs fedup instead keep fous on *one* well working tool besides the fact that yum-upgrades are most times better yum is used and tested every single day from thousands of users while fedup no normal user touchs half a year You misunderstand how fedup works. It gathers up the packages you will need to do the upgrade, then reboots into a very minimal env and uses yum to do the upgrade. Actually no, the system is all hacked up and works in a super-abusive way, see https://bugzilla.redhat.com/show_bug.cgi?id=979083 -- snip -- However, fedup is more safe since it's not happening on a running system. Based on the number of bugzillas that come to our team about broken system after fedup upgrade, I'm not so sure. Thanks Jan -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/16/2013 09:42 AM, Jan Zelený wrote: On 15. 8. 2013 at 09:37:57, Kevin Fenzi wrote: On Thu, 15 Aug 2013 17:32:27 +0200 Reindl Harald h.rei...@thelounge.net wrote: what does *not* matter in case of yum distro-sync because it does also downgrades and if fedup has a problem with it the people who say yum is not officially supported (while no support in any case exists) should ask theirself who in the world needs fedup instead keep fous on *one* well working tool besides the fact that yum-upgrades are most times better yum is used and tested every single day from thousands of users while fedup no normal user touchs half a year You misunderstand how fedup works. It gathers up the packages you will need to do the upgrade, then reboots into a very minimal env and uses yum to do the upgrade. Actually no, the system is all hacked up and works in a super-abusive way, see https://bugzilla.redhat.com/show_bug.cgi?id=979083 Calling it super-abusive is a bit much. What it does is simply the equivalent of using rpm to install/upgrade/erase packages instead of yum. - Panu - -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, Aug 15, 2013 at 03:43:27PM -0400, Jóhann B. Guðmundsson wrote: On 08/15/2013 03:16 PM, drago01 wrote: Suddenly? They always have been supported that even dates back to the Redhat Linux days ... I should clarify what I'm talking about is the discussion of officially supporting upgrading while you probably mean it has been technically possible which has indeed been available for a long time. It's supported in that it's expected to work, and if it doesn't work it's a valid bug and should be fixed or relnoted. That's been the intention forever, and like I said, if QA aren't testing that then QA should be testing that. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 2013-08-15 at 16:12 -0400, Jóhann B. Guðmundsson wrote: On 08/15/2013 03:47 PM, Kevin Fenzi wrote: On Thu, 15 Aug 2013 15:36:53 -0400 Jóhann B. Guðmundsson johan...@gmail.com wrote: Interesting since they did not do that when I joined QA what 5 or 6 years ago so again can you refer me to that discussion. It's always been a test case/critera that I remember... http://fedoraproject.org/wiki/QA/Meetings/20070117#Fedora_7 Shows upgrade test cases were there in Fedora 7 and one of the things QA was testing and ensuring. We tested for it to a limited extent ( via yum ) but we never officially supported it. We always stayed away from opening that pandora box and it was not until we found out that someone had stamped upgrades to be officially supported that we actually properly defined what should be tested, added the criteria for it and made it release blocking. And the discussion around who officially stamped it and why is what I'm looking for ( not that it has been technically possible for number of years ) and I'm pretty sure it was neither Jeremy,Will,Chris or Seth that pushed for that official upgrade stamp when they introduced pre-upgrade once they had finish writing it, since all four knew the ramification for us in QA by doing so. I can tell you that fedup blindly inherited the offically upgrade tool/support from pre-upgrade by fesco decision, while Will was still scratching his head designing/writing it and Tim being the only one that was properly testing what Will threw over the wall. To many including me that seemed like an odd decision making instead for example simply not officially support upgrades ( thus not making it release blocking ) until that tool had been written. Just to make something clear, since at least one person was confused by what Johann was saying: I've not been around long enough to comment on the history here, but as things stand, there is a requirement for a clean stock upgrade case using the 'recommended' upgrade mechanism(s) to work in the release criteria, and QA does test this as part of release validation. Johann is discussing the history that led to this being the case and questioning how exactly we ever came to support upgrades in this way in the first place, which I don't have any idea about, it's before my time. Just wanted to make clear that as things stand right now, upgrading via fedup is supported in that it's required by the validation process to work to the extent described above. I personally like to try and use the word recommended, as in, if you're going to do an upgrade, fedup is the recommended way to do it. The term supported is a bit problematic for Fedora in general as it's not like we have a phone line and we don't give out refunds if it breaks. It's also problematic in the specific case of upgrades, because there are seventy squillion potential upgrade scenarios and no way we can possibly test them all. Even with the testing we do, it's almost inevitable that *some* upgrade attempts will turn out badly. -- 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Fri, 2013-08-16 at 08:42 +0200, Jan Zelený wrote: Actually no, the system is all hacked up and works in a super-abusive way, see https://bugzilla.redhat.com/show_bug.cgi?id=979083 That bug is really an illustration why it is just wrong to keep information about the update history in a semi-private 'db' that only yum gets to access. This information belongs into the journal. We have the change to fix that in the dnf transition. -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Matthias Clasen (mcla...@redhat.com) said: On Fri, 2013-08-16 at 08:42 +0200, Jan Zelený wrote: Actually no, the system is all hacked up and works in a super-abusive way, see https://bugzilla.redhat.com/show_bug.cgi?id=979083 That bug is really an illustration why it is just wrong to keep information about the update history in a semi-private 'db' that only yum gets to access. This information belongs into the journal. We have the change to fix that in the dnf transition. As long as the journal is rotated out at arbitrary times due to space reasons, I really really don't think the information belongs there. It should still be in a public db for other things to use, though. Bill -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 03:55 PM, Stephen John Smoogen wrote: On 15 August 2013 15:48, Matthew Garrett mj...@srcf.ucam.org mailto:mj...@srcf.ucam.org wrote: Oh, and to clarify - upgrades were supported even before then, but required booting Anaconda from new install media. That's been true since the Red Hat Linux days, so years before Fedora even existed. I believe we are arguing over words which have different meanings depending on what each person is talking about. Agreed Does supported mean: a) We guarantee that upgrade works always and without problems? This is what end users think of when they read Officially supported with even higher demand if they are existing RHEL customers... b) We guarantee that upgrade code works but may encounter problems if you have done stuff other than a default install/stuff. Some form of middle ground of this is what we have currently implemented in QA and test for but even there we cannot guarantee anything, like if we take the default desktop installation how well can Gnome itself handle upgrades between releases ( think for example *conf schema changes here ) Now with rings and servers I'm afraid we ( as in QA ) have to start officially support which ever application are in it which often bring incompatible changes with them. c) We guarantee that the upgrade code is there, and it should work but you should know what you are doing This is what the QA attitude used to be, before official upgrade support. d) There is some code, we worked on it, you can activate it, but that is all we can say. Each of those has been said of upgrade by various developers over the years (Jeremy Katz would try to get it down to D but Gafton would want it to be b) and every new person on anaconda would say they wanted to get to a someday.) What's alarming with the decision to officially support upgrades that it was done without consulting the QA community, which are the ones that have to come up with the test cases,make the necessary changes to the release criteria, essentially have to do all the work and above all test it. With the upcoming changes we have to ensure all the supporting sig within the project ( qa,releng,infra etc... ) are being properly communicated,informed and consulted with, in regards to any decision which directly affects them and the community surrounding them. In the end of the day they ( as in all the supporting sig ) are the ones that will have to do all the work as well as allocate resources necessary to do it. JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 15 Aug 2013, Matthew Garrett wrote: I want increased participation in the creation of Fedora, which is a product with a defined set of software shipped as default. I'm also happy with people working to make it practical to use Fedora as the basis for derived products (such as the spins and remixes), providing that they don't compromise the product that we're producing. I feel that people mostly say fedora is for testing. It is somewhat supported by responses to upgrade problems to a new version which invariable are along the lines of we don't support that upgrade path/method. We can't tell people to re-install from scratch every 6 months. What we need is an apt-get dist-upgrade equivalent. Paul -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 2013-08-15 at 09:40 -0400, Paul Wouters wrote: We can't tell people to re-install from scratch every 6 months. What we need is an apt-get dist-upgrade equivalent. +1 -- Best Regards, Artem Bityutskiy -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/15/2013 09:40 AM, Paul Wouters wrote: On Thu, 15 Aug 2013, Matthew Garrett wrote: I want increased participation in the creation of Fedora, which is a product with a defined set of software shipped as default. I'm also happy with people working to make it practical to use Fedora as the basis for derived products (such as the spins and remixes), providing that they don't compromise the product that we're producing. I feel that people mostly say fedora is for testing. It is somewhat supported by responses to upgrade problems to a new version which invariable are along the lines of we don't support that upgrade path/method. We can't tell people to re-install from scratch every 6 months. What we need is an apt-get dist-upgrade equivalent. I think your information is out of date. For the last two releases, we've had the excellent 'fedup' tool that performs a supported distribution upgrade, similar (but better than) 'apt-get dist-upgrade'. I strongly suggest taking a look. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIM4zMACgkQeiVVYja6o6PqgQCgqiOXDD2FjM9OxLtiB7dwPR7Y MXIAnjGGBNUOV1HPNbtmHcaMJ6hQpq1X =rZHt -END PGP 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 03:40 PM, Paul Wouters wrote: On Thu, 15 Aug 2013, Matthew Garrett wrote: I want increased participation in the creation of Fedora, which is a product with a defined set of software shipped as default. I'm also happy with people working to make it practical to use Fedora as the basis for derived products (such as the spins and remixes), providing that they don't compromise the product that we're producing. I feel that people mostly say fedora is for testing. It is somewhat supported by responses to upgrade problems to a new version which invariable are along the lines of we don't support that upgrade path/method. We can't tell people to re-install from scratch every 6 months. What we need is an apt-get dist-upgrade equivalent. Paul I agree our updates should be supported option ;-) They are usually working very well. Marcela -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, Aug 15, 2013 at 09:40:01AM -0400, Paul Wouters wrote: On Thu, 15 Aug 2013, Matthew Garrett wrote: I want increased participation in the creation of Fedora, which is a product with a defined set of software shipped as default. I'm also happy with people working to make it practical to use Fedora as the basis for derived products (such as the spins and remixes), providing that they don't compromise the product that we're producing. I feel that people mostly say fedora is for testing. It is somewhat supported by responses to upgrade problems to a new version which invariable are along the lines of we don't support that upgrade path/method. What's wrong with fedup? -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 15 Aug 2013, Reindl Harald wrote: Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an apt-get dist-upgrade equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known I had tried preupgrade/fedup in the past, but it tried to stuff too many files in /boot because my root partition was encrypted, so this method was never usable for me. The wiki mentions that files now go into /var/lib/fedora-upgrade (which btw should really be /var/cache/fedora-upgrade) which is only available after asking for my disk encryption password. I'll try it for f18-f19, and if this got fixed that is a big step towards running fedora longterm across releases. Paul -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Hi On Thu, Aug 15, 2013 at 10:36 AM, Paul Wouters I'll try it for f18-f19, and if this got fixed that is a big step towards running fedora longterm across releases. Fedup is not the same thing as preupgrade and it appears you are complaining about issues in preupgrade and haven't tried fedup yet. Preupgrade doesn't exist anymore and Fedup is still the recommended option and all it does is run a yum upgrade is a more constrained environment. If you run into any problems, these are just bugs which needs to get filed and fixed. Rahul -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 04:36 PM, Paul Wouters wrote: On Thu, 15 Aug 2013, Reindl Harald wrote: Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an apt-get dist-upgrade equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known I had tried preupgrade/fedup in the past, but it tried to stuff too many files in /boot because my root partition was encrypted, so this method was never usable for me. The wiki mentions that files now go into /var/lib/fedora-upgrade (which btw should really be /var/cache/fedora-upgrade) which is only available after asking for my disk encryption password. I'll try it for f18-f19, and if this got fixed that is a big step towards running fedora longterm across releases. AFAIK, during an upgrade, fedup stores all required rpms below /var/cache/yum. This means, if you don't have a sufficiently large /var partition, you are likely to hit similar issues as with preupgrade. Though this is less likely to hit users than storing packages under /boot, it's still possible to happen (it did happen to me). Another issue I encountered with all 3 upgrade methods, was them not being able to compute required disk space sizes correctly, occasionally causing rpmdb corruptions (I did encounter this issue). And yet another issue is the fedora-distribution occasionally carrying packages with greater NEVRs in older releases than in newer release. A pretty nasty such case had been F18 been equipped with a newer kernel than F19 for a larger time frame. Ralf -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an apt-get dist-upgrade equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known they are *not* more predictable as yum, the opposite is true and two months after the new release while your setup got updates as well as the new release *nobody* knows more how predictable fedup would be than yum 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Am 15.08.2013 17:17, schrieb Ralf Corsepius: On 08/15/2013 04:36 PM, Paul Wouters wrote: On Thu, 15 Aug 2013, Reindl Harald wrote: Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an apt-get dist-upgrade equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known And yet another issue is the fedora-distribution occasionally carrying packages with greater NEVRs in older releases than in newer release. what does *not* matter in case of yum distro-sync because it does also downgrades and if fedup has a problem with it the people who say yum is not officially supported (while no support in any case exists) should ask theirself who in the world needs fedup instead keep fous on *one* well working tool besides the fact that yum-upgrades are most times better yum is used and tested every single day from thousands of users while fedup no normal user touchs half a year 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 15 Aug 2013 17:32:27 +0200 Reindl Harald h.rei...@thelounge.net wrote: what does *not* matter in case of yum distro-sync because it does also downgrades and if fedup has a problem with it the people who say yum is not officially supported (while no support in any case exists) should ask theirself who in the world needs fedup instead keep fous on *one* well working tool besides the fact that yum-upgrades are most times better yum is used and tested every single day from thousands of users while fedup no normal user touchs half a year You misunderstand how fedup works. It gathers up the packages you will need to do the upgrade, then reboots into a very minimal env and uses yum to do the upgrade. The difference is that since it's in a minimal env, you don't have possible problems with running processes, and you can make changes that would otherwise not be possible to a running system. If you use and like yum dist upgrades on running systems, thats great. However, fedup is more safe since it's not happening on a running system. kevin signature.asc Description: PGP 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 05:37 PM, Kevin Fenzi wrote: On Thu, 15 Aug 2013 17:32:27 +0200 Reindl Harald h.rei...@thelounge.net wrote: what does *not* matter in case of yum distro-sync because it does also downgrades and if fedup has a problem with it the people who say yum is not officially supported (while no support in any case exists) should ask theirself who in the world needs fedup instead keep fous on *one* well working tool besides the fact that yum-upgrades are most times better yum is used and tested every single day from thousands of users while fedup no normal user touchs half a year You misunderstand how fedup works. It gathers up the packages you will need to do the upgrade, ... and stores them in /var/cache/yum/... If you don't have a sufficiently large /var/cache, such a download easily exceeds the amount of available diskspace and fails. then reboots into a very minimal env and uses yum to do the upgrade. The difference is that since it's in a minimal env, you don't have possible problems with running processes, and you can make changes that would otherwise not be possible to a running system. Well, may-be I am wrong, but this does not match with what I experienced during the ca. 8 fedup driven updates, I've done. If you use and like yum dist upgrades on running systems, thats great. However, fedup is more safe since it's not happening on a running system. If you say so ... I saw f17-f18 hang during the fedup reboot and not come up at all, and had 2 f18-f19 systems suffering from corrupt rpmdbs. All f18-f19 systems had f18 kernels after fedup had completed, due to the kernel-versions. Ralf -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 05:32 PM, Reindl Harald wrote: Am 15.08.2013 17:17, schrieb Ralf Corsepius: On 08/15/2013 04:36 PM, Paul Wouters wrote: On Thu, 15 Aug 2013, Reindl Harald wrote: Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an apt-get dist-upgrade equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known And yet another issue is the fedora-distribution occasionally carrying packages with greater NEVRs in older releases than in newer release. what does *not* matter in case of yum distro-sync It does matter, esp in case of the kernel, because the kernel is treated differently from most other packages in yum. Another case it matters is case when package versions are identical. In these cases, even though the NEVRS may be identical, the contents can be different (different paths, different deps etc.) Ralf -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 15 Aug 2013 17:59:30 +0200 Ralf Corsepius rc040...@freenet.de wrote: On 08/15/2013 05:37 PM, Kevin Fenzi wrote: ...snip... It gathers up the packages you will need to do the upgrade, ... and stores them in /var/cache/yum/... If you don't have a sufficiently large /var/cache, such a download easily exceeds the amount of available diskspace and fails. Sure, but how would a live yum dist upgrade work there? It also has to download the rpms and store them before starting the transaction. ..snip... If you say so ... I saw f17-f18 hang during the fedup reboot and not come up at all, and had 2 f18-f19 systems suffering from corrupt rpmdbs. You filed bugs on these I hope? :) All f18-f19 systems had f18 kernels after fedup had completed, due to the kernel-versions. Yeah, not sure what happened there. kevin signature.asc Description: PGP 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 11:32 AM, Reindl Harald wrote: Am 15.08.2013 17:17, schrieb Ralf Corsepius: On 08/15/2013 04:36 PM, Paul Wouters wrote: On Thu, 15 Aug 2013, Reindl Harald wrote: Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an apt-get dist-upgrade equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known And yet another issue is the fedora-distribution occasionally carrying packages with greater NEVRs in older releases than in newer release. what does *not* matter in case of yum distro-sync because it does also It seemed to matter yesterday when I tried to update a Fedora 19 vm to rawhide. Try it and see. -- Kaleb -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Am 15.08.2013 18:02, schrieb Ralf Corsepius: On 08/15/2013 05:32 PM, Reindl Harald wrote: Am 15.08.2013 17:17, schrieb Ralf Corsepius: On 08/15/2013 04:36 PM, Paul Wouters wrote: On Thu, 15 Aug 2013, Reindl Harald wrote: Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an apt-get dist-upgrade equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known And yet another issue is the fedora-distribution occasionally carrying packages with greater NEVRs in older releases than in newer release. what does *not* matter in case of yum distro-sync It does matter, esp in case of the kernel, because the kernel is treated differently from most other packages in yum. the only case and exactly here is yum the *better* variant you can verify kernel/grub-config *before* reboot and it is no problem to fix this before the shiny tools for upgrade including anaconda in F13 days did leave me machines more than once in a unbootable state which not happened in any of the 450 yum-dist-upgrades i made so far from FC6 to F19 Another case it matters is case when package versions are identical. In these cases, even though the NEVRS may be identical, the contents can be different (different paths, different deps etc.) nonsense yum-3.4.3-54.fc18.noarch yum-3.4.3-54.fc17.noarch 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Am 15.08.2013 18:19, schrieb Kaleb KEITHLEY: On 08/15/2013 11:32 AM, Reindl Harald wrote: Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an apt-get dist-upgrade equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known And yet another issue is the fedora-distribution occasionally carrying packages with greater NEVRs in older releases than in newer release. what does *not* matter in case of yum distro-sync because it does also It seemed to matter yesterday when I tried to update a Fedora 19 vm to rawhide what exactly was the unsolveable problem you could not fix before reboot? and according to the message below how do someone imagine fedup could solve the specific problem without manual intervention? Original-Nachricht Betreff: Re: Schedule for Wednesday's FESCo Meeting (2013-08-14) Datum: Thu, 15 Aug 2013 09:37:57 -0600 Von: Kevin Fenzi ke...@scrye.com besides the fact that yum-upgrades are most times better yum is used and tested every single day from thousands of users while fedup no normal user touchs half a year You misunderstand how fedup works. It gathers up the packages you will need to do the upgrade, then reboots into a very minimal env and uses yum to do the upgrade 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 10:16 AM, Marcela Mašláňová wrote: I agree our updates should be supported option ;-) They are usually working very well. We really should try to stop using the word supported since it misleading for everybody. Best effort is what accurately describes what the community does so surely there is a word in the English vocabulary that is a better match to that then support and we can try to use... JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 10:26 AM, Jóhann B. Guðmundsson wrote: On 08/15/2013 10:16 AM, Marcela Mašláňová wrote: I agree our updates should be supported option ;-) They are usually working very well. We really should try to stop using the word supported since it misleading for everybody. Best effort is what accurately describes what the community does so surely there is a word in the English vocabulary that is a better match to that then support and we can try to use... tested? -- Nathanael d. Noblet t 403.875.4613 -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 09:40 AM, Paul Wouters wrote: I feel that people mostly say fedora is for testing. It is somewhat supported by responses to upgrade problems to a new version which invariable are along the lines of we don't support that upgrade path/method. Well whomever choose to decide that we support upgrades in the first place bypassed the QA community entirely in making that decision as well as to which tool is preferred,supported or recommended. The fact is we have always had more testing with yum upgrade vs preupgrade/fedup since that is always been the preferred choice of our QA community members and what we recommend ourselves to use [1]. The bottom line is that we cannot support upgrades et all since we cant test cover all the upgrade path of mixed match combination of our ca 12.000 components. ( and that's excluding any testing with 3rd party repo's involved ) . We don't even provide a fallback method encase something goes awry but hopefully that will change for all the spins that decide to default to btrfs if/when that time comes and we should be able to implement something that boots into the volume before upgrade. From my personal opinion we should not be supporting upgrade et all since in all reality we cant do that and we end up sending misleading signals to Fedora consumers when doing that. JBG 1. https://fedoraproject.org/wiki/Releases/Rawhide?rd=Rawhide#Yum_from_Existing_install -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, Aug 15, 2013 at 01:02:42PM -0400, Jóhann B. Guðmundsson wrote: Well whomever choose to decide that we support upgrades in the first place bypassed the QA community entirely in making that decision as well as to which tool is preferred,supported or recommended. If QA is testing something other than the supported upgrade mechanism, then QA should rectify that. The communication has been very clear - if fedup fails to upgrade then that's considered a bug, and if any other approach fails then it may not be. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 02:26 PM, Matthew Garrett wrote: On Thu, Aug 15, 2013 at 01:02:42PM -0400, Jóhann B. Guðmundsson wrote: Well whomever choose to decide that we support upgrades in the first place bypassed the QA community entirely in making that decision as well as to which tool is preferred,supported or recommended. If QA is testing something other than the supported upgrade mechanism, then QA should rectify that. The communication has been very clear - if fedup fails to upgrade then that's considered a bug, and if any other approach fails then it may not be. Our release criteria and everything we defined *after* we found out that we suddenly supported upgrades is solid which is not what I was saying or referring to. Could you point me to the individual(s) and the discussion to support upgrades in the first place, took place so we in the QA community can finally see who made the decision to open that pandora box and why? It might even reveal why the QA community was excluded from that discussion in the first place... JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, Aug 15, 2013 at 9:02 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 08/15/2013 02:26 PM, Matthew Garrett wrote: On Thu, Aug 15, 2013 at 01:02:42PM -0400, Jóhann B. Guðmundsson wrote: Well whomever choose to decide that we support upgrades in the first place bypassed the QA community entirely in making that decision as well as to which tool is preferred,supported or recommended. If QA is testing something other than the supported upgrade mechanism, then QA should rectify that. The communication has been very clear - if fedup fails to upgrade then that's considered a bug, and if any other approach fails then it may not be. Our release criteria and everything we defined *after* we found out that we suddenly supported upgrades is solid which is not what I was saying or referring to. Suddenly? They always have been supported that even dates back to the Redhat Linux days ... Could you point me to the individual(s) and the discussion to support upgrades in the first place, took place so we in the QA community can finally see who made the decision to open that pandora box and why? See above. -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 12:32 PM, Josh Boyer jwbo...@gmail.com wrote: On Wed, Aug 14, 2013 at 12:04 PM, Kevin Fenzi ke...@scrye.com wrote: On Tue, 13 Aug 2013 22:41:37 -0700 Toshio Kuratomi a.bad...@gmail.com wrote: Additional agenda item: Mattdm, sgallagh, and I were talking about the general fesco sentiment towards mattdm's fedora future direction proposal and the multiple fedora products idea at post-flock breakfast. My understanding is that the sentiment was that it would be a board decision whether to go that route, that fesco would be on charge of implementing it, and that fesco was generally in favour of it. The three of us thought it would be a good idea for fesco to officially vote on whether we can get behind the idea and then send it to the board so that we can start putting some proposals together. (Sorry for top-posting... on my phone.) Well, or would it be better to have a concrete proposal to take to them? I don't see any harm I guess in fesco deciding that we are in favor in general of this plan and ask the Board if we are going down a path they don't want us to before writing up concrete proposals. Right. Less worrying about what the Board thinks, more worrying about what FESCo thinks. If those two entities wind up not agreeing, then we can discuss that. As for the Board, I'm hoping to bring up the future direction stuff as a topic we should at least be paying close attention to in the next meeting. Having something from FESCo to review would be great too. The Board discussed this today. We agree with the development of a working group to describe an implementation proposal for the future of Fedora, and encourage the involvement of existing desktop, cloud and server contributors in the process. We look forward to reviewing the proposal. Thanks. josh -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 03:16 PM, drago01 wrote: On Thu, Aug 15, 2013 at 9:02 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 08/15/2013 02:26 PM, Matthew Garrett wrote: On Thu, Aug 15, 2013 at 01:02:42PM -0400, Jóhann B. Guðmundsson wrote: Well whomever choose to decide that we support upgrades in the first place bypassed the QA community entirely in making that decision as well as to which tool is preferred,supported or recommended. If QA is testing something other than the supported upgrade mechanism, then QA should rectify that. The communication has been very clear - if fedup fails to upgrade then that's considered a bug, and if any other approach fails then it may not be. Our release criteria and everything we defined *after* we found out that we suddenly supported upgrades is solid which is not what I was saying or referring to. Suddenly? They always have been supported that even dates back to the Redhat Linux days ... Interesting since they did not do that when I joined QA what 5 or 6 years ago so again can you refer me to that discussion. JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 03:16 PM, drago01 wrote: On Thu, Aug 15, 2013 at 9:02 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 08/15/2013 02:26 PM, Matthew Garrett wrote: On Thu, Aug 15, 2013 at 01:02:42PM -0400, Jóhann B. Guðmundsson wrote: Well whomever choose to decide that we support upgrades in the first place bypassed the QA community entirely in making that decision as well as to which tool is preferred,supported or recommended. If QA is testing something other than the supported upgrade mechanism, then QA should rectify that. The communication has been very clear - if fedup fails to upgrade then that's considered a bug, and if any other approach fails then it may not be. Our release criteria and everything we defined *after* we found out that we suddenly supported upgrades is solid which is not what I was saying or referring to. Suddenly? They always have been supported that even dates back to the Redhat Linux days ... I should clarify what I'm talking about is the discussion of officially supporting upgrading while you probably mean it has been technically possible which has indeed been available for a long time. JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, Aug 15, 2013 at 03:02:37PM -0400, Jóhann B. Guðmundsson wrote: Our release criteria and everything we defined *after* we found out that we suddenly supported upgrades is solid which is not what I was saying or referring to. We've always supported upgrades. Before fedup, preupgrade was the supported upgrade mechanism. That's been true as long as I've been involved in Red Hat. Could you point me to the individual(s) and the discussion to support upgrades in the first place, took place so we in the QA community can finally see who made the decision to open that pandora box and why? Preupgrade was accepted into Fedora 8, so you'd probably need to go back and review the feature discussion from then. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 15 Aug 2013 15:36:53 -0400 Jóhann B. Guðmundsson johan...@gmail.com wrote: Interesting since they did not do that when I joined QA what 5 or 6 years ago so again can you refer me to that discussion. It's always been a test case/critera that I remember... http://fedoraproject.org/wiki/QA/Meetings/20070117#Fedora_7 Shows upgrade test cases were there in Fedora 7 and one of the things QA was testing and ensuring. kevin signature.asc Description: PGP 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Oh, and to clarify - upgrades were supported even before then, but required booting Anaconda from new install media. That's been true since the Red Hat Linux days, so years before Fedora even existed. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 15 August 2013 15:48, Matthew Garrett mj...@srcf.ucam.org wrote: Oh, and to clarify - upgrades were supported even before then, but required booting Anaconda from new install media. That's been true since the Red Hat Linux days, so years before Fedora even existed. I believe we are arguing over words which have different meanings depending on what each person is talking about. Does supported mean: a) We guarantee that upgrade works always and without problems? b) We guarantee that upgrade code works but may encounter problems if you have done stuff other than a default install/stuff. c) We guarantee that the upgrade code is there, and it should work but you should know what you are doing d) There is some code, we worked on it, you can activate it, but that is all we can say. Each of those has been said of upgrade by various developers over the years (Jeremy Katz would try to get it down to D but Gafton would want it to be b) and every new person on anaconda would say they wanted to get to a someday.) -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 03:47 PM, Kevin Fenzi wrote: On Thu, 15 Aug 2013 15:36:53 -0400 Jóhann B. Guðmundsson johan...@gmail.com wrote: Interesting since they did not do that when I joined QA what 5 or 6 years ago so again can you refer me to that discussion. It's always been a test case/critera that I remember... http://fedoraproject.org/wiki/QA/Meetings/20070117#Fedora_7 Shows upgrade test cases were there in Fedora 7 and one of the things QA was testing and ensuring. We tested for it to a limited extent ( via yum ) but we never officially supported it. We always stayed away from opening that pandora box and it was not until we found out that someone had stamped upgrades to be officially supported that we actually properly defined what should be tested, added the criteria for it and made it release blocking. And the discussion around who officially stamped it and why is what I'm looking for ( not that it has been technically possible for number of years ) and I'm pretty sure it was neither Jeremy,Will,Chris or Seth that pushed for that official upgrade stamp when they introduced pre-upgrade once they had finish writing it, since all four knew the ramification for us in QA by doing so. I can tell you that fedup blindly inherited the offically upgrade tool/support from pre-upgrade by fesco decision, while Will was still scratching his head designing/writing it and Tim being the only one that was properly testing what Will threw over the wall. To many including me that seemed like an odd decision making instead for example simply not officially support upgrades ( thus not making it release blocking ) until that tool had been written. JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Am 15.08.2013 22:12, schrieb Jóhann B. Guðmundsson: On 08/15/2013 03:47 PM, Kevin Fenzi wrote: On Thu, 15 Aug 2013 15:36:53 -0400 Jóhann B. Guðmundsson johan...@gmail.com wrote: Interesting since they did not do that when I joined QA what 5 or 6 years ago so again can you refer me to that discussion. It's always been a test case/critera that I remember... http://fedoraproject.org/wiki/QA/Meetings/20070117#Fedora_7 Shows upgrade test cases were there in Fedora 7 and one of the things QA was testing and ensuring. We tested for it to a limited extent ( via yum ) but we never officially supported it. We always stayed away from opening that pandora box and it was not until we found out that someone had stamped upgrades to be officially supported that we actually properly defined what should be tested, added the criteria for it and made it release blocking honestly: if dist-upgrade swould not work *nobody* would use Fedora for anything relevant Fedora would be *completly* meaningless from this moment on why? because nobody has the time and effort to install from scratch twice a year if he does more with his computer than click on the icons of the default screen after login this is not only the point for Fedora *any* relevant software which would only work a few months would become meaningsless expect for people which are bored and play around just for fun with no goal 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Thu, 15 Aug 2013 16:12:48 -0400 Jóhann B. Guðmundsson johan...@gmail.com wrote: On 08/15/2013 03:47 PM, Kevin Fenzi wrote: On Thu, 15 Aug 2013 15:36:53 -0400 Jóhann B. Guðmundsson johan...@gmail.com wrote: Interesting since they did not do that when I joined QA what 5 or 6 years ago so again can you refer me to that discussion. It's always been a test case/critera that I remember... http://fedoraproject.org/wiki/QA/Meetings/20070117#Fedora_7 Shows upgrade test cases were there in Fedora 7 and one of the things QA was testing and ensuring. We tested for it to a limited extent ( via yum ) but we never officially supported it. Thats not my recollection... upgrades via DVD media were always mentioned as supported and were tested by QA. Perhaps someone who was around inside Red Hat in the Fedora Core days could comment, but I remember Fedora pretty much carrying on with that in F7. Anyhow, we are getting far afield. if there's a desire change user expectations, we could discuss doing that. I think we will have to see what the proposal looks like and what upgrades and methods would make sense. kevin signature.asc Description: PGP 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Tue, 13 Aug 2013 22:41:37 -0700 Toshio Kuratomi a.bad...@gmail.com wrote: Additional agenda item: Mattdm, sgallagh, and I were talking about the general fesco sentiment towards mattdm's fedora future direction proposal and the multiple fedora products idea at post-flock breakfast. My understanding is that the sentiment was that it would be a board decision whether to go that route, that fesco would be on charge of implementing it, and that fesco was generally in favour of it. The three of us thought it would be a good idea for fesco to officially vote on whether we can get behind the idea and then send it to the board so that we can start putting some proposals together. (Sorry for top-posting... on my phone.) Well, or would it be better to have a concrete proposal to take to them? I don't see any harm I guess in fesco deciding that we are in favor in general of this plan and ask the Board if we are going down a path they don't want us to before writing up concrete proposals. kevin signature.asc Description: PGP 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 12:04 PM, Kevin Fenzi ke...@scrye.com wrote: On Tue, 13 Aug 2013 22:41:37 -0700 Toshio Kuratomi a.bad...@gmail.com wrote: Additional agenda item: Mattdm, sgallagh, and I were talking about the general fesco sentiment towards mattdm's fedora future direction proposal and the multiple fedora products idea at post-flock breakfast. My understanding is that the sentiment was that it would be a board decision whether to go that route, that fesco would be on charge of implementing it, and that fesco was generally in favour of it. The three of us thought it would be a good idea for fesco to officially vote on whether we can get behind the idea and then send it to the board so that we can start putting some proposals together. (Sorry for top-posting... on my phone.) Well, or would it be better to have a concrete proposal to take to them? I don't see any harm I guess in fesco deciding that we are in favor in general of this plan and ask the Board if we are going down a path they don't want us to before writing up concrete proposals. Right. Less worrying about what the Board thinks, more worrying about what FESCo thinks. If those two entities wind up not agreeing, then we can discuss that. As for the Board, I'm hoping to bring up the future direction stuff as a topic we should at least be paying close attention to in the next meeting. Having something from FESCo to review would be great too. josh -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 10:04:41AM -0600, Kevin Fenzi wrote: I don't see any harm I guess in fesco deciding that we are in favor in general of this plan and ask the Board if we are going down a path they don't want us to before writing up concrete proposals. Yeah, I was hoping to have discussion from Flock written up nicely for us to talk about at this meeting, but given the time and that I haven't eaten _breakfast_ yet, I don't think that's going to happen. For this meeting, I have several separate proposals: 1. In order to build what we need for the future of Fedora, FESCO endorses the idea of moving from a one-policy-fits-all-software policy to a tiered model as roughly laid out in http://mattdm.org/fedora/next, and recommends this to the board as the technical underpinning of our strategic direction. 2. FESCO-created working group to draft Fedora Base Design as called for in that proposal. 3. FESCO-created working group to draft Ring 2 policies and infrastructure needs. 4. Ask SCL team and FPC if they can find a way for SCL to be included in Fedora in F20 timeframe, within a special area of the current guidelines as a trial for ring 2 tech in Fedora. Also, not yet ready for a proposal but maybe for discussion: * We recommend Fedora move to a product-centered approach for designing, building, and marketing Fedora. * These products would be Fedora Workstation, Fedora Server, and Fedora Cloud (precise definitions to be developed), based around a common core shared wherever possible and with infrastructure for other groups based around other possible products to develop. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, 2013-08-14 at 13:00 -0400, Matthew Miller wrote: * These products would be Fedora Workstation, Fedora Server, and Fedora Cloud (precise definitions to be developed) Why not derive these definitions from the current Red Hat Enterprise Linux products? -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/14/2013 01:00 PM, Matthew Miller wrote: On Wed, Aug 14, 2013 at 10:04:41AM -0600, Kevin Fenzi wrote: I don't see any harm I guess in fesco deciding that we are in favor in general of this plan and ask the Board if we are going down a path they don't want us to before writing up concrete proposals. Yeah, I was hoping to have discussion from Flock written up nicely for us to talk about at this meeting, but given the time and that I haven't eaten _breakfast_ yet, I don't think that's going to happen. For this meeting, I have several separate proposals: 1. In order to build what we need for the future of Fedora, FESCO endorses the idea of moving from a one-policy-fits-all-software policy to a tiered model as roughly laid out in http://mattdm.org/fedora/next, and recommends this to the board as the technical underpinning of our strategic direction. 2. FESCO-created working group to draft Fedora Base Design as called for in that proposal. Has fesco already created that working group if so who's on it? 3. FESCO-created working group to draft Ring 2 policies and infrastructure needs. Has fesco already created that working group if so who's on it? Also, not yet ready for a proposal but maybe for discussion: snip * These products would be Fedora Workstation, Fedora Server, and Fedora Cloud (precise definitions to be developed), based around a common core shared wherever possible and with infrastructure for other groups based around other possible products to develop. The above does not solve historic problem and differences in our community and arguably gives us no benefits of implementing over what we currently have. For example what would be the default desktop in the Fedora workstation and why ? Would we be defaulting and or recommending one application over another in Fedora server for example openldap vs 389ds, kvm vs xen, postgresql vs mariadb if so why? Given that the above proposal are not direct products of SIG's who's in control of what goes in and what goes out of the Fedora Workstation, Fedora Server, and Fedora Cloud and their target audience ? As I see it the above part of the proposal only splits the default product into three different products without actually solving anything. Since I dont see how that you propose addresses and or solves any of the issues we are faced with I argue the way forward for us should be that Fedora products are the results/publication of each sub-community but not creation of whom releng/fesco/board specific Fedora individual or as an whole Fedora Workstation, Fedora Server, and Fedora Cloud SIG? JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Colin Walters (walt...@verbum.org) said: On Wed, 2013-08-14 at 13:00 -0400, Matthew Miller wrote: * These products would be Fedora Workstation, Fedora Server, and Fedora Cloud (precise definitions to be developed) Why not derive these definitions from the current Red Hat Enterprise Linux products? In terms of content and differentiation, likely because those are actually fairly poorly delineated products. Bill -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 02:26:55PM -0400, Jóhann B. Guðmundsson wrote: 2. FESCO-created working group to draft Fedora Base Design as called for in that proposal. Has fesco already created that working group if so who's on it? No. The proposal is to create such a group, through calling for volunteers. Has fesco already created that working group if so who's on it? Ditto. * These products would be Fedora Workstation, Fedora Server, and Fedora Cloud (precise definitions to be developed), based around a common core [...] For example what would be the default desktop in the Fedora workstation and why ? We (community; FESCO, Board, SIGs, and Teams) will work to define a vision for what Fedora needs, independent of upstream projects, and then work with upstreams to best meet those needs. Would we be defaulting and or recommending one application over another in Fedora server for example openldap vs 389ds, kvm vs xen, postgresql vs mariadb if so why? Ideally, we avoid tying ourselves down, but I think any such recommendations would be based on the level of support we're able to give to those things, and, again, how how they fit the goals we define. Given that the above proposal are not direct products of SIG's who's in control of what goes in and what goes out of the Fedora Workstation, Fedora Server, and Fedora Cloud and their target audience ? I think it's reasonable to have more formally-structured Fedora teams for each of these things. What do you think? As I see it the above part of the proposal only splits the default product into three different products without actually solving anything. These particular suggestions came from looking at some of the different requirements the project has overall, and concluding that no single default really addresses them well, but that these three areas cover important areas, each worth investing resources in. Since I dont see how that you propose addresses and or solves any of the issues we are faced with I argue the way forward for us should be that Fedora products are the results/publication of each sub-community but not creation of whom releng/fesco/board specific Fedora individual or as an whole Fedora Workstation, Fedora Server, and Fedora Cloud SIG? Can you rephrase this? I'm not sure I understand. If you can articulate what you mean by issues we are faced with, that would help, too. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/14/2013 03:51 PM, Matthew Miller wrote: snip Would we be defaulting and or recommending one application over another in Fedora server for example openldap vs 389ds, kvm vs xen, postgresql vs mariadb if so why? Ideally, we avoid tying ourselves down, but I think any such recommendations would be based on the level of support we're able to give to those things, and, again, how how they fit the goals we define. As I see it both the labels of default and recommendations cannot be apply to a community which provides multiple application and solutions and best effort in maintaining that by an fluctuating number of any given contributors at any given time. Given that the above proposal are not direct products of SIG's who's in control of what goes in and what goes out of the Fedora Workstation, Fedora Server, and Fedora Cloud and their target audience ? I think it's reasonable to have more formally-structured Fedora teams for each of these things. What do you think? What I think in that regard is that the SIG or sub-community already have established an governing structure around themselves,their target audience and the product they have decided to deliver to their target audience so adding an additional layer on top of that will have negative effects on the ecosystem they have established for themselves and live in. As I see it the above part of the proposal only splits the default product into three different products without actually solving anything. These particular suggestions came from looking at some of the different requirements the project has overall, and concluding that no single default really addresses them well, but that these three areas cover important areas, each worth investing resources in. Which areas are of importance is in the hand of the beholder. In other words each sub-community and what they are doing is important to them and those three areas by no means cover all the sub-communities that currently exist and might exist in the future of the project thus from my perspective this proposal thus is flawed and not future proof as the community continues to expand. With regards to resources investment pulling resources from one aspect of the project to put them into another will only cause imbalance within the overall existing ecosystem but you have to be a bit more clearer what you mean by each worth investing resources in as in where are those resources coming from or taken from and what are they? Since I dont see how that you propose addresses and or solves any of the issues we are faced with I argue the way forward for us should be that Fedora products are the results/publication of each sub-community but not creation of whom releng/fesco/board specific Fedora individual or as an whole Fedora Workstation, Fedora Server, and Fedora Cloud SIG? Can you rephrase this? I'm not sure I understand. If you can articulate what you mean by issues we are faced with, that would help, too. We have competing projects,products or application if you will in the project that are aiming at and competing for the same user base. Putting one of those at a higher level by default, by recommendation or even just by placing it on the front web page puts the others at disadvantage and will hinder growth and participation in the relevant sub-communities which will result in worse product and in turn will have negative outcome for the project in whole. At least that is how I see it. JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 05:32:15PM -0400, Jóhann B. Guðmundsson wrote: Putting one of those at a higher level by default, by recommendation or even just by placing it on the front web page puts the others at disadvantage and will hinder growth and participation in the relevant sub-communities which will result in worse product and in turn will have negative outcome for the project in whole. At least that is how I see it. Some projects are objectively better than other projects. Some projects may not be objectively better but are more closely aligned with our release schedule and support cycles. Some projects are actively developed in Fedora and as such can be more cleanly integrated into the distribution. Making it easier for users to obtain those projects is doing our users a service. It is not our responsibility to encourage growth and development of other projects that don't make things better for our users, and so it's inappropriate to provide equivalent promotion. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/14/2013 06:04 PM, Matthew Garrett wrote: On Wed, Aug 14, 2013 at 05:32:15PM -0400, Jóhann B. Guðmundsson wrote: Putting one of those at a higher level by default, by recommendation or even just by placing it on the front web page puts the others at disadvantage and will hinder growth and participation in the relevant sub-communities which will result in worse product and in turn will have negative outcome for the project in whole. At least that is how I see it. Some projects are objectively better than other projects. Some projects may not be objectively better but are more closely aligned with our release schedule and support cycles. Some projects are actively developed in Fedora and as such can be more cleanly integrated into the distribution. As soon as we slip that argument no longer stands and we always slip... Making it easier for users to obtain those projects is doing our users a service. It is not our responsibility to encourage growth and development of other projects that don't make things better for our users, and so it's inappropriate to provide equivalent promotion. You do realize that each sub community is trying to reach out to their own target users, even an single application might be reaching to a specific target audience so in that perspective there is no such thing as our users. So in other words what to take from your response is that you are saying that you do not want increased participation in the project as whole and or only for specific areas of the project? JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 06:49:17PM -0400, Jóhann B. Guðmundsson wrote: On 08/14/2013 06:04 PM, Matthew Garrett wrote: Some projects are objectively better than other projects. Some projects may not be objectively better but are more closely aligned with our release schedule and support cycles. Some projects are actively developed in Fedora and as such can be more cleanly integrated into the distribution. As soon as we slip that argument no longer stands and we always slip... We suck, so we should keep on sucking? Come on. Our inability to maintain a schedule is the result of a wide variety of factors that we can improve, not an inherent reality. Making it easier for users to obtain those projects is doing our users a service. It is not our responsibility to encourage growth and development of other projects that don't make things better for our users, and so it's inappropriate to provide equivalent promotion. You do realize that each sub community is trying to reach out to their own target users, even an single application might be reaching to a specific target audience so in that perspective there is no such thing as our users. If you visit fedoraproject.org and click on Download now, you'll get a 64-bit x86 desktop live image. Those are our de-facto target users. The proposal under discussion actually broadens that slightly by making it clearer that we offer three separate first-class products for three different user-cases. You seem to be arguing for a different scenario, one where arbitrary subsets of the Fedora package set are advertised equally. That's not the status quo, and so I think you need to follow this proposal's lead and come up with a solid argument for how your position improves Fedora and what technical and policy changes are needed to get there. So in other words what to take from your response is that you are saying that you do not want increased participation in the project as whole and or only for specific areas of the project? I want increased participation in the creation of Fedora, which is a product with a defined set of software shipped as default. I'm also happy with people working to make it practical to use Fedora as the basis for derived products (such as the spins and remixes), providing that they don't compromise the product that we're producing. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Additional agenda item: Mattdm, sgallagh, and I were talking about the general fesco sentiment towards mattdm's fedora future direction proposal and the multiple fedora products idea at post-flock breakfast. My understanding is that the sentiment was that it would be a board decision whether to go that route, that fesco would be on charge of implementing it, and that fesco was generally in favour of it. The three of us thought it would be a good idea for fesco to officially vote on whether we can get behind the idea and then send it to the board so that we can start putting some proposals together. (Sorry for top-posting... on my phone.) -Toshio On Aug 13, 2013 9:39 PM, Kevin Fenzi ke...@scrye.com wrote: Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2013-08-14 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1143 F20 System Wide Change: No Default Sendmail - https://fedoraproject.org/wiki/Changes/NoDefaultSendmail .fesco 1143 https://fedorahosted.org/fesco/ticket/1143 #topic #1144 F20 System Wide Change: No Default Syslog - https://fedoraproject.org/wiki/Changes/NoDefaultSyslog .fesco 1144 https://fedorahosted.org/fesco/ticket/1144 = New business = #topic #1156 F20 System Wide Change: Ruby on Rails 4.0 - https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.0 .fesco 1156 https://fedorahosted.org/fesco/ticket/1156 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- 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
