Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 05:43:15PM -0500, Matthew Miller wrote: > On Wed, Nov 14, 2018 at 10:30:06PM +, Zbigniew Jędrzejewski-Szmek wrote: > > I love Fedora, but the idea that you can take a 3 year old Fedora and > > put it out on the web is just bonkers. We don't have the manpower and > > the procedures to make Fedora suitable for this kind of use. > > We, from my statistics, there's a lot of 3-year-old (and older!) > Fedora out on the web today. But that aside, let's say we wanted to do it > right *and* still keep the distro exciting and fun to hack on. > > What person-power and procedures would we need to add? This is like asking how to turn Fedora into RHEL or Debian stable w/ support. I think we'd need to a) specify a set of packages, the "core", everything outside in the "universe" is not supported b) find people to provide support for the lifetime of the edition c) enforce the update policies to only do limited updates in old versions d) find people to QA for those updates as they happen I think it just requires a whole new set of people working on this. It's not only that this is additional and different work. It's also that this requires a *different mindset*. I think one of the reasons that Debian finds it so hard to move, is because they *have* reached this mindset, and now every new thing is suspicious and best-avoided. Long-term stability is at odds with "First", and I think if we try to do that, we'll never do it very well, but the things we are quite good at will suffer anyway. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Thursday's FPC Meeting (2018-11-15 17:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2018-11-15 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2018-11-15 09:00 PST US/Pacific 2018-11-15 12:00 EST --> US/Eastern <-- 2018-11-15 17:00 GMT Europe/London 2018-11-15 17:00 UTC UTC 2018-11-15 18:00 CET Europe/Berlin 2018-11-15 18:00 CET Europe/Paris 2018-11-15 22:30 IST Asia/Calcutta New Day: Friday - 2018-11-16 01:00 HKT Asia/Hong_Kong 2018-11-16 01:00 +08 Asia/Singapore 2018-11-16 02:00 JST Asia/Tokyo 2018-11-16 03:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #719 Simplify packaging of forge-hosted projects .fpc 719 https://pagure.io/packaging-committee/issue/719 = New business = #topic #806 Procedure should be updated for Pull Requests .fpc 806 https://pagure.io/packaging-committee/issue/806 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wednesday, November 14, 2018, Laura Abbott wrote: > On 11/14/18 5:29 AM, Matthew Miller wrote: > >> On Wed, Nov 14, 2018 at 12:32:14PM +0100, Adam Samalik wrote: >> >>> Do we have any user data about what "stability" means to users and on >>> what >>> different levels that can be achieved? Is it about app versions such as >>> MariaDB? is it about language runtime versions such as Node.js? is it >>> about >>> things like glibc? or kernel? Or does it need to be the whole distro as >>> we >>> have it today? >>> >>> In case we don't find a uniform solution that would fit all those cases >>> (== >>> for the whole release as we know it today), focusing on those specific >>> levels (modules? rings?! ;) ) might help with different approaches could >>> help us at least a little bit. Well, considering there are some. >>> >> >> I'm thinking mostly about a base platform. And even there, I think kernel >> versions and such can change -- we don't need a RHEL-style kernel ABI >> promise. We just need changes there to not break 1) the hardware it runs >> on >> and 2) the stuff on top. >> >> >> > So it's business as usual for the kernel then :) > > More seriously, I do think we need to define what LTS actually means. > Especially for the kernel, there's already LTS defined upstream but that > may not align with what Fedora wants to do elsewhere. We may not want > a super strong RHEL ABI but actual LTS users may not want to deal with > other aspects of a kernel upgrade. > > The kernel is actually transparent to most users. Userspace ABI is guaranteed by upstream. So as long as kernel upgrades do not break users won't see much of a difference. The only two exceptions are: 1) Out of tree driver users 2) People buying new hardware For 1) kernel upgrades might be a problem if there driver is not updated fast enough For 2) not having the upgrades is a problem because they would have to wait months before they can use their new hardware. So ignoring case 1) it would be indeed "business as usual" (Assuming upgrades do not break the system but that's what testing is for). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Rawhide-20181114.n.0 compose check report
No missing expected images. Failed openQA tests: 37/142 (x86_64), 5/24 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20181113.n.0): ID: 308758 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/308758 ID: 308763 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/308763 ID: 308766 Test: x86_64 Server-dvd-iso server_role_deploy_database_server URL: https://openqa.fedoraproject.org/tests/308766 ID: 308770 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/308770 ID: 308774 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/308774 ID: 308796 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/308796 ID: 308813 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/308813 ID: 308843 Test: x86_64 universal install_kickstart_firewall_disabled URL: https://openqa.fedoraproject.org/tests/308843 ID: 308845 Test: x86_64 universal install_kickstart_user_creation URL: https://openqa.fedoraproject.org/tests/308845 ID: 308847 Test: x86_64 universal install_kickstart_firewall_configured URL: https://openqa.fedoraproject.org/tests/308847 ID: 308849 Test: x86_64 universal install_kickstart_nfs URL: https://openqa.fedoraproject.org/tests/308849 Old failures (same test failed in Rawhide-20181113.n.0): ID: 308754 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/308754 ID: 308755 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/308755 ID: 308781 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/308781 ID: 308783 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/308783 ID: 308784 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/308784 ID: 308785 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/308785 ID: 308799 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/308799 ID: 308800 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/308800 ID: 308801 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/308801 ID: 308803 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/308803 ID: 308819 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/308819 ID: 308824 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/308824 ID: 308839 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/308839 ID: 308840 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/308840 ID: 308841 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/308841 ID: 308854 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/308854 ID: 308855 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/308855 ID: 308856 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/308856 ID: 308857 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/308857 ID: 308871 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/308871 ID: 308872 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/308872 ID: 308879 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/308879 ID: 308880 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/308880 ID: 308891 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/308891 ID: 308892 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/308892 ID: 308897 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/308897 ID: 308898 Test: x86_64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/308898 ID: 308899 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/308899 ID: 308902 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/308902 ID: 308919 Test: i386 universa
Fedora rawhide compose report: 20181114.n.0 changes
OLD: Fedora-Rawhide-20181113.n.0 NEW: Fedora-Rawhide-20181114.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 5 Dropped packages:9 Upgraded packages: 186 Downgraded packages: 0 Size of added packages: 7.31 MiB Size of dropped packages:11.54 MiB Size of upgraded packages: 6.21 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -121.09 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cinnamon live i386 Path: Spins/i386/iso/Fedora-Cinnamon-Live-i386-Rawhide-20181114.n.0.iso Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20181114.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: asv-0.3.1-3.fc30 Summary: Airspeed Velocity: A simple Python history benchmarking tool RPMs:asv asv-doc Size:7.16 MiB Package: golang-github-census-instrumentation-opencensus-proto-0.1.0-1.fc30 Summary: Language Independent Interface Types For OpenCensus RPMs:golang-github-census-instrumentation-opencensus-proto-devel Size:56.02 KiB Package: golang-github-pascaldekloe-goe-0-0.1.20181113git57f6aae.fc30 Summary: Common enterprise features for the Go programming language RPMs:golang-github-pascaldekloe-goe-devel Size:28.88 KiB Package: rust-bit-set-0.5.0-1.fc30 Summary: Set of bits RPMs:rust-bit-set+default-devel rust-bit-set+std-devel rust-bit-set-devel Size:35.32 KiB Package: rust-bit-vec-0.5.0-1.fc30 Summary: Vector of bits RPMs:rust-bit-vec+default-devel rust-bit-vec+std-devel rust-bit-vec-devel Size:39.77 KiB = DROPPED PACKAGES = Package: pulp-2.15.2-2.fc29 Summary: An application for managing software repositories RPMs:pulp-admin-client pulp-agent pulp-consumer-client pulp-doc pulp-nodes-admin-extensions pulp-nodes-child pulp-nodes-common pulp-nodes-consumer-extensions pulp-nodes-parent pulp-selinux pulp-server python2-pulp-agent-lib python2-pulp-bindings python2-pulp-client-lib python2-pulp-common python2-pulp-devel python2-pulp-oid_validation python2-pulp-repoauth python2-pulp-streamer Size:7.06 MiB Package: pulp-docker-3.1.1-1.fc29 Summary: Support for Docker content in the Pulp platform RPMs:pulp-docker-admin-extensions pulp-docker-doc pulp-docker-plugins python2-pulp-docker-common Size:352.27 KiB Package: pulp-ostree-1.3.0-2.fc28 Summary: Support for OSTree content in the Pulp platform RPMs:pulp-ostree-admin-extensions pulp-ostree-doc pulp-ostree-plugins python2-pulp-ostree-common Size:319.25 KiB Package: pulp-puppet-2.15.2-1.fc29 Summary: Support for Puppet content in the Pulp Platform RPMs:pulp-puppet-admin-extensions pulp-puppet-consumer-extensions pulp-puppet-devel pulp-puppet-doc pulp-puppet-handlers pulp-puppet-plugins pulp-puppet-tools python2-pulp-puppet-common Size:473.18 KiB Package: pulp-python-2.0.2-1.fc29 Summary: Support for Python content in the Pulp platform RPMs:pulp-python-admin-extensions pulp-python-doc pulp-python-plugins python2-pulp-python-common Size:1.18 MiB Package: pulp-rpm-2.15.2-1.fc29 Summary: Support for RPM content in the Pulp platform RPMs:pulp-rpm-admin-extensions pulp-rpm-consumer-extensions pulp-rpm-devel pulp-rpm-doc pulp-rpm-handlers pulp-rpm-plugins pulp-rpm-yumplugins python2-pulp-rpm-common Size:791.87 KiB Package: python-crane-3.1.1-2.fc29 Summary: A WSGI app providing a docker-registry-like API with redirection RPMs:python2-crane Size:1.35 MiB Package: rust-coco-0.3.4-4.fc29 Summary: Concurrent collections RPMs:rust-coco-devel Size:36.48 KiB Package: rust-deque-0.3.2-5.fc29 Summary: A (mostly) lock-free concurrent work-stealing deque RPMs:rust-deque-devel Size:20.33 KiB = UPGRADED PACKAGES = Package: GMT-5.4.4-4.fc30 Old package: GMT-5.4.4-3.fc30 Summary: Generic Mapping Tools RPMs: GMT GMT-common GMT-devel GMT-doc Size: 87.14 MiB Size change: -336 B Changelog: * Wed Nov 14 2018 Orion Poplawski - 5.4.4-4 - Rebuild for octave 4.4 Package: annobin-8.60-1.fc30 Old package: annobin-8.59-1.fc30 Summary: Binary annotation plugin for GCC RPMs: annobin Size: 1.05 MiB Size change: 736 B Changelog: * Tue Nov 13 2018 Nick Clifton - 8.60-1 - Skip -Wl,-z,now and -Wl,-z,relro checks for non-gcc produced binaries. (#1624421) Package: appliance-tools-008.0-11.fc30 Old package: appliance-tools-008.0-10.fc29 Summary: Tools for building Appliances RPMs: appliance-tools Size: 57.19 KiB Size change: 68 B Changelog: * Tue Nov 13 2018 Neal Gompa - 008.0-11 - Port to Python 3 - Backport xz multi-threading support - Refresh nss libs hack patch Package: c-ares-1.15.0-1.fc30 Old package: c-ares-1.14.0-5.fc30 Summary: A library that performs asynchronous DNS operations RPMs: c-ares c-ares-devel Size: 1.03 MiB Size change: 45.73 KiB Changelog: * Tue
Self Introduction: Milind Changire
Hello people, I'm a Gluster engineer and have joined the Fedora community with an effort to factor off the Glusterfs SELinux bits off the primary selinux-policy-targeted package. This factoring with help the distribution SELinux policy maintainers as well as Gluster engineers to ship their policies independently without getting in each others way. The glusterfs-selinux effort will also help the Gluster project stay as close to the SELinux deployment requirements as possible without long delays while trying to get the Gluster SELinux bits into the distribution SELinux policies. Please take a look at the glusterfs-selinux Review Request and provide valuable feedback on the packaging and the entire SELinux package in general: https://bugzilla.redhat.com/show_bug.cgi?id=1649713 -- Milind ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
The major OS competitor has moved to a 6 month release cadence, so that needs to be taken into account. I suspect the easiest way to have a longer supported system is by NOT having a longer supported system. For the case of desktop hardware vendors something like a constantly updating silverblue might fit better. It could be a continuously updating system "automatically" moving to the next release shortly after the next fedora version is released. As it is image based breakage should be harder to occur. It will be no more or less faster updated than competitor operating systems that manufacturers use. On Thu, 15 Nov 2018, 00:15 Ben Rosser On Wed, Nov 14, 2018 at 6:04 PM Stephen John Smoogen > wrote: > > > > On Wed, 14 Nov 2018 at 16:03, Ben Rosser wrote: > > > > > > On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen > wrote: > > > > From what I have talked with in the past.. 3 years is their bare > > > > minimum and 7 is their what we really want. It usually takes the > > > > vendor about 3-6 months of work to make sure the OS works on their > > > > hardware without major problems and then they want people to buy > > > > support contracts for 3-5 years where the number of problems needed > in > > > > year 3-5 are none. [This means that they want to have Fedora N for > 3-6 > > > > months before their laptops ship with it. So you ship them a frozen > > > > preload before you release to public. They also want any shipped to > > > > 'last' for the warranty cycle because trying to deal with update > > > > questions when N eol's in the middle costs them a lot.] > > > > > > If 7 years is what manufacturers really want, then it sounds like > > > > Well they also want a Ferrari and all support to be done upstream for > > free. 7 is usually their counter to 13 months. You start going down > > there to find that what they really settle for will be 3-4 years as > > most people don't extend warranties that long. > > Well, even so, 3-4 years would be a pretty long time. > > My point about EPEL was that, Fedora currently does produce a > long-term-support type product (admittedly for another distro). It's > EPEL. > > Except we don't really push it. EPEL is an opt-in thing, which means > lots of packages don't have EPEL branches-- possibly because the > maintainers didn't want to commit to maintaining a package in a > long-term-support type environment, or possibly because the > maintainers never thought or bothered to create an EPEL branch, or > possibly because there are too many dependencies that don't exist in > EPEL and tracking down those maintainers isn't worth the time and > effort. I know that I would package more things for EPEL if I could > reuse Fedora specs with a minimum of fuss and I didn't have to spend > time getting a bunch of dependent packages built. > > It is not clear to me that Fedora having two long-term-support type > products would be a good idea, as I am not sure that we have the > resources to maintain *one* at the moment. That makes me think we'd > want to tie a hypothetical "Fedora LTS" directly to RHEL/CentOS/EPEL > somehow, and find a way to reuse the work for both efforts. > > Ben Rosser > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 4:42 PM, John Florian wrote: I still don't understand what makes updating these for a *new* release significantly easier than an *existing* one. So let's just say GNOME (or whatever) comes out next month with a new major release we want to showcase. Why is it necessary to have a Fedora 30 to be able to realize this update. What is so difficult about providing this for Fedora 29. I'm trying to understand why these upstream updates can't be decoupled from the Fedora release schedule. It's all a matter of QA. The freeze, the blocker bug process, and the quantity of users who test the stuff for us. We'd need major changes to our updates process to account for this in a mid-release update. The blocker bugs process would be needed, for a single bodhi update. At least a month or two of testing (during which new versions of the update will be released, so the update will have to go through some iterations). And lots and lots of testers: currently we get those for free because tons of people help us test beta releases of Fedora, I think far more than run updates-testing. This is all doable and solvable. Not a blocker. But if we don't take it seriously and make some big changes in how we release updates, it won't go well. Not well at all. So I'd recommend against it, unless there is some major benefit available from doing so. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 6:04 PM Stephen John Smoogen wrote: > > On Wed, 14 Nov 2018 at 16:03, Ben Rosser wrote: > > > > On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen > > wrote: > > > From what I have talked with in the past.. 3 years is their bare > > > minimum and 7 is their what we really want. It usually takes the > > > vendor about 3-6 months of work to make sure the OS works on their > > > hardware without major problems and then they want people to buy > > > support contracts for 3-5 years where the number of problems needed in > > > year 3-5 are none. [This means that they want to have Fedora N for 3-6 > > > months before their laptops ship with it. So you ship them a frozen > > > preload before you release to public. They also want any shipped to > > > 'last' for the warranty cycle because trying to deal with update > > > questions when N eol's in the middle costs them a lot.] > > > > If 7 years is what manufacturers really want, then it sounds like > > Well they also want a Ferrari and all support to be done upstream for > free. 7 is usually their counter to 13 months. You start going down > there to find that what they really settle for will be 3-4 years as > most people don't extend warranties that long. Well, even so, 3-4 years would be a pretty long time. My point about EPEL was that, Fedora currently does produce a long-term-support type product (admittedly for another distro). It's EPEL. Except we don't really push it. EPEL is an opt-in thing, which means lots of packages don't have EPEL branches-- possibly because the maintainers didn't want to commit to maintaining a package in a long-term-support type environment, or possibly because the maintainers never thought or bothered to create an EPEL branch, or possibly because there are too many dependencies that don't exist in EPEL and tracking down those maintainers isn't worth the time and effort. I know that I would package more things for EPEL if I could reuse Fedora specs with a minimum of fuss and I didn't have to spend time getting a bunch of dependent packages built. It is not clear to me that Fedora having two long-term-support type products would be a good idea, as I am not sure that we have the resources to maintain *one* at the moment. That makes me think we'd want to tie a hypothetical "Fedora LTS" directly to RHEL/CentOS/EPEL somehow, and find a way to reuse the work for both efforts. Ben Rosser ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On 11/14/18 2:42 PM, John Florian wrote: > I still don't understand what makes updating these for a *new* release > significantly easier than an *existing* one. So let's just say GNOME > (or whatever) comes out next month with a new major release we want to > showcase. Why is it necessary to have a Fedora 30 to be able to realize > this update. What is so difficult about providing this for Fedora 29. > I'm trying to understand why these upstream updates can't be decoupled > from the Fedora release schedule. Well, there's the problem all rolling releases have with that: The user (mostly) has to accept changes when the distro pushes them. If you push major updates at release boundries, users can choose to stay on the older release until they are ready to devote time to the upgrade. Some users are fine with change any old time and adapt, but others dislike that to varying degrees. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On 11/14/18 5:29 AM, Matthew Miller wrote: On Wed, Nov 14, 2018 at 12:32:14PM +0100, Adam Samalik wrote: Do we have any user data about what "stability" means to users and on what different levels that can be achieved? Is it about app versions such as MariaDB? is it about language runtime versions such as Node.js? is it about things like glibc? or kernel? Or does it need to be the whole distro as we have it today? In case we don't find a uniform solution that would fit all those cases (== for the whole release as we know it today), focusing on those specific levels (modules? rings?! ;) ) might help with different approaches could help us at least a little bit. Well, considering there are some. I'm thinking mostly about a base platform. And even there, I think kernel versions and such can change -- we don't need a RHEL-style kernel ABI promise. We just need changes there to not break 1) the hardware it runs on and 2) the stuff on top. So it's business as usual for the kernel then :) More seriously, I do think we need to define what LTS actually means. Especially for the kernel, there's already LTS defined upstream but that may not align with what Fedora wants to do elsewhere. We may not want a super strong RHEL ABI but actual LTS users may not want to deal with other aspects of a kernel upgrade. Laura ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On 11/14/18 1:26 PM, Carmen Bianca Bakker wrote: Je mer, 2018-11-14 je 18:34 +0100, Kevin Kofler skribis: That is what make us different distro with its own user base. Want the very same but LTS system? try CentOS. Or RHEL. +1. LTS Fedora is what CentOS is for. Why should we not just point users who want LTS to CentOS and EPEL? Crazy idea: Would it be possible to integrate CentOS into the Fedora fold? It's not a crazy idea at all, but the details are tricky. Since CentOS is essentially a RHEL derivative, this would require RedHat collaboration. In principle, Fedora is an R&D precursor for RHEL, but I have not seen an official statement on how RedHat bakes RHEL out of Fedora. If you squint at https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux , it seems that they fork Fedora every 4 or so years, and take about a year of QA, while selectively (?) back-porting subsequent Fedora developments. The result is RedHat-branded and released as RHEL; whereas CentOS follows up while stripping RedHat branding (yes, there's a certain amount of forth-and-back :) I wonder if RedHat could be persuaded to modify their process to adopt a Fedora release instead of forking it, and backport into that release---let's call it "Fedora LTS a.k.a. CentOS Release Candidate" (FLAC-RC :). It would require perhaps more effort on the part of RedHat to avoid breakage in the middle of their development cycle, but that's probably a good CI practice anyway. Matthew, do you think that is something that RedHat might be interested in? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 10:30:06PM +, Zbigniew Jędrzejewski-Szmek wrote: > I love Fedora, but the idea that you can take a 3 year old Fedora and > put it out on the web is just bonkers. We don't have the manpower and > the procedures to make Fedora suitable for this kind of use. We, from my statistics, there's a lot of 3-year-old (and older!) Fedora out on the web today. But that aside, let's say we wanted to do it right *and* still keep the distro exciting and fun to hack on. What person-power and procedures would we need to add? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On 11/14/18 4:38 PM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Nov 14, 2018 at 12:37:46PM -0500, John Florian wrote: On 11/14/18 10:36 AM, mcatanz...@gnome.org wrote: We need to rebase GNOME within about two months of the new upstream releases, or we'll lose our edge with the GNOME community. We'd be ceding our position as best GNOME distro to Ubuntu and Arch. It seems wrong that a DE, even if it's the default, has so much sway over the distro as a whole. It's not just gnome. It's also gcc, glibc, boost, systemd, python, and any other project which cannot be upgraded easily mid-cycle. Having a chance to push a new version every six months is much better than waiting a year. I still don't understand what makes updating these for a *new* release significantly easier than an *existing* one. So let's just say GNOME (or whatever) comes out next month with a new major release we want to showcase. Why is it necessary to have a Fedora 30 to be able to realize this update. What is so difficult about providing this for Fedora 29. I'm trying to understand why these upstream updates can't be decoupled from the Fedora release schedule. So a one-year cycle means a major GNOME version update will need to land in the middle of a release to avoid that. And these do not have a good reputation for stability. Basically we'll wind up with a bunch of bugs landing halfway through the release, and without the usual Fedora QA process to ensure the most important of them get fixed before they reach users. Why can't GNOME be updated mid-release like any other application? Why does the QA process require the cadence of the whole distro release process to bend to GNOME? Can't a major GNOME update land in the testing repos to have QA issues sorted out there just as well as in some alpha/beta release of the overall Fedora? For me, any discussions about .1 or .5 completely miss the point. The numbering does not matter at all, the freeze and the testing and bugfixing matters. If we do it every 6 months, we might just as well call this a new release each time. As mentioned elsewhere in this thread, we have plenty of technical issues to solve, including security bugs and whatnot. Let's not get distracted by numbering. I agree the numbering is irrelevant... I never said it was. It was said or implied that QA works better *between* releases and I don't see why that cannot occur for a release that's already out the door. I mean isn't that what the testing repos are for? So I'm proposing to partly evolve to a sort of rolling distro. If the schedule decoupling can occur, it should then be possible to move Fedora to a yearly release schedule, provide a 6 month upgrade window and reduce maintainer burden because there's only 1 or 2 supported releases instead of 2 or 3. That would mean releases are supported for 18 months instead of 13. Change the periods how you wish, but the decoupling would allow getting longer support while requiring less work due to fewer concurrent releases. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On 11/14/18 2:35 AM, Daniel P. Berrangé wrote: If Fedora had longer life cycles, and more streams maintained in parallel, then I think the result would be that I end up doing rebases for everything I maintain rather than trying to backport anything. Admittedly this would somewhat negate the supposed benefit of having stable long life releases, but its either that or the releases bitrot accumulating more & more bugs & security flaws. At least for the kernel, if we actually had a Fedora LTS we could do the opposite of what we have now which is rebase as soon as the kernel releases. The kernel already has LTS releases available which are nominally maintained for two years (c.f. https://www.kernel.org/category/releases.html). Because of the timing of the kernel releases (about every 90 days) we just end up rebasing within a Fedora release because there usually isn't time to try and pick an LTS kernel to use. An actual Fedora LTS would mean we could potentially align to what LTS kernel upstream chooses. More generally though, this makes sense for the kernel because that project already thinks about LTS. If a project doesn't already have a well defined LTS release then I suspect many packagers will just end up rebasing because it's more comprehensive. Thanks, Laura ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 05:09:18PM -0500, Matthew Miller wrote: > On Wed, Nov 14, 2018 at 09:54:45PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > > The answer is "a lot". I don't think we have any hard numbers, but > > > > see https://pagure.io/fesco/issue/1935. Generally, it seems we can't > > > > process the CVEs we get now. > > > > "This result was limited to 1000 bugs." → that's just for CVEs. > > > What happens if we limit that to a smaller subset, though? > > What do you mean? > > There are zillions of CVES across all of the packages in the entire Fedora > collection. How many are there against, say, the subset used for the IoT > spin (and potential future edition)? bluez, nginx, systemd, mysql, gdb, bzip2, openjpg, imagemagick, shutter, exiv2, libexif, libkdcraw, glibc, php, busybox, tcpdump, bintuils, that's from the top of the list. I love Fedora, but the idea that you can take a 3 year old Fedora and put it out on the web is just bonkers. We don't have the manpower and the procedures to make Fedora suitable for this kind of use. We *could* change what Fedora is, by making it stable and long-lived, but at least I would then find a different distro to hack on. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On 13 November 2018 23:36:38 GMT, Matthew Miller wrote: > >Hi everyone! Let's talk about something new and exciting. Assuming a system that is automatically updating, but doesn't get upgraded to the next fedora release - a system like this needs to degrade progressively but securely: after thirteen months GUI applications are unsupported and are actively removed by dnf updates; after four years network servers are unsupported, shut down and removed; after seven years sshd is removed, default runlevel set to 1; after ten years runlevel is set to zero. This is how you allow longer term support for server applications, without supporting old GUI software, and without leaving zombie machines (and virtual machines) laying around on the net causing trouble. This would be responsible lifecycle management. -- Bruno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, 14 Nov 2018 at 16:03, Ben Rosser wrote: > > On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen wrote: > > From what I have talked with in the past.. 3 years is their bare > > minimum and 7 is their what we really want. It usually takes the > > vendor about 3-6 months of work to make sure the OS works on their > > hardware without major problems and then they want people to buy > > support contracts for 3-5 years where the number of problems needed in > > year 3-5 are none. [This means that they want to have Fedora N for 3-6 > > months before their laptops ship with it. So you ship them a frozen > > preload before you release to public. They also want any shipped to > > 'last' for the warranty cycle because trying to deal with update > > questions when N eol's in the middle costs them a lot.] > > If 7 years is what manufacturers really want, then it sounds like Well they also want a Ferrari and all support to be done upstream for free. 7 is usually their counter to 13 months. You start going down there to find that what they really settle for will be 3-4 years as most people don't extend warranties that long. > CentOS is much better positioned to be get shipped on laptops than > Fedora. Instead of working on a new "Fedora LTS" for this usage case, > would time be better spent improving EPEL and CentOS for the > desktop/laptop use case? I'd always thought of CentOS/RHEL as "Fedora > LTS" anyway, to be honest. > > Ben Rosser > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On 11/14/18 6:29 AM, Matthew Miller wrote: On Wed, Nov 14, 2018 at 12:32:14PM +0100, Adam Samalik wrote: Do we have any user data about what "stability" means to users and on what different levels that can be achieved? Is it about app versions such as MariaDB? is it about language runtime versions such as Node.js? is it about things like glibc? or kernel? Or does it need to be the whole distro as we have it today? In case we don't find a uniform solution that would fit all those cases (== for the whole release as we know it today), focusing on those specific levels (modules? rings?! ;) ) might help with different approaches could help us at least a little bit. Well, considering there are some. I'm thinking mostly about a base platform. And even there, I think kernel versions and such can change -- we don't need a RHEL-style kernel ABI promise. We just need changes there to not break 1) the hardware it runs on and 2) the stuff on top. From my standpoint the thing to run slow to keep userspace ABI compatible are the basic userspace enablers: system compilers, libc, and other shared libraries that are commonly required by most of the compiled packages. Similar for basic OS pieces: init system, dbus, etc. Move the kernel faster, move the applications faster, but keep that middle slower and stable. Having that platform live on the gcc/libc 1 year cycle makes way more sense than the 6 month cycle we have today. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 09:54:45PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > The answer is "a lot". I don't think we have any hard numbers, but > > > see https://pagure.io/fesco/issue/1935. Generally, it seems we can't > > > process the CVEs we get now. > > > "This result was limited to 1000 bugs." → that's just for CVEs. > > What happens if we limit that to a smaller subset, though? > What do you mean? There are zillions of CVES across all of the packages in the entire Fedora collection. How many are there against, say, the subset used for the IoT spin (and potential future edition)? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
El mié., 14 nov. 2018 20:09, Matthew Miller escribió: > On Wed, Nov 14, 2018 at 06:11:48PM +0100, Iñaki Ucar wrote: > > > Mostly blue sky -- let's generate ideas! -- but let's also stay within > > > reasonable possibilities, and also, you know, keeping it Fedora. > > > Particularly, I'm pretty sure about the goals: 1. getting Fedora > desktop and > > > IoT shipped on systems and 2. expanding the community by getting > Fedora into > > > places which don't consider us because we're perceived as too fleeting. > > > > Why not make just IoT LTS? > > That's a possibility. How would we do that? > IoT has quite particular requirements. Ubuntu Core was made with that in mind and, AFAIK, it's a complete different thing. Iñaki ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
Josh Boyer (jwbo...@fedoraproject.org) said: > > > If 7 years is what manufacturers really want, then it sounds like > > > CentOS is much better positioned to be get shipped on laptops than > > > Fedora. Instead of working on a new "Fedora LTS" for this usage case, > > > would time be better spent improving EPEL and CentOS for the > > > desktop/laptop use case? I'd always thought of CentOS/RHEL as "Fedora > > > LTS" anyway, to be honest. > > > > The point of a Fedora LTS for these manufacturers, if it were to exist, > > is to give them a channel to partner with, work on support with, and > > a software base they can get needed changes into. > > Agreed. Fedora is well positioned to do that. In fact, it's well > positioned for the manufacturers themselves to get their software > changes in as well. I think there is an opportunity here for both > sides that's worth looking at. > > > AFAIK, CentOS isn't set up to accept changes (into the base repo) or > > provide that level of support. And if they wanted to do it with Red Hat > > at the RHEL level... presumably they would already be doing so. > > That would presume a lot more as well. Do both parties want to pursue > that market? Do both parties get benefits from it? Are the > development models and support terms structured in a way that > facilitates that? Even if we assume an answer of "yes" for all of > those things and RHEL is pursuing it, that doesn't mean Fedora cannot > or should not, right? No, it doesn't mean Fedora can't do that. My main point is that I don't see any situations where those answers are all 'yes' for CentOS, so I don't think trying to position CentOS for this makes sense it either makes sense for RHEL, or for Fedora (or for both). Bill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 04:48:04PM -0500, Matthew Miller wrote: > On Wed, Nov 14, 2018 at 09:29:31PM +, Zbigniew Jędrzejewski-Szmek wrote: > > The answer is "a lot". I don't think we have any hard numbers, but > > see https://pagure.io/fesco/issue/1935. Generally, it seems we can't > > process the CVEs we get now. > > "This result was limited to 1000 bugs." → that's just for CVEs. > > What happens if we limit that to a smaller subset, though? What do you mean? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 4:20 PM Bill Nottingham wrote: > > Ben Rosser (rosser@gmail.com) said: > > On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen > > wrote: > > > From what I have talked with in the past.. 3 years is their bare > > > minimum and 7 is their what we really want. It usually takes the > > > vendor about 3-6 months of work to make sure the OS works on their > > > hardware without major problems and then they want people to buy > > > support contracts for 3-5 years where the number of problems needed in > > > year 3-5 are none. [This means that they want to have Fedora N for 3-6 > > > months before their laptops ship with it. So you ship them a frozen > > > preload before you release to public. They also want any shipped to > > > 'last' for the warranty cycle because trying to deal with update > > > questions when N eol's in the middle costs them a lot.] > > > > If 7 years is what manufacturers really want, then it sounds like > > CentOS is much better positioned to be get shipped on laptops than > > Fedora. Instead of working on a new "Fedora LTS" for this usage case, > > would time be better spent improving EPEL and CentOS for the > > desktop/laptop use case? I'd always thought of CentOS/RHEL as "Fedora > > LTS" anyway, to be honest. > > The point of a Fedora LTS for these manufacturers, if it were to exist, > is to give them a channel to partner with, work on support with, and > a software base they can get needed changes into. Agreed. Fedora is well positioned to do that. In fact, it's well positioned for the manufacturers themselves to get their software changes in as well. I think there is an opportunity here for both sides that's worth looking at. > AFAIK, CentOS isn't set up to accept changes (into the base repo) or > provide that level of support. And if they wanted to do it with Red Hat > at the RHEL level... presumably they would already be doing so. That would presume a lot more as well. Do both parties want to pursue that market? Do both parties get benefits from it? Are the development models and support terms structured in a way that facilitates that? Even if we assume an answer of "yes" for all of those things and RHEL is pursuing it, that doesn't mean Fedora cannot or should not, right? josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 09:29:31PM +, Zbigniew Jędrzejewski-Szmek wrote: > The answer is "a lot". I don't think we have any hard numbers, but > see https://pagure.io/fesco/issue/1935. Generally, it seems we can't > process the CVEs we get now. > "This result was limited to 1000 bugs." → that's just for CVEs. What happens if we limit that to a smaller subset, though? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 12:37:46PM -0500, John Florian wrote: > On 11/14/18 10:36 AM, mcatanz...@gnome.org wrote: > >We need to rebase GNOME within about two months of the new > >upstream releases, or we'll lose our edge with the GNOME > >community. We'd be ceding our position as best GNOME distro to > >Ubuntu and Arch. > > It seems wrong that a DE, even if it's the default, has so much sway > over the distro as a whole. It's not just gnome. It's also gcc, glibc, boost, systemd, python, and any other project which cannot be upgraded easily mid-cycle. Having a chance to push a new version every six months is much better than waiting a year. > >So a one-year cycle means a major GNOME version update will need > >to land in the middle of a release to avoid that. And these do not > >have a good reputation for stability. Basically we'll wind up with > >a bunch of bugs landing halfway through the release, and without > >the usual Fedora QA process to ensure the most important of them > >get fixed before they reach users. > > Why can't GNOME be updated mid-release like any other application? > Why does the QA process require the cadence of the whole distro > release process to bend to GNOME? Can't a major GNOME update land > in the testing repos to have QA issues sorted out there just as well > as in some alpha/beta release of the overall Fedora? For me, any discussions about .1 or .5 completely miss the point. The numbering does not matter at all, the freeze and the testing and bugfixing matters. If we do it every 6 months, we might just as well call this a new release each time. As mentioned elsewhere in this thread, we have plenty of technical issues to solve, including security bugs and whatnot. Let's not get distracted by numbering. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 11:11:59AM -0700, Ken Dreyer wrote: > On Tue, Nov 13, 2018 at 4:37 PM Matthew Miller > wrote: > > But there are some good cases for a longer lifecycle. For one thing, > > this has been a really big blocker for getting Fedora shipped on > > hardware. > > This is an interesting topic to me because I recently toured the > System76 factory here in Denver. They are engineering their own > operating system (Pop!_OS) on top of Ubuntu, and I would love to see > Fedora become more viable as a base in these types of situations. > > We have a lot of data stored in Bodhi. I've wondered about mining the > security update data in particular to discover: > > A) How many security updates that we push that would have affected > older versions of Fedora, over time? In other words, based on the > Fedora 28 data, how many security updates does Fedora 27 lack 3 months > past its EOL? 6 months? 12 months? That would give a rough scope of > the security situation and level of effort. The answer is "a lot". I don't think we have any hard numbers, but see https://pagure.io/fesco/issue/1935. Generally, it seems we can't process the CVEs we get now. "This result was limited to 1000 bugs." → that's just for CVEs. > B) Is it possible to "mock rebuild" those security updates' SRPMs for > the EOL Fedora releases? How much harder does it get over time? This > could be a semi-automated way to experiment with extending the > lifecycle of older Fedoras. > > Obviously this is not perfect, but I imagine that solely focusing on > security updates could help extend the lifecycle from 13 months to > maybe 25 months. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
Ben Rosser (rosser@gmail.com) said: > On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen wrote: > > From what I have talked with in the past.. 3 years is their bare > > minimum and 7 is their what we really want. It usually takes the > > vendor about 3-6 months of work to make sure the OS works on their > > hardware without major problems and then they want people to buy > > support contracts for 3-5 years where the number of problems needed in > > year 3-5 are none. [This means that they want to have Fedora N for 3-6 > > months before their laptops ship with it. So you ship them a frozen > > preload before you release to public. They also want any shipped to > > 'last' for the warranty cycle because trying to deal with update > > questions when N eol's in the middle costs them a lot.] > > If 7 years is what manufacturers really want, then it sounds like > CentOS is much better positioned to be get shipped on laptops than > Fedora. Instead of working on a new "Fedora LTS" for this usage case, > would time be better spent improving EPEL and CentOS for the > desktop/laptop use case? I'd always thought of CentOS/RHEL as "Fedora > LTS" anyway, to be honest. The point of a Fedora LTS for these manufacturers, if it were to exist, is to give them a channel to partner with, work on support with, and a software base they can get needed changes into. AFAIK, CentOS isn't set up to accept changes (into the base repo) or provide that level of support. And if they wanted to do it with Red Hat at the RHEL level... presumably they would already be doing so. Bill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen wrote: > From what I have talked with in the past.. 3 years is their bare > minimum and 7 is their what we really want. It usually takes the > vendor about 3-6 months of work to make sure the OS works on their > hardware without major problems and then they want people to buy > support contracts for 3-5 years where the number of problems needed in > year 3-5 are none. [This means that they want to have Fedora N for 3-6 > months before their laptops ship with it. So you ship them a frozen > preload before you release to public. They also want any shipped to > 'last' for the warranty cycle because trying to deal with update > questions when N eol's in the middle costs them a lot.] If 7 years is what manufacturers really want, then it sounds like CentOS is much better positioned to be get shipped on laptops than Fedora. Instead of working on a new "Fedora LTS" for this usage case, would time be better spent improving EPEL and CentOS for the desktop/laptop use case? I'd always thought of CentOS/RHEL as "Fedora LTS" anyway, to be honest. Ben Rosser ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Container updates available in bodhi
Dear all, It is now possible to use bodhi to release a new container build. Currently it is following the same flow as packages. After a successful OSBS build, a bodhi update can be created. Fedpkg does not yet support creating updates for containers [0], so you have to either use bodhi web UI or the bodhi cli. For example bodhi updates new --type enhancement --notes "cockpit update to version 181-2" cockpit-181-2.fc29 Once the update is pushed to testing, the container will be available in the registry with the testing tag podman pull registry.fedoraproject.org/f29/cockpit:testing Then the container latest tag will be pushed to registry.fedoraproject.org, if it receives +3 karma or waits 7 days in testing. Thanks [0] - https://pagure.io/fedpkg/issue/296 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On 11/14/18 12:36 AM, Matthew Miller wrote: > > So, what would this look like? I have some ideas, but, really, there > are many possibilities. That's what this thread is for. Let's figure it > out. How would we structure repositories? How would we make sure we're > not overworked? How would we balance this with getting people new stuff > fast as well? > I know that 13 month for hardware vendors is quite short. Some of them have processes for approving minor updates that take 6 month or longer. We don't talk about a new kernel update here, we really talk about a simple update of a client application in the IoT world. So good so far, it makes sense that they are quite unhappy with Fedora 13 month release cycles. At the same time, one of the main reasons I use fedora is because updates are so smooth in the recent releases. I think that's something we can bring to IoT devices as well. With ostree and the newer ways of upgrading systems it's definitely possible to upgrade software quite fail safe. I would go for one more release cycle that is supported (18-19 months) instead of going for full LTS. Since LTS is really something I think CentOS and RHEL should do. 10 years is LTS. 36 month is only half way, and when we want IoT devices to become more secure in the long term, I think we should work on making them safer and easier to update instead of setting up an LTS which then causes ugly breaking during upgrades which we see on Ubuntu and other places. At least that's my experience and why I would like to avoid an LTS life cycle. And 36 or 48 months are quite short for IoT (think about the toaster you bought. How old is it?) but quite long in the world of software. And for Vendors of notebooks and desktops, I think the upgrade process is ready to work for end users. Especially on defaults. When we look here to Windows, with Windows 10 they do exactly that. Providing a Release that lasts 6 month (+ something for business) and then is updated. We do this for 15 years now and quite smooth, so why change? 13 months are completely fine for a desktop. Finally people. We have resource, but not an infinite number of them. We have so many projects we are working on and right now automatic various of our existing projects already takes so much work time that adding more release cycles would only make it harder. Especially with back porting all the fixes to the then LTS. And besides that I guess most people who want an LTS outside of the IoT world, would go for CentOS anyway. So may let's see if we can bring CentOS and RHEL towards IoT instead of bringing CentOS and RHEL to Fedora. I hope/guess the way for the latter is way shorter. -- Signed Sheogorath signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Dec 2018 Fedora Elections: Nomination & Campaign period is open
Today we are starting the Nomination & Campaign period during which we accept nominations to the "steering bodies" of the following teams: * FESCo (Engineering) (5 seats) [1] * Fedora Council (1 seat) [2] * Mindshare (1 seat) [3] This period is open until 2018-Nov-28 at 23:59:59 UTC. Candidates may self-nominate. If you nominate someone else, please check with them to ensure that they are willing to be nominated before submitting their name. The nominees can already start preparing their answers for questions in the Election Questionnaire. The questions can be found in the template files[4]. Nominees submit their questionnaire answers via a private Pagure issue[5]. The Election Wrangler or their backup will publish the interviews to the Community Blog [6] a day before the start of the Voting period (2018-Dec-06). Please note that the interview is mandatory for all nominees. Nominees not having their interview ready by end of the Interview period (2018-Dec-05) will be disqualified and removed from the election. Nominees may submit their interview answers immediately and may edit them until the end of the interview period. Nominees are encouraged to begin their interview answers as soon as they accept their nomination. As part of the Campaign people might also ask questions to specific candidates on @devel mailing list, if they want. The full schedule of the December 2018 Elections is available on the Elections schedule[7]. [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations [2] https://fedoraproject.org/wiki/Council/Nominations [3] https://fedoraproject.org/wiki/Mindshare/Nominations [4] https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-December [5] https://pagure.io/fedora-project-schedule/issues [6] http://communityblog.fedoraproject.org/ [7] https://fedorapeople.org/groups/schedule/f-29/f-29-elections.html -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, 14 Nov 2018 at 11:45, wrote: > > On Tue, Nov 13, 2018 at 5:36 PM, Matthew Miller > wrote: > > But there are some good cases for a longer lifecycle. For one thing, this has > been a really big blocker for getting Fedora shipped on hardware. Second, > there are people who really could be happily running Fedora but since we > don't check the tickbox, they don't even look at us seriously. I'd love to > change these things. To do that, we need something that lasts for 36-48 > months. > > > Is 36 months an absolute minimum for getting onto consumer laptops? > > Don't underestimate the difficulty of adding an extra year. 48 months is a > *lot* harder than 36. 36 is a lot harder than 24 or 27 (2 years plus 3 month > upgrade window). > From what I have talked with in the past.. 3 years is their bare minimum and 7 is their what we really want. It usually takes the vendor about 3-6 months of work to make sure the OS works on their hardware without major problems and then they want people to buy support contracts for 3-5 years where the number of problems needed in year 3-5 are none. [This means that they want to have Fedora N for 3-6 months before their laptops ship with it. So you ship them a frozen preload before you release to public. They also want any shipped to 'last' for the warranty cycle because trying to deal with update questions when N eol's in the middle costs them a lot.] This matches the majority of laptop buyers whether they are developers or home users. They cycle a laptop 4 to 5 years with 7-8 looking to be the new average. They also don't update their OS unless it does it auto-magically for them. This is where the majority of profits for laptop sales come from so the manufacturers aim to please this segment most. There isn't a large margin on laptop sales anymore -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
Je mer, 2018-11-14 je 18:34 +0100, Kevin Kofler skribis: > > That is what make us different distro with its own user base. Want the > > very same but LTS system? try CentOS. Or RHEL. > > +1. LTS Fedora is what CentOS is for. Why should we not just point users who > want LTS to CentOS and EPEL? Crazy idea: Would it be possible to integrate CentOS into the Fedora fold? I am not intimately familiar with the relation between CentOS and Fedora, but I can see two radical(!) changes that would address this topic: - Completely absorb CentOS into Fedora. Every nth Fedora release becomes the equivalent of a CentOS release, and will be supported for a long time. - Keep everything approximately the same, but rename CentOS to "Fedora LTS". I agree otherwise, though. Creating Fedora LTS seems like an effort in futility when CentOS exists as a close enough approximation. Best regards, Carmen signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Tue, Nov 13, 2018 at 4:37 PM Matthew Miller wrote: > But there are some good cases for a longer lifecycle. For one thing, > this has been a really big blocker for getting Fedora shipped on > hardware. This is an interesting topic to me because I recently toured the System76 factory here in Denver. They are engineering their own operating system (Pop!_OS) on top of Ubuntu, and I would love to see Fedora become more viable as a base in these types of situations. We have a lot of data stored in Bodhi. I've wondered about mining the security update data in particular to discover: A) How many security updates that we push that would have affected older versions of Fedora, over time? In other words, based on the Fedora 28 data, how many security updates does Fedora 27 lack 3 months past its EOL? 6 months? 12 months? That would give a rough scope of the security situation and level of effort. B) Is it possible to "mock rebuild" those security updates' SRPMs for the EOL Fedora releases? How much harder does it get over time? This could be a semi-automated way to experiment with extending the lifecycle of older Fedoras. Obviously this is not perfect, but I imagine that solely focusing on security updates could help extend the lifecycle from 13 months to maybe 25 months. - Ken ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
I think different people want different things from an LTS though. CentOS makes it hard to do e.g. Postgres 10 and Python3 which Ubuntu ships out of the box in 1804. Modularity seems like it will help in this regard. > On Nov 14, 2018, at 11:39 AM, Kevin Kofler wrote: > > Ralf Corsepius wrote: >> This would be my proposal, also. I would simply extend the release >> cycles to 1 year and to return to the roots. I.e. make a distro, and >> drop "rings" "modules" and "spins". > > Rings and modules should go away indeed, but spins should not! We have had > spins since Fedora 7! They are part of the success story of Fedora. > > What should be dropped, though, is the artificial distinction between > "editions" and "spins". Everything should be an equally-featured spin, and > the GNOME spin should be called GNOME spin. > >Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 06:11:48PM +0100, Iñaki Ucar wrote: > > Mostly blue sky -- let's generate ideas! -- but let's also stay within > > reasonable possibilities, and also, you know, keeping it Fedora. > > Particularly, I'm pretty sure about the goals: 1. getting Fedora desktop and > > IoT shipped on systems and 2. expanding the community by getting Fedora into > > places which don't consider us because we're perceived as too fleeting. > > Why not make just IoT LTS? That's a possibility. How would we do that? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
I concur. This is effectively what I was trying to express with respect to the distinctions. On November 14, 2018 12:39:40 PM EST, Kevin Kofler wrote: >Ralf Corsepius wrote: >> This would be my proposal, also. I would simply extend the release >> cycles to 1 year and to return to the roots. I.e. make a distro, and >> drop "rings" "modules" and "spins". > >Rings and modules should go away indeed, but spins should not! We have >had >spins since Fedora 7! They are part of the success story of Fedora. > >What should be dropped, though, is the artificial distinction between >"editions" and "spins". Everything should be an equally-featured spin, >and >the GNOME spin should be called GNOME spin. > >Kevin Kofler >___ >devel mailing list -- devel@lists.fedoraproject.org >To unsubscribe send an email to devel-le...@lists.fedoraproject.org >Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >List Archives: >https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- John___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
Ralf Corsepius wrote: > This would be my proposal, also. I would simply extend the release > cycles to 1 year and to return to the roots. I.e. make a distro, and > drop "rings" "modules" and "spins". Rings and modules should go away indeed, but spins should not! We have had spins since Fedora 7! They are part of the success story of Fedora. What should be dropped, though, is the artificial distinction between "editions" and "spins". Everything should be an equally-featured spin, and the GNOME spin should be called GNOME spin. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On 11/14/18 10:36 AM, mcatanz...@gnome.org wrote: We need to rebase GNOME within about two months of the new upstream releases, or we'll lose our edge with the GNOME community. We'd be ceding our position as best GNOME distro to Ubuntu and Arch. It seems wrong that a DE, even if it's the default, has so much sway over the distro as a whole. I use Fedora for so much more than a desktop. Admittedly, I've never been a big fan of spins and would much prefer to see all DEs and other spin-like things just be more rpms I can install, if I choose ... all on top of a single base OS. So a one-year cycle means a major GNOME version update will need to land in the middle of a release to avoid that. And these do not have a good reputation for stability. Basically we'll wind up with a bunch of bugs landing halfway through the release, and without the usual Fedora QA process to ensure the most important of them get fixed before they reach users. Why can't GNOME be updated mid-release like any other application? Why does the QA process require the cadence of the whole distro release process to bend to GNOME? Can't a major GNOME update land in the testing repos to have QA issues sorted out there just as well as in some alpha/beta release of the overall Fedora? I would think that the distro release cadence only have hard limits set by things like the kernel and glibc. I'm probably taking an entirely too simple view of the overall process and am not attacking GNOME specifically, but just as an example given your comment. I'm just genuinely trying to understand the reasoning behind it and see if those assumptions cannot be changed. I'd love to see Fedora move to a one year release, but with a 6 month upgrade period (N and N-1 for 6 months vs the present N, N-1 and N-2 for 1 month). I'd think that would mean less work for maintainers and provide nearly the same or better benefit to users as what we have now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
Michal Schorm wrote: > We, as a distro, just take a different approach. > To be bleeding edge requires to have releases often. > > That allow us to manage changes like GCC, OpenSSL and so on quickly. > Struggling with upstream who don't adapt, can't adapt or don't want to > adapt at the same speed. (And OpenSSL patch isn't something you'd want > to write for serveral pojects you maintain ...) > > That is what make us different distro with its own user base. Want the > very same but LTS system? try CentOS. Or RHEL. +1. LTS Fedora is what CentOS is for. Why should we not just point users who want LTS to CentOS and EPEL? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla
On Wed, Nov 14, 2018 at 11:44 AM Randy Barlow wrote: > On Wed, 2018-11-14 at 11:56 +0100, Igor Gnatenko wrote: > > > > > This was not approved - there was a -1 vote and so it was > > > > > planned to be > > > > > discussed in the next meeting. > > > > > > > > I commented the ticket, but I will copy my response here: there > > > > was no > > > > single -1 within a week after opening a ticket so to my knowledge > > > > the > > > > ticket was approved. > > > > * The ticket had formal proposal offered (means that FESCo members > > can vote) > > * 6 FESCo members voted +1 within a week (which means that there were > > at least three "for" votes and no "against" votes) > > > > Considering 2 points above -- I can read that it is approved. Waiting > > for anyone to put note that it is approved is nice, but not must. If > > the policy is somehow different from what I have read, please update > > docs.fp.o and announce it. > > I suppose that's a fair interpretation of the wording in the policy, > though it wasn't my personal interpretation based off of memory. I > think I would generally prefer that people wait for the ticket to > officially say it's approved, but you are right that the policy doesn't > explicitly state that. > > In any case, fair enough, I retract my claim that it wasn't approved ☺ > For the record, your memory is faulty. When we reworked the policy, we made it explicit that once it passed that week, if it had at least +3 and no -1 votes, it was approved. This was to avoid FESCo's classic problem of taking forever to reach a decision on things. After that point, it's pending an *announcement*, but the ruling is official. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, 14 Nov 2018 at 15:25, Matthew Miller wrote: > > Mostly blue sky -- let's generate ideas! -- but let's also stay within > reasonable possibilities, and also, you know, keeping it Fedora. > Particularly, I'm pretty sure about the goals: 1. getting Fedora desktop and > IoT shipped on systems and 2. expanding the community by getting Fedora into > places which don't consider us because we're perceived as too fleeting. Why not make just IoT LTS? -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 10:41:17AM -0600, mcatanz...@gnome.org wrote: > It's a possibility... I'd rather call it .5 for halfway, though. > F30, F30.5, F31... ehh, it would be OK, but there should be real > concrete gain if we do this. It gets us no closer to a 36 month > lifetime. Well, it would reduce the number of active streams, and make the QA effort be a subset of full-release QA. Alternately, GNOME could switch to a yearly release cycle for our convenience. :) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla
On Mon, 12 Nov 2018 at 15:35, Jaroslav Mracek wrote: > > Hello everyone, > > There was an announcement of release libsolv-0.7.0 ([HEADS UP] libsolv 0.7) > into rawhide, but the rebase also ended up in stable branches of Fedora 28 > and 29. This release could affect not only libsolv users, but also libdnf, > PackageKit, microdnf, or dnf related applications. > I would like to ask everyone for intensive testing and reporting any issues > concerning the rebase. > > Thanks a lot for your help What risk does this present for dnf upgrades from F28 to F29? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla
On Wed, 2018-11-14 at 11:56 +0100, Igor Gnatenko wrote: > > > > This was not approved - there was a -1 vote and so it was > > > > planned to be > > > > discussed in the next meeting. > > > > > > I commented the ticket, but I will copy my response here: there > > > was no > > > single -1 within a week after opening a ticket so to my knowledge > > > the > > > ticket was approved. > > * The ticket had formal proposal offered (means that FESCo members > can vote) > * 6 FESCo members voted +1 within a week (which means that there were > at least three "for" votes and no "against" votes) > > Considering 2 points above -- I can read that it is approved. Waiting > for anyone to put note that it is approved is nice, but not must. If > the policy is somehow different from what I have read, please update > docs.fp.o and announce it. I suppose that's a fair interpretation of the wording in the policy, though it wasn't my personal interpretation based off of memory. I think I would generally prefer that people wait for the ticket to officially say it's approved, but you are right that the policy doesn't explicitly state that. In any case, fair enough, I retract my claim that it wasn't approved ☺ signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 10:31 AM, Matthew Miller wrote: Is there a way we could do these as ".1" releases, with orchestrated QA for the big update rather than a whole release? It's a possibility... I'd rather call it .5 for halfway, though. F30, F30.5, F31... ehh, it would be OK, but there should be real concrete gain if we do this. It gets us no closer to a 36 month lifetime. Or, if we can combine this with having a gated Rawhide meant for day-to-day use (and using ostree for rollbacks), would that be adequate for the "on the edge" GNOME community? No, even I wouldn't use it. I like having a stable desktop. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
Thanks for starting this discussion, Matthew! A few notes: * My personal long-term dream is that all Fedora users are running Silverblue, we do great automated QA testing, and upgrading from one Fedora to the next is a non-event, and opt-out rather than opt-in, and long term support would not be needed. We aren't there yet. :-) * If we have a long-term support branch, the stuff that's in the default install / the stuff that would be in a Silverblue image - should be rebased very sparingly. I think we'd have to define this set - it's bigger than the current "critical path". * As we move higher up the stack, it's more reasonable for maintainers to take an approach of maintaining a single version across active Fedora branches - and we have various mechanism to make that easier: packages.cfg, module stream expansion, Flatpaks. * The kernel is a big question mark - our kernel maintenance strategy really *assumes* that we can aggressively rebase, but if the Fedora project is working with a hardware vendor, the kernel is the component that the hardware vendor is probably going to be squeamish about. Not sure what the solution here is - sync to a LTS kernel? Presumably part of Fedora working with hardware vendors would be figuring a good testing strategy so that updates get testing on the actual hardware before going out. * If we are offering a long term branch as a strategy to work with hardware vendors, what happens when users *choose* to upgrade to a newer stable Fedora? - Owen On Tue, Nov 13, 2018 at 6:37 PM Matthew Miller wrote: > > > Hi everyone! Let's talk about something new and exciting. Since its > first release fifteen years ago, Fedora has had a 13-month lifecycle > (give or take). That works awesomely for many cases (like, hey, we're > all here), but not for everyone. Let's talk about how we might address > some of the users and use cases we're missing out on. > > When I talk to people about this, I often get "hey, you should do LTS > or go to rolling releases.” As I've said before, on the surface that's > a weird thing to say, since the actual user impact of those two > different things is mostly _opposite_. So, digging in, it often really > means "I don't want the pain and fear of big OS upgrades". > > We've addressed that in several ways: first, making upgrades better. > (Thanks everyone who has worked on that.) A Fedora release-to-release > update is normally not much more trouble than you might get some random > Tuesday with a rolling release. Second, we have some things like Fedora > Atomic Host and upcoming Fedora CoreOS and IoT which both implement a > rolling stream on top of the Fedora release base. And finally, there's > the coming-someday plans for gating Rawhide, making that a better > proposition for people who really want to live on the edge. > > But there are some good cases for a longer lifecycle. For one thing, > this has been a really big blocker for getting Fedora shipped on > hardware. Second, there are people who really could be happily running > Fedora but since we don't check the tickbox, they don't even look at us > seriously. I'd love to change these things. To do that, we need > something that lasts for 36-48 months. > > So, what would this look like? I have some ideas, but, really, there > are many possibilities. That's what this thread is for. Let's figure it > out. How would we structure repositories? How would we make sure we're > not overworked? How would we balance this with getting people new stuff > fast as well? > > > > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 09:54:27AM -0600, mcatanz...@gnome.org wrote: > Is 36 months an absolute minimum for getting onto consumer laptops? Based on the conversations I've had, yes. We might be able to get some niche acceptance with 27 months. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 09:36:01AM -0600, mcatanz...@gnome.org wrote: > We need to rebase GNOME within about two months of the new upstream > releases, or we'll lose our edge with the GNOME community. We'd be > ceding our position as best GNOME distro to Ubuntu and Arch. So a > one-year cycle means a major GNOME version update will need to land > in the middle of a release to avoid that. And these do not have a > good reputation for stability. Basically we'll wind up with a bunch > of bugs landing halfway through the release, and without the usual > Fedora QA process to ensure the most important of them get fixed > before they reach users. So I can't support this plan Is there a way we could do these as ".1" releases, with orchestrated QA for the big update rather than a whole release? Or, if we can combine this with having a gated Rawhide meant for day-to-day use (and using ostree for rollbacks), would that be adequate for the "on the edge" GNOME community? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Tue, Nov 13, 2018 at 5:36 PM, Matthew Miller wrote: But there are some good cases for a longer lifecycle. For one thing, this has been a really big blocker for getting Fedora shipped on hardware. Second, there are people who really could be happily running Fedora but since we don't check the tickbox, they don't even look at us seriously. I'd love to change these things. To do that, we need something that lasts for 36-48 months. Is 36 months an absolute minimum for getting onto consumer laptops? Don't underestimate the difficulty of adding an extra year. 48 months is a *lot* harder than 36. 36 is a lot harder than 24 or 27 (2 years plus 3 month upgrade window). Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 04:29:22PM +0100, Ralf Corsepius wrote: > On 11/14/18 4:08 PM, Gerald Henriksen wrote: > > On Wed, 14 Nov 2018 06:12:11 +0100, you wrote: > > > > > We, as a distro, just take a different approach. > > > To be bleeding edge requires to have releases often. > > > > Such a bleeding edge distro that it took 4 years for Swift to arrive, > > or still trying to get rid of Python 2. > > Fedora has become "bleeding edge" in sense of being unstable, unreliable and > containing immature, experimental features. IME the opposite has happened - I see far less instability and breakage when upgrading to a new Fedora release these days, than experienced in the past. Even rawhide doesn't destroy systems as frequently as it did in the past. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 9:29 AM, Ralf Corsepius wrote: Absolutely. Fedora once was a pretty solid end-user distro and fun-project for devs. Now it has become an unstable, experimental "bleeding edge" distro with a more and more balloning overhead. I don't agree at all. Fedora is great. We have tons of compliments from users in places like /r/Fedora and /r/GNOME praising how stable Fedora is. We have by far the most developers working on the distro, thanks to Red Hat. And our QA process -- blocker bugs and freeze exceptions -- is second to none, and ensures we have the highest-quality product of any comparable distro on release day. What we have is a reputation management issue. This reputation that Fedora is bleeding edge or a testbed for RHEL is pervasive, and we need to find some way to kill it. Another issue is that our updates QA remains insufficient: broken updates are able to reach users before they can be detected and pulled, defeating the benefit of all that release day QA. Subjectively, this situation feels better nowadays than it used to be. But we still had a big problem with the recent broken mesa and GCC updates, for example. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 9:08 AM, Gerald Henriksen wrote: My feeling is part of the solution is to move to a yearly release cycle. Unlike the early days of Fedora things just aren't changing as quick in terms of the base of the OS - hardware support in the kernel is generally excellent, and both Gnome and KDE (and likely the others) are mature environments that while they improve with each release there isn't generally anything that says a 6 month wait would be unbearable - and consideration should also be done to the track record that given the overall stability of those desktops that upgrades can likely be done safely mid-Fedora-release. We need to rebase GNOME within about two months of the new upstream releases, or we'll lose our edge with the GNOME community. We'd be ceding our position as best GNOME distro to Ubuntu and Arch. So a one-year cycle means a major GNOME version update will need to land in the middle of a release to avoid that. And these do not have a good reputation for stability. Basically we'll wind up with a bunch of bugs landing halfway through the release, and without the usual Fedora QA process to ensure the most important of them get fixed before they reach users. So I can't support this plan Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On 11/14/18 4:08 PM, Gerald Henriksen wrote: On Wed, 14 Nov 2018 06:12:11 +0100, you wrote: We, as a distro, just take a different approach. To be bleeding edge requires to have releases often. Such a bleeding edge distro that it took 4 years for Swift to arrive, or still trying to get rid of Python 2. Fedora has become "bleeding edge" in sense of being unstable, unreliable and containing immature, experimental features. Regardless of what we think Fedora is or isn't, a look outside of Fedora shows an overall Linux community that appears to be increasingly ignoring Fedora. Absolutely. Fedora once was a pretty solid end-user distro and fun-project for devs. Now it has become an unstable, experimental "bleeding edge" distro with a more and more balloning overhead. Part of this discussion needs to be around the combined issues of getting more maintainers and getting more users. My feeling is part of the solution is to move to a yearly release cycle. This would be my proposal, also. I would simply extend the release cycles to 1 year and to return to the roots. I.e. make a distro, and drop "rings" "modules" and "spins". Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, 14 Nov 2018 06:12:11 +0100, you wrote: >We, as a distro, just take a different approach. >To be bleeding edge requires to have releases often. Such a bleeding edge distro that it took 4 years for Swift to arrive, or still trying to get rid of Python 2. Regardless of what we think Fedora is or isn't, a look outside of Fedora shows an overall Linux community that appears to be increasingly ignoring Fedora. Part of this discussion needs to be around the combined issues of getting more maintainers and getting more users. My feeling is part of the solution is to move to a yearly release cycle. Unlike the early days of Fedora things just aren't changing as quick in terms of the base of the OS - hardware support in the kernel is generally excellent, and both Gnome and KDE (and likely the others) are mature environments that while they improve with each release there isn't generally anything that says a 6 month wait would be unbearable - and consideration should also be done to the track record that given the overall stability of those desktops that upgrades can likely be done safely mid-Fedora-release. So perhaps then you go with 2 effective releases of Fedora - a one year release, and a 3 year release. You get the benefits for those that need it of a LTS style product, reduce the upgrade churn that is putting off some prospective users. Won't satisfy everyone but it may be an improvement. Anything that really can't wait for a next release could be temporarily thrown into COPR, with perhaps a feature that at the next major release the COPR repository automatically gets removed as the package is now available from the main Fedora repository. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 01:58:13PM +, Zbigniew Jędrzejewski-Szmek wrote: > Because each old version is different? The fact that a backport has > been made for RHEL does not mean that this backport is appropriate for > the given Fedora version. Iff this was so simple, we could just take > CentOS packages and compile them for Fedora. Well, in a lot of cases, we *could*. > In my experience, backporting even to older version of Fedora is > proportional to the number of branches. This is because the diff between > F-2 and F-1 is just as large (on average) as the diff between F-1 and F. Yeah, definitely. We can't do this in a way which significantly increases the number of active branches. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 08:36:46AM -0500, Matthew Miller wrote: > On Wed, Nov 14, 2018 at 06:12:11AM +0100, Michal Schorm wrote: > > We, as a distro, just take a different approach. > > To be bleeding edge requires to have releases often. > > But being "bleeding edge" has never been what Fedora's about, despite > getting that epithet slapped at us. Yes, we want innovation and new > software, but we also want software which *works*. We want to provide a > consistent, pleasant, and functional user experience, without getting > metaphorical blood all over. > > > [...] > > What I wanted to express by this message is the fact, prolonging > > software support time in Fedora means *a lot* of low-level work TBD. > > I can maintain it either "bleeding edge style", geting users new > > features literally ASAP, or "LTS style" defend the database from any > > update to not break anything, bugfix and security fix only. (I'm doing > > it for RHEL after all). > > But not both. > > Lots of good feedback, but I want to focus on this last comment. > > It sounds like you are actually already doing both approaches -- the fast > branch for Fedora and a slower, RH-internal branch for RHEL. What if you > made that slower branch *also* in Fedora as a direct upstream for your > internal RHEL work? Fedora is supposed to be the upstream for RHEL, after > all. Why not make that true all of the time, not just every N years when > RHEL branches? Because each old version is different? The fact that a backport has been made for RHEL does not mean that this backport is appropriate for the given Fedora version. Iff this was so simple, we could just take CentOS packages and compile them for Fedora. In my experience, backporting even to older version of Fedora is proportional to the number of branches. This is because the diff between F-2 and F-1 is just as large (on average) as the diff between F-1 and F. (That was the technical consideration. There's also the social side: working on new&shiny that you use yourself is fun, doing the same for old and stable versions is a job.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, 14 Nov 2018 at 11:26, Daniel P. Berrangé wrote: > It is not so much whether we "care", but rather whether we have enough > time in the day to get the expected work done. I can't magic up more > time to work no matter how much I care to. Exactly my situation too. Richard. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 07:54:24AM -0500, Neal Gompa wrote: > > If we reduce the non-LTS supported time from 13 months to, let's say, 7 > > months (2 months overlap to allow for time to upgrade) then perhaps it > > could work? And then add a LTS branch that's supported for 3 years? We'd > > have the same number of branches as now, just that one is LTS. > That's basically the Ubuntu model. They do 9 months for regular > releases, and 5 years (originally 3 years) for LTS releases. > > However, what could also work would be something along the lines of > openSUSE Evergreen[1] model (prior to the shift to openSUSE Leap + > Tumbleweed), where the community decides on a version to stabilize and > maintain for bugfixes for an extended period of time. If we wanted to > talk about having extended lifecycles, I think this would be a > workable model. This would be similar to the original Fedora Legacy > project (if anyone remembers that!). > > [1]: https://en.opensuse.org/openSUSE:Evergreen Yeah I came into Fedora through the Legacy project. :) There are also ideas from Tom Callaway's proposal from FUDCon Lawrence: a major release every two years, followed by point updates. Kind of like RHL back in the day. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: could Fedora please reverse its policy re End-Of-Life
The update frequency is twice a year, the method is fully documented: https://fedoraproject.org/wiki/DNF_system_upgrade Simply refresh, download, reboot and wait a little while ... It's hardly a burden, I've got at least 5 machines that have been upgraded this way since Fedora 13. Op wo 14 nov. 2018 om 13:19 schreef Miroslav Suchý : > > Dne 14. 11. 18 v 2:23 steve schooler napsal(a): > > I recognize that since Fedora is FREE, the developers face an enormous > > burden. However, I suspect that many will feel as I do that it is an > > onerous user-burden to have to frequently upgrade/re-install. Further, > > forum-technical-support, regardless of how timely and incisive, doesn't > > compensate for the user-burden. > > This is the core issue. We only have a limited manpower. You have three > things to choose from: free of charge > distribution, long support, fresh versions of SW in distribution - but we can > only choose two of them. > Fedora chose free and fresh versions. > > If you want long support, you can always choose CentOS, which is based on > Fedora. However, you are loosing the "fresh > versions". > > AFAIK no one at a market is offering all three at once. > > Miroslav > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 06:12:11AM +0100, Michal Schorm wrote: > We, as a distro, just take a different approach. > To be bleeding edge requires to have releases often. But being "bleeding edge" has never been what Fedora's about, despite getting that epithet slapped at us. Yes, we want innovation and new software, but we also want software which *works*. We want to provide a consistent, pleasant, and functional user experience, without getting metaphorical blood all over. [...] > What I wanted to express by this message is the fact, prolonging > software support time in Fedora means *a lot* of low-level work TBD. > I can maintain it either "bleeding edge style", geting users new > features literally ASAP, or "LTS style" defend the database from any > update to not break anything, bugfix and security fix only. (I'm doing > it for RHEL after all). > But not both. Lots of good feedback, but I want to focus on this last comment. It sounds like you are actually already doing both approaches -- the fast branch for Fedora and a slower, RH-internal branch for RHEL. What if you made that slower branch *also* in Fedora as a direct upstream for your internal RHEL work? Fedora is supposed to be the upstream for RHEL, after all. Why not make that true all of the time, not just every N years when RHEL branches? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: could Fedora please reverse its policy re End-Of-Life
On Wed, Nov 14, 2018 at 02:26:09PM +0100, Carmen Bianca Bakker wrote: > Je mer, 2018-11-14 je 12:28 +0100, Miroslav Suchý skribis: > > This is the core issue. We only have a limited manpower. You have three > > things to choose from: free of charge > > distribution, long support, fresh versions of SW in distribution - but we > > can only choose two of them. > > > > [...] > > > > AFAIK no one at a market is offering all three at once. > > You could possibly argue that rolling releases offer this, but they are > a different beast entirely. Nah, "rolling" is the very opposite of LTS. You just keep upgrading more often. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 12:32:14PM +0100, Adam Samalik wrote: > Do we have any user data about what "stability" means to users and on what > different levels that can be achieved? Is it about app versions such as > MariaDB? is it about language runtime versions such as Node.js? is it about > things like glibc? or kernel? Or does it need to be the whole distro as we > have it today? > > In case we don't find a uniform solution that would fit all those cases (== > for the whole release as we know it today), focusing on those specific > levels (modules? rings?! ;) ) might help with different approaches could > help us at least a little bit. Well, considering there are some. I'm thinking mostly about a base platform. And even there, I think kernel versions and such can change -- we don't need a RHEL-style kernel ABI promise. We just need changes there to not break 1) the hardware it runs on and 2) the stuff on top. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 09:27:39AM -, Leigh Scott wrote: > > out. How would we structure repositories? How would we make sure we're > > not overworked? How would we balance this with getting people new stuff > > fast as well? > I'm already overworked supporting old releases for the current 13 months, > most of my time is spent on fedora next. I think any workable answer is going to need some sort of Rings approach that allows different cadence for deliverables on top. Cinnamon, for example, could be in Ring 2 and deliver a faster-moving experience. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Tue, Nov 13, 2018 at 08:05:54PM -0500, Stephen John Smoogen wrote: > > But there are some good cases for a longer lifecycle. For one thing, > > this has been a really big blocker for getting Fedora shipped on > > hardware. Second, there are people who really could be happily running > > Fedora but since we don't check the tickbox, they don't even look at us > > seriously. I'd love to change these things. To do that, we need > > something that lasts for 36-48 months. [...] > There are a lot of possibilities, but it is also that "something that > lasts for 36-48 months" probably means something different to everyone > involved. > > To some set it means "Whatever was shipped on Day0 had only better get > backported fixes and maybe, maybe minor updates", to others it means > "well it shouldn't have any major api/abi updates in those 36-48 > months.. " to the "so this just means it should be a rolling update as > long as everything always works or resets easily". Is this > conversation completely blue-sky or are there boundaries we should > watch out for so we aren't arguing over "well why not make Fedora a > rebuild of Debian using a deb2rpm tool since they already are LTS" and > other people saying why not Mostly blue sky -- let's generate ideas! -- but let's also stay within reasonable possibilities, and also, you know, keeping it Fedora. Particularly, I'm pretty sure about the goals: 1. getting Fedora desktop and IoT shipped on systems and 2. expanding the community by getting Fedora into places which don't consider us because we're perceived as too fleeting. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: could Fedora please reverse its policy re End-Of-Life
Je mer, 2018-11-14 je 12:28 +0100, Miroslav Suchý skribis: > This is the core issue. We only have a limited manpower. You have three > things to choose from: free of charge > distribution, long support, fresh versions of SW in distribution - but we can > only choose two of them. > > [...] > > AFAIK no one at a market is offering all three at once. You could possibly argue that rolling releases offer this, but they are a different beast entirely. Carmen signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 7:49 AM Kalev Lember wrote: > > On 11/14/2018 11:35 AM, Daniel P. Berrangé wrote: > > If Fedora had longer life cycles, and more streams maintained in > > parallel, then I think the result would be that I end up doing > > rebases for everything I maintain rather than trying to backport > > anything. Admittedly this would somewhat negate the supposed benefit > > of having stable long life releases, but its either that or the > > releases bitrot accumulating more & more bugs & security flaws. > > I agree, this would lead to too much workload on the maintainers if we > just add a new long-lived branch. There's already rawhide, F29, F28, F27 > which is already quite a lot of branches to maintain. > > However, I think this could work if we change how long we maintain the > non-LTS branches. > > If we reduce the non-LTS supported time from 13 months to, let's say, 7 > months (2 months overlap to allow for time to upgrade) then perhaps it > could work? And then add a LTS branch that's supported for 3 years? We'd > have the same number of branches as now, just that one is LTS. > That's basically the Ubuntu model. They do 9 months for regular releases, and 5 years (originally 3 years) for LTS releases. However, what could also work would be something along the lines of openSUSE Evergreen[1] model (prior to the shift to openSUSE Leap + Tumbleweed), where the community decides on a version to stabilize and maintain for bugfixes for an extended period of time. If we wanted to talk about having extended lifecycles, I think this would be a workable model. This would be similar to the original Fedora Legacy project (if anyone remembers that!). [1]: https://en.opensuse.org/openSUSE:Evergreen -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 12:47:42PM +0100, Miroslav Suchý wrote: > Dne 14. 11. 18 v 0:36 Matthew Miller napsal(a): > > I'd love to change these things. To do that, we need > > something that lasts for 36-48 months. > > So that means we will be supporting something like Fedora 23 nowadays. That > is Firefox 41, mock 1.2, dnf 1.1.3, ruby > 2.2. systemd 222, kernel 4.2.3, qemu 2.4 ... > > Will this be useful for users? Or we will be hit by requests to rebase to a > newer version? To backport some bugfix or > feature? > > I can imagine having LTS Fedora version which will be released every three > years, but *only if* we state that only > security issues will be fixed there - and even that will be hard packages > like Firefox. And we strongly *enforce* no > rebases in this version. Enforcing "no rebases" would actually make a long life Fedora *worse* than RHEL in places. For example, RHEL rebases libvirt and qemu[1] is almost every minor update. Regards, Daniel [1] Might no be obvious to some as there's actually 2 distinct QEMU RPMs shipped, one never rebases & one always rebases. -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On 11/14/2018 11:35 AM, Daniel P. Berrangé wrote: If Fedora had longer life cycles, and more streams maintained in parallel, then I think the result would be that I end up doing rebases for everything I maintain rather than trying to backport anything. Admittedly this would somewhat negate the supposed benefit of having stable long life releases, but its either that or the releases bitrot accumulating more & more bugs & security flaws. I agree, this would lead to too much workload on the maintainers if we just add a new long-lived branch. There's already rawhide, F29, F28, F27 which is already quite a lot of branches to maintain. However, I think this could work if we change how long we maintain the non-LTS branches. If we reduce the non-LTS supported time from 13 months to, let's say, 7 months (2 months overlap to allow for time to upgrade) then perhaps it could work? And then add a LTS branch that's supported for 3 years? We'd have the same number of branches as now, just that one is LTS. -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
Dne 14. 11. 18 v 0:36 Matthew Miller napsal(a): > I'd love to change these things. To do that, we need > something that lasts for 36-48 months. So that means we will be supporting something like Fedora 23 nowadays. That is Firefox 41, mock 1.2, dnf 1.1.3, ruby 2.2. systemd 222, kernel 4.2.3, qemu 2.4 ... Will this be useful for users? Or we will be hit by requests to rebase to a newer version? To backport some bugfix or feature? I can imagine having LTS Fedora version which will be released every three years, but *only if* we state that only security issues will be fixed there - and even that will be hard packages like Firefox. And we strongly *enforce* no rebases in this version. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
Do we have any user data about what "stability" means to users and on what different levels that can be achieved? Is it about app versions such as MariaDB? is it about language runtime versions such as Node.js? is it about things like glibc? or kernel? Or does it need to be the whole distro as we have it today? In case we don't find a uniform solution that would fit all those cases (== for the whole release as we know it today), focusing on those specific levels (modules? rings?! ;) ) might help with different approaches could help us at least a little bit. Well, considering there are some. On Wed, Nov 14, 2018 at 12:37 AM Matthew Miller wrote: > > Hi everyone! Let's talk about something new and exciting. Since its > first release fifteen years ago, Fedora has had a 13-month lifecycle > (give or take). That works awesomely for many cases (like, hey, we're > all here), but not for everyone. Let's talk about how we might address > some of the users and use cases we're missing out on. > > When I talk to people about this, I often get "hey, you should do LTS > or go to rolling releases.” As I've said before, on the surface that's > a weird thing to say, since the actual user impact of those two > different things is mostly _opposite_. So, digging in, it often really > means "I don't want the pain and fear of big OS upgrades". > > We've addressed that in several ways: first, making upgrades better. > (Thanks everyone who has worked on that.) A Fedora release-to-release > update is normally not much more trouble than you might get some random > Tuesday with a rolling release. Second, we have some things like Fedora > Atomic Host and upcoming Fedora CoreOS and IoT which both implement a > rolling stream on top of the Fedora release base. And finally, there's > the coming-someday plans for gating Rawhide, making that a better > proposition for people who really want to live on the edge. > > But there are some good cases for a longer lifecycle. For one thing, > this has been a really big blocker for getting Fedora shipped on > hardware. Second, there are people who really could be happily running > Fedora but since we don't check the tickbox, they don't even look at us > seriously. I'd love to change these things. To do that, we need > something that lasts for 36-48 months. > > So, what would this look like? I have some ideas, but, really, there > are many possibilities. That's what this thread is for. Let's figure it > out. How would we structure repositories? How would we make sure we're > not overworked? How would we balance this with getting people new stuff > fast as well? > > > > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Adam Šamalík --- Software Engineer Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: could Fedora please reverse its policy re End-Of-Life
Dne 14. 11. 18 v 2:23 steve schooler napsal(a): > I recognize that since Fedora is FREE, the developers face an enormous > burden. However, I suspect that many will feel as I do that it is an onerous > user-burden to have to frequently upgrade/re-install. Further, > forum-technical-support, regardless of how timely and incisive, doesn't > compensate for the user-burden. This is the core issue. We only have a limited manpower. You have three things to choose from: free of charge distribution, long support, fresh versions of SW in distribution - but we can only choose two of them. Fedora chose free and fresh versions. If you want long support, you can always choose CentOS, which is based on Fedora. However, you are loosing the "fresh versions". AFAIK no one at a market is offering all three at once. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla
On 11/14/18 12:56 PM, Igor Gnatenko wrote: On Wed, Nov 14, 2018 at 10:14 AM Panu Matilainen wrote: On 11/13/18 10:24 PM, Igor Gnatenko wrote: On Tue, Nov 13, 2018 at 8:49 PM Randy Barlow wrote: On Tue, 2018-11-13 at 13:43 -0500, Neal Gompa wrote: It wasn't a random rebase. A FESCo ticket was submitted and approved[1]. However, there was a miscommunication that led to the DNF team not being aware it happened. [1]: https://pagure.io/fesco/issue/2009 This was not approved - there was a -1 vote and so it was planned to be discussed in the next meeting. I commented the ticket, but I will copy my response here: there was no single -1 within a week after opening a ticket so to my knowledge the ticket was approved. Which is why you need to wait until the actual decision has been stated in the ticket. https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy says """ Once a ticket has a formal proposal offered, FESCo members have one week to either vote for or against it or else propose the ticket for the next weekly meeting agenda. At the end of that one week, if the proposal has gained at least three "for" votes and no "against" votes, it is approved. Any "against" votes mean that it goes onto the next meeting agenda. If the week passes and the required number of votes have not been met, the proposal is extended by one further week and the minimum requirement becomes a single positive "for" vote. This is intended to ensure that proposals do not languish. """ * The ticket had formal proposal offered (means that FESCo members can vote) * 6 FESCo members voted +1 within a week (which means that there were at least three "for" votes and no "against" votes) Considering 2 points above -- I can read that it is approved. Waiting for anyone to put note that it is approved is nice, but not must. If the policy is somehow different from what I have read, please update docs.fp.o and announce it. I stand corrected then. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla
On Wed, Nov 14, 2018 at 10:14 AM Panu Matilainen wrote: > > On 11/13/18 10:24 PM, Igor Gnatenko wrote: > > On Tue, Nov 13, 2018 at 8:49 PM Randy Barlow > > wrote: > >> > >> On Tue, 2018-11-13 at 13:43 -0500, Neal Gompa wrote: > >>> It wasn't a random rebase. A FESCo ticket was submitted and > >>> approved[1]. However, there was a miscommunication that led to the > >>> DNF > >>> team not being aware it happened. > >>> > >>> [1]: https://pagure.io/fesco/issue/2009 > >> > >> This was not approved - there was a -1 vote and so it was planned to be > >> discussed in the next meeting. > > > > I commented the ticket, but I will copy my response here: there was no > > single -1 within a week after opening a ticket so to my knowledge the > > ticket was approved. > > Which is why you need to wait until the actual decision has been stated > in the ticket. https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy says """ Once a ticket has a formal proposal offered, FESCo members have one week to either vote for or against it or else propose the ticket for the next weekly meeting agenda. At the end of that one week, if the proposal has gained at least three "for" votes and no "against" votes, it is approved. Any "against" votes mean that it goes onto the next meeting agenda. If the week passes and the required number of votes have not been met, the proposal is extended by one further week and the minimum requirement becomes a single positive "for" vote. This is intended to ensure that proposals do not languish. """ * The ticket had formal proposal offered (means that FESCo members can vote) * 6 FESCo members voted +1 within a week (which means that there were at least three "for" votes and no "against" votes) Considering 2 points above -- I can read that it is approved. Waiting for anyone to put note that it is approved is nice, but not must. If the policy is somehow different from what I have read, please update docs.fp.o and announce it. > > - Panu - > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 10:19:32AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Nov 14, 2018 at 06:12:11AM +0100, Michal Schorm wrote: > > We, as a distro, just take a different approach. > > To be bleeding edge requires to have releases often. > > > > That allow us to manage changes like GCC, OpenSSL and so on quickly. > > Struggling with upstream who don't adapt, can't adapt or don't want to > > adapt at the same speed. (And OpenSSL patch isn't something you'd want > > to write for serveral pojects you maintain ...) > > > > That is what make us different distro with its own user base. Want the > > very same but LTS system? try CentOS. Or RHEL. > > +1 > > As can be clearly seen from the breadth of the update streams, once F+2 > is released, F+1 still gets a moderate number of updates, but F only > gets major bugs fixed, at best. Some maintainers care more, some less, > but it's pretty obvious that our "oldstable" release is not where the > maintainers are. Now imagine how well we would support F-4 (36 months) > or F-6 (48 months). I'd guess "not at all". It is not so much whether we "care", but rather whether we have enough time in the day to get the expected work done. I can't magic up more time to work no matter how much I care to. Even with the current lifecycle, once a new stable Fedora release comes out, I'll usually only backport security fixes to the previous stable Fedora release from that time onwards. Any other bugs will only get addressed in the most recent stable release unless its trivial to do the previous one too. In some cases I'll not even pretend to be able to backport, and instead simply rebase all existing Fedora releases to latest upstream versions every time. If Fedora had longer life cycles, and more streams maintained in parallel, then I think the result would be that I end up doing rebases for everything I maintain rather than trying to backport anything. Admittedly this would somewhat negate the supposed benefit of having stable long life releases, but its either that or the releases bitrot accumulating more & more bugs & security flaws. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Wed, Nov 14, 2018 at 06:12:11AM +0100, Michal Schorm wrote: > We, as a distro, just take a different approach. > To be bleeding edge requires to have releases often. > > That allow us to manage changes like GCC, OpenSSL and so on quickly. > Struggling with upstream who don't adapt, can't adapt or don't want to > adapt at the same speed. (And OpenSSL patch isn't something you'd want > to write for serveral pojects you maintain ...) > > That is what make us different distro with its own user base. Want the > very same but LTS system? try CentOS. Or RHEL. +1 As can be clearly seen from the breadth of the update streams, once F+2 is released, F+1 still gets a moderate number of updates, but F only gets major bugs fixed, at best. Some maintainers care more, some less, but it's pretty obvious that our "oldstable" release is not where the maintainers are. Now imagine how well we would support F-4 (36 months) or F-6 (48 months). I'd guess "not at all". I don't see this going anywhere without a lot of new maintainers. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
> out. How would we structure repositories? How would we make sure we're > not overworked? How would we balance this with getting people new stuff > fast as well? I'm already overworked supporting old releases for the current 13 months, most of my time is spent on fedora next. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla
On 11/13/18 10:24 PM, Igor Gnatenko wrote: On Tue, Nov 13, 2018 at 8:49 PM Randy Barlow wrote: On Tue, 2018-11-13 at 13:43 -0500, Neal Gompa wrote: It wasn't a random rebase. A FESCo ticket was submitted and approved[1]. However, there was a miscommunication that led to the DNF team not being aware it happened. [1]: https://pagure.io/fesco/issue/2009 This was not approved - there was a -1 vote and so it was planned to be discussed in the next meeting. I commented the ticket, but I will copy my response here: there was no single -1 within a week after opening a ticket so to my knowledge the ticket was approved. Which is why you need to wait until the actual decision has been stated in the ticket. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
