Re: Proposal: Move to an annual platform release starting at F30
On Thu, Nov 29, 2018 at 12:42 PM Nicolas Mailhot wrote: > > Le jeudi 29 novembre 2018 à 10:56 -0500, Josh Boyer a écrit : > > > > Of the large number of packages that you maintain, how many of them > > are critical to freeze at a specific version for a given Fedora > > release? Possibly some, but I would think across the distribution it > > would not be a huge number. > > It's not so much that many packages need freezing, but quite a lot need > coordinated rebuilds (mini mass rebuilds). Once thing current cadencing > provides is "free" mass rebuilds (you just make sure to commit the key > packages before branching and releng will usually mass rebuild all the > other things that depend on those key parts for some other reason). > > Fix the tooling so those mini mass rebuilds are cheap to setup and are > not human packager intensive, and there's not reason the rebuild result > could not be pushed to every release. Or to a rolling release. Or > whatever. Yes, agreed. Fixing the tooling is what much of these threads are about ;) > We really need to evolve our tooling from "packages can be handled > independently in reviews, builds, and pushes, coordinated changes are > the exception" to "we manage sets of packages by default, single-package > changes are just set changes with set = 1" Modularity does that for a number of cases, but it isn't a silver bullet. Our package dependencies web is much too complex to make it feasible for everything to be in a module, at least right now. (We should really also revisit our package dependencies in general and try to minimize as much as we can for a variety of reasons, leveraging rich/weak deps. That's a different topic though.) 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: Proposal: Move to an annual platform release starting at F30
Le jeudi 29 novembre 2018 à 10:56 -0500, Josh Boyer a écrit : > > Of the large number of packages that you maintain, how many of them > are critical to freeze at a specific version for a given Fedora > release? Possibly some, but I would think across the distribution it > would not be a huge number. It's not so much that many packages need freezing, but quite a lot need coordinated rebuilds (mini mass rebuilds). Once thing current cadencing provides is "free" mass rebuilds (you just make sure to commit the key packages before branching and releng will usually mass rebuild all the other things that depend on those key parts for some other reason). Fix the tooling so those mini mass rebuilds are cheap to setup and are not human packager intensive, and there's not reason the rebuild result could not be pushed to every release. Or to a rolling release. Or whatever. We really need to evolve our tooling from "packages can be handled independently in reviews, builds, and pushes, coordinated changes are the exception" to "we manage sets of packages by default, single-package changes are just set changes with set = 1" -- Nicolas Mailhot ___ 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: Proposal: Move to an annual platform release starting at F30
On Thu, Nov 29, 2018 at 11:15 AM Neal Gompa wrote: > > On Thu, Nov 29, 2018 at 10:57 AM Josh Boyer wrote: > > > > On Thu, Nov 29, 2018 at 10:22 AM Paul Frields wrote: > > > > > > On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý wrote: > > > > > > > > Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a): > > > > >> In other words, the "technical debt" we are trying to solve here is > > > > >> not project wide and doesn't justify slowing down the whole project > > > > >> permanently. > > > > > I completely disagree. Our release process and tooling is built on > > > > > heroism and tech debt. > > > > > > > > People working on release and people working on packages maintenance > > > > are different group - they are not disjunct, but it > > > > is not the same group. > > > > For example *I* am a maintainer of lots of packages, but the additional > > > > works because of the fedora release is about one > > > > working day per year - and it is mostly because of fedora-upgrade > > > > package. Other packages do not need so much work. I am > > > > more affected by upstream releases. > > > > > > > > Do not forget that annual releases will mean that N-1 release will > > > > implicate 24 months support for packages which will > > > > mean a much more significant impact on us-the maintaners. > > > > I'll echo what Paul says below with a +1, but I wanted to touch on > > this point a bit because it implies an assumption that the maintenance > > model remains the same even if lifecycle options change. I don't > > think that needs to be the case, nor do I think it would even be good. > > > > Of the large number of packages that you maintain, how many of them > > are critical to freeze at a specific version for a given Fedora > > release? Possibly some, but I would think across the distribution it > > would not be a huge number. So if there is no essential need to > > freeze them at a specific version, why would you want to maintain the > > packages *separately* for each release? That sounds like extra work > > for no benefit. If we instead take a maintenance approach that you > > maintain package foo and it is built for all releases, then you only > > really need to maintain it in a singular instance. > > > > Today that is something that can be accomplished with modularity, but > > I would suggest that we look at stream branching as a solution even > > for regular packages. So you wouldn't have fc22-fc32 branches under > > package foo. You'd have foo/stream- and you could build that > > wherever you'd like. Couple that with automated CI testing and I > > believe you actually decrease your maintenance burden while increasing > > your quality. > > > > There are many details that would need to be worked out and I don't > > want to trivialize them, but I do want to at least get people thinking > > about it in the long term. If we are going to improve the way we > > build and deliver our operating system, we shouldn't assume we can do > > that without changing the way we maintain it either. > > > > We can change this _today_, actually. fedpkg supports an in-repo > config file to specify distro targets to push whenever running `fedpkg > build`. So you could do a repo with only a master branch and have it > push to all distro targets enabled for the repo at once. This is > probably a useful optimization for the overwhelming majority of > packages held by packagers. Yep, I know :) For a lot of packages, this could be done now. I think to get the full benefits from it across the distro, we'd need to really define that platform layer so maintainers know what they can depend on, etc. > It's just not documented or available as an option for setup when you > file a repo creation request. Right. I think we should start encouraging its use. I kind of dislike using 'master' as the branch because it's ambiguous depending on how you look at it, but it's not wrong. A stream branch just provides a bit more context. 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: Proposal: Move to an annual platform release starting at F30
On Thu, Nov 29, 2018 at 10:57 AM Josh Boyer wrote: > > On Thu, Nov 29, 2018 at 10:22 AM Paul Frields wrote: > > > > On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý wrote: > > > > > > Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a): > > > >> In other words, the "technical debt" we are trying to solve here is > > > >> not project wide and doesn't justify slowing down the whole project > > > >> permanently. > > > > I completely disagree. Our release process and tooling is built on > > > > heroism and tech debt. > > > > > > People working on release and people working on packages maintenance are > > > different group - they are not disjunct, but it > > > is not the same group. > > > For example *I* am a maintainer of lots of packages, but the additional > > > works because of the fedora release is about one > > > working day per year - and it is mostly because of fedora-upgrade > > > package. Other packages do not need so much work. I am > > > more affected by upstream releases. > > > > > > Do not forget that annual releases will mean that N-1 release will > > > implicate 24 months support for packages which will > > > mean a much more significant impact on us-the maintaners. > > I'll echo what Paul says below with a +1, but I wanted to touch on > this point a bit because it implies an assumption that the maintenance > model remains the same even if lifecycle options change. I don't > think that needs to be the case, nor do I think it would even be good. > > Of the large number of packages that you maintain, how many of them > are critical to freeze at a specific version for a given Fedora > release? Possibly some, but I would think across the distribution it > would not be a huge number. So if there is no essential need to > freeze them at a specific version, why would you want to maintain the > packages *separately* for each release? That sounds like extra work > for no benefit. If we instead take a maintenance approach that you > maintain package foo and it is built for all releases, then you only > really need to maintain it in a singular instance. > > Today that is something that can be accomplished with modularity, but > I would suggest that we look at stream branching as a solution even > for regular packages. So you wouldn't have fc22-fc32 branches under > package foo. You'd have foo/stream- and you could build that > wherever you'd like. Couple that with automated CI testing and I > believe you actually decrease your maintenance burden while increasing > your quality. > > There are many details that would need to be worked out and I don't > want to trivialize them, but I do want to at least get people thinking > about it in the long term. If we are going to improve the way we > build and deliver our operating system, we shouldn't assume we can do > that without changing the way we maintain it either. > We can change this _today_, actually. fedpkg supports an in-repo config file to specify distro targets to push whenever running `fedpkg build`. So you could do a repo with only a master branch and have it push to all distro targets enabled for the repo at once. This is probably a useful optimization for the overwhelming majority of packages held by packagers. It's just not documented or available as an option for setup when you file a repo creation request. -- 真実はいつも一つ！/ 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: Proposal: Move to an annual platform release starting at F30
On Thu, Nov 29, 2018 at 10:22 AM Paul Frields wrote: > > On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý wrote: > > > > Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a): > > >> In other words, the "technical debt" we are trying to solve here is > > >> not project wide and doesn't justify slowing down the whole project > > >> permanently. > > > I completely disagree. Our release process and tooling is built on > > > heroism and tech debt. > > > > People working on release and people working on packages maintenance are > > different group - they are not disjunct, but it > > is not the same group. > > For example *I* am a maintainer of lots of packages, but the additional > > works because of the fedora release is about one > > working day per year - and it is mostly because of fedora-upgrade package. > > Other packages do not need so much work. I am > > more affected by upstream releases. > > > > Do not forget that annual releases will mean that N-1 release will > > implicate 24 months support for packages which will > > mean a much more significant impact on us-the maintaners. I'll echo what Paul says below with a +1, but I wanted to touch on this point a bit because it implies an assumption that the maintenance model remains the same even if lifecycle options change. I don't think that needs to be the case, nor do I think it would even be good. Of the large number of packages that you maintain, how many of them are critical to freeze at a specific version for a given Fedora release? Possibly some, but I would think across the distribution it would not be a huge number. So if there is no essential need to freeze them at a specific version, why would you want to maintain the packages *separately* for each release? That sounds like extra work for no benefit. If we instead take a maintenance approach that you maintain package foo and it is built for all releases, then you only really need to maintain it in a singular instance. Today that is something that can be accomplished with modularity, but I would suggest that we look at stream branching as a solution even for regular packages. So you wouldn't have fc22-fc32 branches under package foo. You'd have foo/stream- and you could build that wherever you'd like. Couple that with automated CI testing and I believe you actually decrease your maintenance burden while increasing your quality. There are many details that would need to be worked out and I don't want to trivialize them, but I do want to at least get people thinking about it in the long term. If we are going to improve the way we build and deliver our operating system, we shouldn't assume we can do that without changing the way we maintain it either. josh > Let's not get too focused on an annual release (or any specific > timeframe for longer release). I know this is something that some > people want. I understand that, and it's *possible* to do in a future > state where more people are empowered to make releases happen. But a > longer release is not the primary goal, merely something that's > possible. > > I'm more interested in a shorter release that implies less added > maintainer effort. We already put time into Rawhide, and I would like > to see that better leveraged in what we push to consumers. Right now > our branch cycle is six months, at which point we have numerous > freezes and other operations that consume a lot of manual time. They > also bottleneck our pace. > > I want to increase automation, decrease manual bottlenecks and > freezes, and spread out permissions to assemble and push out "ready" > content. I would like to optimize for a faster release, making any > slower releases possible. Those releases should be based on what the > consumers of that release need, as well as the efforts our maintainers > have available. > > -- > Paul > ___ > 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: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 7:43 AM Fabio Valentini wrote: > I think the kernel is a bad example here. It's exceedly stable across > releases, so it's probably the one component that's least problematic > to upgrade during a fedora release. The fedora kernel team is already > doing that, and they are doing an excellent job, which they definitely > deserve more praise for than they get. For me, the frequent, > well-executed stable kernel updates are one thing that positively > distinguishes fedora from other non-rolling distros. [...snip...] I wanted to offer a hearty +1 here. I have been thinking more about the optimization needed for a faster release process, which would *not* disadvantage our awesome kernel team. I wouldn't foresee, for example, that we'd freeze on a specific kernel for such a process. On the contrary, the kernel team does an *amazing* job making sure that Fedora is relevant to the upstream kernel community as much as possible. We routinely get fresh kernels with updated hardware support. I wouldn't want to see this stop. I understand the lifecycle goals theoretically also make possible a longer term release. How that would happen should be based on what its consumers need, and (maybe even more importantly) what our maintainers are able to do without each being issued a Fedora Time Turner[1]. I don't want to optimize for that case because a much shorter cycle (even with less fanfare) encourages us to pursue more automation and more contributor empowerment. * * * [1] http://harrypotter.wikia.com/wiki/Time-Turner ___ 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: Proposal: Move to an annual platform release starting at F30
On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý wrote: > > Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a): > >> In other words, the "technical debt" we are trying to solve here is > >> not project wide and doesn't justify slowing down the whole project > >> permanently. > > I completely disagree. Our release process and tooling is built on > > heroism and tech debt. > > People working on release and people working on packages maintenance are > different group - they are not disjunct, but it > is not the same group. > For example *I* am a maintainer of lots of packages, but the additional works > because of the fedora release is about one > working day per year - and it is mostly because of fedora-upgrade package. > Other packages do not need so much work. I am > more affected by upstream releases. > > Do not forget that annual releases will mean that N-1 release will implicate > 24 months support for packages which will > mean a much more significant impact on us-the maintaners. Let's not get too focused on an annual release (or any specific timeframe for longer release). I know this is something that some people want. I understand that, and it's *possible* to do in a future state where more people are empowered to make releases happen. But a longer release is not the primary goal, merely something that's possible. I'm more interested in a shorter release that implies less added maintainer effort. We already put time into Rawhide, and I would like to see that better leveraged in what we push to consumers. Right now our branch cycle is six months, at which point we have numerous freezes and other operations that consume a lot of manual time. They also bottleneck our pace. I want to increase automation, decrease manual bottlenecks and freezes, and spread out permissions to assemble and push out "ready" content. I would like to optimize for a faster release, making any slower releases possible. Those releases should be based on what the consumers of that release need, as well as the efforts our maintainers have available. -- Paul ___ 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: Proposal: Move to an annual platform release starting at F30
Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a): >> In other words, the "technical debt" we are trying to solve here is >> not project wide and doesn't justify slowing down the whole project >> permanently. > I completely disagree. Our release process and tooling is built on > heroism and tech debt. People working on release and people working on packages maintenance are different group - they are not disjunct, but it is not the same group. For example *I* am a maintainer of lots of packages, but the additional works because of the fedora release is about one working day per year - and it is mostly because of fedora-upgrade package. Other packages do not need so much work. I am more affected by upstream releases. Do not forget that annual releases will mean that N-1 release will implicate 24 months support for packages which will mean a much more significant impact on us-the maintaners. 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: Proposal: Move to an annual platform release starting at F30
On Wed, 28 Nov 2018 at 13:05, Josh Boyer wrote: > > On Wed, Nov 28, 2018 at 12:57 PM Stephen John Smoogen > wrote: > > > > On Wed, 28 Nov 2018 at 12:47, Owen Taylor wrote: > > > > > > On Wed, Nov 28, 2018 at 12:40 PM Stephen John Smoogen > > > wrote: > > > > On Wed, 28 Nov 2018 at 11:37, Owen Taylor wrote: > > > > > > > > Fedora needs to be an operating system provider, not just an operating > > > > > system toolbox provider. > > > > > > > > I feel like we have been saying this for 15+ years even before Fedora > > > > was Fedora. Even back in the RHL days, we would argue over whether > > > > what we were providing was an 'OS' or not versus a toolkit for someone > > > > else to work with. > > > > > > I don't think we've just been saying this, I think we've been steadily > > > improving in this area - both in our focus and in our processes. The > > > move to editions was particularly helpful. > > > > > > > I didn't mean to assume we haven't improved on it, but I do believe it > > is the central 'conflict' we have had. My main worry is that can we > > actually achieve being an "operating system provider" or are we always > > going to be a toolbox who isn't happy with itself? (or thirdly, are we > > already an operating system provider with delusions of being a > > toolbox?) > > Why do either of those possibilities matter? Or asked more directly, > why wouldn't we continue to look at ourselves and iterate and try to > improve? There is no "done" state in an operating system. > You communicated clearer in your previous email what I wanted to say better than I have in mine. Evolution versus revolution. We spend a lot of time and energy talking for and against revolutions every release because we don't seem to know what we are at and when in fact most of them are evolutions which later on weren't as big as expected. I just want us to come to some consensus on what we have accomplished, where we are at, and then see if we can work out what we need to iterate and improve. [I am probably still not communicating this any better than I did in my previous emails, as I think you covered it very well previously. ] > > How can we know if we actually are still making progress if we each > > have a different definition of what that operating system is. > > Great question. I know there are different ideas around it in terms > of platform vs. core/extras vs. lifecycles of different bits. I think > coming to a general consensus on that is a huge part of the discussion > we're having here. Thanks. I am interested in working out what we have accomplished so far, and what we are hurting on in concrete terms. > 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 -- 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: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 12:57 PM Stephen John Smoogen wrote: > > On Wed, 28 Nov 2018 at 12:47, Owen Taylor wrote: > > > > On Wed, Nov 28, 2018 at 12:40 PM Stephen John Smoogen > > wrote: > > > On Wed, 28 Nov 2018 at 11:37, Owen Taylor wrote: > > > > > > Fedora needs to be an operating system provider, not just an operating > > > > system toolbox provider. > > > > > > I feel like we have been saying this for 15+ years even before Fedora > > > was Fedora. Even back in the RHL days, we would argue over whether > > > what we were providing was an 'OS' or not versus a toolkit for someone > > > else to work with. > > > > I don't think we've just been saying this, I think we've been steadily > > improving in this area - both in our focus and in our processes. The > > move to editions was particularly helpful. > > > > I didn't mean to assume we haven't improved on it, but I do believe it > is the central 'conflict' we have had. My main worry is that can we > actually achieve being an "operating system provider" or are we always > going to be a toolbox who isn't happy with itself? (or thirdly, are we > already an operating system provider with delusions of being a > toolbox?) Why do either of those possibilities matter? Or asked more directly, why wouldn't we continue to look at ourselves and iterate and try to improve? There is no "done" state in an operating system. > How can we know if we actually are still making progress if we each > have a different definition of what that operating system is. Great question. I know there are different ideas around it in terms of platform vs. core/extras vs. lifecycles of different bits. I think coming to a general consensus on that is a huge part of the discussion we're having here. 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: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 12:47 PM Owen Taylor wrote: > > On Wed, Nov 28, 2018 at 12:40 PM Stephen John Smoogen > wrote: > > On Wed, 28 Nov 2018 at 11:37, Owen Taylor wrote: > > > > Fedora needs to be an operating system provider, not just an operating > > > system toolbox provider. > > > > I feel like we have been saying this for 15+ years even before Fedora > > was Fedora. Even back in the RHL days, we would argue over whether > > what we were providing was an 'OS' or not versus a toolkit for someone > > else to work with. > > I don't think we've just been saying this, I think we've been steadily > improving in this area - both in our focus and in our processes. The > move to editions was particularly helpful. I think this is a key observation. Some people thought Editions were just rearranging stuff arbitrarily or for little value. I continue to see them as a great way to focus on specific user bases. What we're discussing now is just continuation of that at a more fundamental level. For some reason I can't understand, people want a revolution every time. Fedora often has a tendency to look at evolution as failure. That isn't sustainable and leads to repeating mistakes, creating totally new problems, etc. There is nothing wrong with iteration as long as you know where you're going and why you're making the changes you're making. In this particular round, I think focusing on some of the fundamentals on how we construct our OS (compose tooling, real actual CI, etc) is another evolution. Does it materially change what Fedora is to end users? No. Does it have benefits for them and for maintainers in the long run? Yes. We seem to also keep trying to force fit a single OS release methodology into all use cases. That leads to a poor fit many times. With looking at multiple lifecycles and how to pull that off using the fundamentals above, we can actually still look at being an OS provider but it doesn't have to be a singular OS. We can create the platform necessary to have commonality at certain layers across different use cases. Do I think all of this will happen in a single Fedora "release"? No. It's good to be somewhat timeboxed, and I think we can make really great strides on some of it. For other bits we'll have to see how things fall out going forward. But if we don't take the time now to work on the enablers, the big picture or theoretical goals won't matter. 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: Proposal: Move to an annual platform release starting at F30
On Wed, 28 Nov 2018 at 12:47, Owen Taylor wrote: > > On Wed, Nov 28, 2018 at 12:40 PM Stephen John Smoogen > wrote: > > On Wed, 28 Nov 2018 at 11:37, Owen Taylor wrote: > > > > Fedora needs to be an operating system provider, not just an operating > > > system toolbox provider. > > > > I feel like we have been saying this for 15+ years even before Fedora > > was Fedora. Even back in the RHL days, we would argue over whether > > what we were providing was an 'OS' or not versus a toolkit for someone > > else to work with. > > I don't think we've just been saying this, I think we've been steadily > improving in this area - both in our focus and in our processes. The > move to editions was particularly helpful. > I didn't mean to assume we haven't improved on it, but I do believe it is the central 'conflict' we have had. My main worry is that can we actually achieve being an "operating system provider" or are we always going to be a toolbox who isn't happy with itself? (or thirdly, are we already an operating system provider with delusions of being a toolbox?) How can we know if we actually are still making progress if we each have a different definition of what that operating system is. > Owen > ___ > 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: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 12:40 PM Stephen John Smoogen wrote: > On Wed, 28 Nov 2018 at 11:37, Owen Taylor wrote: > > Fedora needs to be an operating system provider, not just an operating > > system toolbox provider. > > I feel like we have been saying this for 15+ years even before Fedora > was Fedora. Even back in the RHL days, we would argue over whether > what we were providing was an 'OS' or not versus a toolkit for someone > else to work with. I don't think we've just been saying this, I think we've been steadily improving in this area - both in our focus and in our processes. The move to editions was particularly helpful. Owen ___ 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: Proposal: Move to an annual platform release starting at F30
On Wed, 28 Nov 2018 at 11:37, Owen Taylor wrote: > > On Wed, Nov 28, 2018 at 3:07 AM Brian (bex) Exelbierd > wrote: > > > I'd push Brendans' concept further and suggest that we try to > > eliminate as many of the compilers, libraries and core system tools as > > possible from this bootable-base so that those can iterate at their > > own speed, perhaps 4 year for a laptop vendor and 30 day for a > > experimental ARM device. Fedora as a project might not build output > > for the whole range, but a build system that allowed us to help others > > be successful would be a huge help here. > > Fedora needs to be an operating system provider, not just an operating > system toolbox provider. I feel like we have been saying this for 15+ years even before Fedora was Fedora. Even back in the RHL days, we would argue over whether what we were providing was an 'OS' or not versus a toolkit for someone else to work with. [Especially during the days when Mandrake and a couple others were just rebuilds of Red Hat Linux with specific kernel flags and some light patching to sed Red Hat Linux to Mandrake.] Do we even know what an operating system provider is? Because it seems like we do this every release where each groups look at what was produced versus what they wanted and all they can see is all the compromises they had to make to get it out the door. And unless we actually come up with some specific things of what is really wanted, we will be doing this every release in the future too. -- 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: Proposal: Move to an annual platform release starting at F30
I totally agree with Paul and Kevin. I want to see a faster release cycle (probably rolling release) and shorter processes to get a release out. On Tue, Nov 27, 2018 at 3:02 PM Kevin Fenzi wrote: > I agree with the folks in this subthread, but I think we are going to > have to look at 'redesigning' things more than just 'optimizing'. > > ie, collect all our inputs and outputs and things we need to do in the > process and figure out how to make it modular (no relation) so we can > look at just a single changed input and quickly test and generate all > the outputs that are affected by that input (and not any of the others). > > For example, a new xfce4-settings package comes out, we want to test it, > test the Xfce live media and if it all passes, perhaps release that media. > If we can do this, we can release different artifacts at different times which gives more comfort and flexibility to different WG's. > > It may well be that we can figure out a 'base platform' just by looking > at these imput/outputs: what things are in most or all outputs? > > kevin > > > ___ > 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: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 3:07 AM Brian (bex) Exelbierd wrote: > I think that Fedora's role as an innovater in the OS space means we > should be aggressively exploring this. Rolling Releases, Tech-Driven > Releases and Time-Based Releases all have well known positives and > negatives. All of the work that has been done on Modularity, > containers, flatpaks, OSTree, and more, gives us the opportunity to > really re-think this. While it is true there are dozens (or more) > additional solutions to the too-fast/too-slow and the > incompatible-libraries problems, these technologies seem to be gaining > the most adoption across a variety of use cases. They are all also > generally well supported in Fedora and we need to aggressively push > them to achieve this goal or determine where the dead-end is so we can > move to the next innovation. We have a lot of flexibility with all these technologies. What we need to achieve through our processes - CI, the release process, etc, is to enable users to take advantage of the technologies to achieve their goals - to get their work done - without having new problems thrown at them - excessive complexity, instability, etc. > I personal am hugely in favor of us adopting a bootable-base model > that allows us to iterate the kernel and the various user-space pieces > at the speed of the upstream, the user's desires and the builder's > desires[^0] all at the same time. While this will require us to do > some level of NxM matrix building and testing, a base that didn't have > to change often for most use cases reduces the matrix considerably. The term "bootable-base" concerns me - because it could be interpreted to mean a minimal bootable set - just enough to get systemd and dnf running, perhaps. In another mail, you explained what you meant as "light up the machine level [...] and get containers/flatpaks/etc running". What does it take to get containers running usefully? It probably looks quite a bit like Fedora CoreOS. What does it take to get Flatpaks running in a useful way to users? - you need a full desktop environment - something like Fedora Silverblue (or the default install set of Fedora Workstation if you prefer loose packages). While the Fedora release today contains a lot more software than this "core operating system" - generally our release processes today are targeted at trying to release a stable core operating system - and this is something we can't lose if we start changing around how things work. It's not that I don't think the maintenance of glibc and gcc is really important, but if we refocus our release processes only on that, and one day a broken wpa-supplicant rebase lands and half our users lose networking - that would be a really poor outcome for Fedora. > I'd push Brendans' concept further and suggest that we try to > eliminate as many of the compilers, libraries and core system tools as > possible from this bootable-base so that those can iterate at their > own speed, perhaps 4 year for a laptop vendor and 30 day for a > experimental ARM device. Fedora as a project might not build output > for the whole range, but a build system that allowed us to help others > be successful would be a huge help here. Fedora needs to be an operating system provider, not just an operating system toolbox provider. There are a lot of use cases for the "operating system toolbox" - To build the operating systems that Fedora releases - CoreOS, Workstation, etc. - To create the containers, Flatpak runtimes, and Flatpaks that Fedora releases - For users to create application containers - To create development environments (pet containers) - For adventurous users to create new, customized operating systems but you can't do integration testing on operating system toolbox, because the whole point is that you can integrated it any way you want and only the end user defines what is broken and what is working. Producing a *quality* operating system requires us to focus our processes on the integrated operating systems that we produce, on the applications we produce - and that's what our processes should be around. Could we replace the current 6 month release processes with an alternate set of processes around multiple rolling branches? It's certainly a possibility, but it's going to be very difficult to get a high level of stability - a level of stability that is acceptable to all end users - without a process where the *entire operating system* gets beta tested before being pushed out. If we want to move in the direction of rolling releases, the first step is to get the continuous integration testing and gating in place to make rawhide consumable by a broader set of people. That would be incredibly useful even if we keep the current 6 month tempo, but essential if we want to move to a rolling stable model. Until we can demonstrate that, it seems really premature to talk about rolling stable models. Owen ___ devel
Re: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 1:49 PM Brian (bex) Exelbierd wrote: > > On Wed, Nov 28, 2018 at 1:31 PM Igor Gnatenko > wrote: > > > > On Wed, Nov 28, 2018 at 1:14 PM Brian (bex) Exelbierd > > wrote: > > > > > > On Wed, Nov 28, 2018 at 12:12 PM Peter Robinson > > > wrote: > > > > > > > > On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd > > > > wrote: > > > > > > > > > > On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy > > > > > wrote: > > > > > > Paul's proposal was definitely a one-time pause for the reasons you > > > > > > state. He requested we follow-up with additional questions and > > > > > > suggestions so I'm questioning and suggesting taking it a step > > > > > > further. We talk about rolling releases, but people are skeptical > > > > > > due > > > > > > to rawhide instability. What does it look like if the "rolling" > > > > > > happens on top of an otherwise stable platform where fundamentals > > > > > > like > > > > > > compilers, libraries and core system tools are held steady, but > > > > > > things > > > > > > on top move fast? Maybe you don't need an F30.1, maybe it means F30 > > > > > > just keeps getting nice incremental updates for as long as the > > > > > > editions want to stick with it. Variable lifecycle or cadence can > > > > > > open up these kinds of options. Some things are better fast. Some > > > > > > things are better slow. > > > > > > > > > > This. Yes This. +100 > > > > > > > > > > I think that Fedora's role as an innovater in the OS space means we > > > > > should be aggressively exploring this. Rolling Releases, Tech-Driven > > > > > Releases and Time-Based Releases all have well known positives and > > > > > negatives. All of the work that has been done on Modularity, > > > > > containers, flatpaks, OSTree, and more, gives us the opportunity to > > > > > really re-think this. While it is true there are dozens (or more) > > > > > additional solutions to the too-fast/too-slow and the > > > > > incompatible-libraries problems, these technologies seem to be gaining > > > > > the most adoption across a variety of use cases. They are all also > > > > > generally well supported in Fedora and we need to aggressively push > > > > > them to achieve this goal or determine where the dead-end is so we can > > > > > move to the next innovation. > > > > > > > > > > I personal am hugely in favor of us adopting a bootable-base model > > > > > that allows us to iterate the kernel and the various user-space pieces > > > > > at the speed of the upstream, the user's desires and the builder's > > > > > desires[^0] all at the same time. While this will require us to do > > > > > some level of NxM matrix building and testing, a base that didn't have > > > > > to change often for most use cases reduces the matrix considerably. > > > > > > > > The above doesn't make sense, you're saying "move as fast as upstream" > > > > and "a base that doesn't change" in the same context, which is it? > > > > > > I've failed to be clear - sorry about that. Let me try again. > > > > > > Please remember that I tend think from the lens of user space, not > > > kernel space. So there may be detail errors in this, I am hoping the > > > concepts are valid though. > > > > > > In general, I can run various versions of my applications against > > > multiple different kernels, for example. Therefore, if I have a > > > kernel that changed once a year, it isn't going to, for many > > > applications, stop me from changing versions multiple times during the > > > year. Therefore if Fedora had a stabilized bootable base, I could > > > move my applications at the cadence of upstream, or a stabilized > > > release (not at all) or at the speed in the middle I want. Fedora > > > might not build the entire range of that, but I am not prevented from > > > choosing amongst multiple Fedora provided options (stable vs devel or > > > all supported upstream releases, for example). > > > > So you mean that you want CentOS stable base and latest software you want? > > Nope. I want CentOS to serve their user base. If the CentOS project > chooses to formally become part of Fedora and to release a > longer-maintained base to their users under the banner of our mission, > I welcome them with open arms. But, that is their decision. > > I don't think Fedora wants to get into 10 year life cycles and that > level of backporting. But, accepting a new kernel/bootable base > shouldn't force me to take a new version of LibreOffice, for example. So what you are saying here is what "first" version of Modularity was about. And it didn't work out because of many reasons. One of them is no useful CI infrastructure (still not solved) which didn't allow packagers to remove useless BuildRequires for tests (because rpmbuild is still tte way to run test suite). If we can get commitment from people who maintain "minimal viable base" to move their tests to CI and get FTBFS fixes in time -- it might work. > > > The bootable base
Re: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 1:07 PM Brian (bex) Exelbierd wrote: > > On Wed, Nov 28, 2018 at 12:12 PM Peter Robinson wrote: > > > > On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd > > wrote: > > > > > > On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy wrote: > > > > Paul's proposal was definitely a one-time pause for the reasons you > > > > state. He requested we follow-up with additional questions and > > > > suggestions so I'm questioning and suggesting taking it a step > > > > further. We talk about rolling releases, but people are skeptical due > > > > to rawhide instability. What does it look like if the "rolling" > > > > happens on top of an otherwise stable platform where fundamentals like > > > > compilers, libraries and core system tools are held steady, but things > > > > on top move fast? Maybe you don't need an F30.1, maybe it means F30 > > > > just keeps getting nice incremental updates for as long as the > > > > editions want to stick with it. Variable lifecycle or cadence can > > > > open up these kinds of options. Some things are better fast. Some > > > > things are better slow. > > > > > > This. Yes This. +100 > > > > > > I think that Fedora's role as an innovater in the OS space means we > > > should be aggressively exploring this. Rolling Releases, Tech-Driven > > > Releases and Time-Based Releases all have well known positives and > > > negatives. All of the work that has been done on Modularity, > > > containers, flatpaks, OSTree, and more, gives us the opportunity to > > > really re-think this. While it is true there are dozens (or more) > > > additional solutions to the too-fast/too-slow and the > > > incompatible-libraries problems, these technologies seem to be gaining > > > the most adoption across a variety of use cases. They are all also > > > generally well supported in Fedora and we need to aggressively push > > > them to achieve this goal or determine where the dead-end is so we can > > > move to the next innovation. > > > > > > I personal am hugely in favor of us adopting a bootable-base model > > > that allows us to iterate the kernel and the various user-space pieces > > > at the speed of the upstream, the user's desires and the builder's > > > desires[^0] all at the same time. While this will require us to do > > > some level of NxM matrix building and testing, a base that didn't have > > > to change often for most use cases reduces the matrix considerably. > > > > The above doesn't make sense, you're saying "move as fast as upstream" > > and "a base that doesn't change" in the same context, which is it? > > I've failed to be clear - sorry about that. Let me try again. > > Please remember that I tend think from the lens of user space, not > kernel space. So there may be detail errors in this, I am hoping the > concepts are valid though. > > In general, I can run various versions of my applications against > multiple different kernels, for example. Therefore, if I have a > kernel that changed once a year, it isn't going to, for many > applications, stop me from changing versions multiple times during the > year. Therefore if Fedora had a stabilized bootable base, I could > move my applications at the cadence of upstream, or a stabilized > release (not at all) or at the speed in the middle I want. Fedora > might not build the entire range of that, but I am not prevented from > choosing amongst multiple Fedora provided options (stable vs devel or > all supported upstream releases, for example). I think the kernel is a bad example here. It's exceedly stable across releases, so it's probably the one component that's least problematic to upgrade during a fedora release. The fedora kernel team is already doing that, and they are doing an excellent job, which they definitely deserve more praise for than they get. For me, the frequent, well-executed stable kernel updates are one thing that positively distinguishes fedora from other non-rolling distros. On the other hand, specific releases of GCC, glibc, (golang, ruby, python, ocaml, perl, node, insert other compilers / interpreters here) would be better examples of a "stable base". They really warrant "new releases", since major updates of those components usually require mass rebuilds of their dependent packages. So, I'd rather draw the line between "base" and "rolling application releases" *atop* the development environment that the versions of GCC, glibc, python, golang, etc. make up, not below them. This is what many packagers already do, from my experience. GNOME really is an exception here, even KDE/KF5/Plasma is updated regularly during stable releases. Whether the "base" system (that's used for development and building all other packages atop it) is released every 6 months (aligning with semi-annual releases of i.e. golang) or yearly (more in line with ~annual releases of GCC, python, etc.) isn't as important then, since what's important to users (hardware support - kernel, and applications) is
Re: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 1:31 PM Igor Gnatenko wrote: > > On Wed, Nov 28, 2018 at 1:14 PM Brian (bex) Exelbierd > wrote: > > > > On Wed, Nov 28, 2018 at 12:12 PM Peter Robinson > > wrote: > > > > > > On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd > > > wrote: > > > > > > > > On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy wrote: > > > > > Paul's proposal was definitely a one-time pause for the reasons you > > > > > state. He requested we follow-up with additional questions and > > > > > suggestions so I'm questioning and suggesting taking it a step > > > > > further. We talk about rolling releases, but people are skeptical due > > > > > to rawhide instability. What does it look like if the "rolling" > > > > > happens on top of an otherwise stable platform where fundamentals like > > > > > compilers, libraries and core system tools are held steady, but things > > > > > on top move fast? Maybe you don't need an F30.1, maybe it means F30 > > > > > just keeps getting nice incremental updates for as long as the > > > > > editions want to stick with it. Variable lifecycle or cadence can > > > > > open up these kinds of options. Some things are better fast. Some > > > > > things are better slow. > > > > > > > > This. Yes This. +100 > > > > > > > > I think that Fedora's role as an innovater in the OS space means we > > > > should be aggressively exploring this. Rolling Releases, Tech-Driven > > > > Releases and Time-Based Releases all have well known positives and > > > > negatives. All of the work that has been done on Modularity, > > > > containers, flatpaks, OSTree, and more, gives us the opportunity to > > > > really re-think this. While it is true there are dozens (or more) > > > > additional solutions to the too-fast/too-slow and the > > > > incompatible-libraries problems, these technologies seem to be gaining > > > > the most adoption across a variety of use cases. They are all also > > > > generally well supported in Fedora and we need to aggressively push > > > > them to achieve this goal or determine where the dead-end is so we can > > > > move to the next innovation. > > > > > > > > I personal am hugely in favor of us adopting a bootable-base model > > > > that allows us to iterate the kernel and the various user-space pieces > > > > at the speed of the upstream, the user's desires and the builder's > > > > desires[^0] all at the same time. While this will require us to do > > > > some level of NxM matrix building and testing, a base that didn't have > > > > to change often for most use cases reduces the matrix considerably. > > > > > > The above doesn't make sense, you're saying "move as fast as upstream" > > > and "a base that doesn't change" in the same context, which is it? > > > > I've failed to be clear - sorry about that. Let me try again. > > > > Please remember that I tend think from the lens of user space, not > > kernel space. So there may be detail errors in this, I am hoping the > > concepts are valid though. > > > > In general, I can run various versions of my applications against > > multiple different kernels, for example. Therefore, if I have a > > kernel that changed once a year, it isn't going to, for many > > applications, stop me from changing versions multiple times during the > > year. Therefore if Fedora had a stabilized bootable base, I could > > move my applications at the cadence of upstream, or a stabilized > > release (not at all) or at the speed in the middle I want. Fedora > > might not build the entire range of that, but I am not prevented from > > choosing amongst multiple Fedora provided options (stable vs devel or > > all supported upstream releases, for example). > > So you mean that you want CentOS stable base and latest software you want? Nope. I want CentOS to serve their user base. If the CentOS project chooses to formally become part of Fedora and to release a longer-maintained base to their users under the banner of our mission, I welcome them with open arms. But, that is their decision. I don't think Fedora wants to get into 10 year life cycles and that level of backporting. But, accepting a new kernel/bootable base shouldn't force me to take a new version of LibreOffice, for example. > > The bootable base would change based on Fedora's needs. Perhaps we > > decide want to new kernels (again sorry for my failings in this field) > > every 6 months to introduce new drivers and hardware support. Someone > > who wants faster can self-build for their community/needs more > > frequently or a hardware vendor might want a kernel that doesn't > > change as often and is backported. Fedora may not build the whole > > range here either. > > > > > > I'd push Brendans' concept further and suggest that we try to > > > > eliminate as many of the compilers, libraries and core system tools as > > > > possible from this bootable-base so that those can iterate at their > > > > own speed, perhaps 4 year for a laptop vendor and 30 day for a >
Re: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 1:14 PM Brian (bex) Exelbierd wrote: > > On Wed, Nov 28, 2018 at 12:12 PM Peter Robinson wrote: > > > > On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd > > wrote: > > > > > > On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy wrote: > > > > Paul's proposal was definitely a one-time pause for the reasons you > > > > state. He requested we follow-up with additional questions and > > > > suggestions so I'm questioning and suggesting taking it a step > > > > further. We talk about rolling releases, but people are skeptical due > > > > to rawhide instability. What does it look like if the "rolling" > > > > happens on top of an otherwise stable platform where fundamentals like > > > > compilers, libraries and core system tools are held steady, but things > > > > on top move fast? Maybe you don't need an F30.1, maybe it means F30 > > > > just keeps getting nice incremental updates for as long as the > > > > editions want to stick with it. Variable lifecycle or cadence can > > > > open up these kinds of options. Some things are better fast. Some > > > > things are better slow. > > > > > > This. Yes This. +100 > > > > > > I think that Fedora's role as an innovater in the OS space means we > > > should be aggressively exploring this. Rolling Releases, Tech-Driven > > > Releases and Time-Based Releases all have well known positives and > > > negatives. All of the work that has been done on Modularity, > > > containers, flatpaks, OSTree, and more, gives us the opportunity to > > > really re-think this. While it is true there are dozens (or more) > > > additional solutions to the too-fast/too-slow and the > > > incompatible-libraries problems, these technologies seem to be gaining > > > the most adoption across a variety of use cases. They are all also > > > generally well supported in Fedora and we need to aggressively push > > > them to achieve this goal or determine where the dead-end is so we can > > > move to the next innovation. > > > > > > I personal am hugely in favor of us adopting a bootable-base model > > > that allows us to iterate the kernel and the various user-space pieces > > > at the speed of the upstream, the user's desires and the builder's > > > desires[^0] all at the same time. While this will require us to do > > > some level of NxM matrix building and testing, a base that didn't have > > > to change often for most use cases reduces the matrix considerably. > > > > The above doesn't make sense, you're saying "move as fast as upstream" > > and "a base that doesn't change" in the same context, which is it? > > I've failed to be clear - sorry about that. Let me try again. > > Please remember that I tend think from the lens of user space, not > kernel space. So there may be detail errors in this, I am hoping the > concepts are valid though. > > In general, I can run various versions of my applications against > multiple different kernels, for example. Therefore, if I have a > kernel that changed once a year, it isn't going to, for many > applications, stop me from changing versions multiple times during the > year. Therefore if Fedora had a stabilized bootable base, I could > move my applications at the cadence of upstream, or a stabilized > release (not at all) or at the speed in the middle I want. Fedora > might not build the entire range of that, but I am not prevented from > choosing amongst multiple Fedora provided options (stable vs devel or > all supported upstream releases, for example). So you mean that you want CentOS stable base and latest software you want? > The bootable base would change based on Fedora's needs. Perhaps we > decide want to new kernels (again sorry for my failings in this field) > every 6 months to introduce new drivers and hardware support. Someone > who wants faster can self-build for their community/needs more > frequently or a hardware vendor might want a kernel that doesn't > change as often and is backported. Fedora may not build the whole > range here either. > > > > I'd push Brendans' concept further and suggest that we try to > > > eliminate as many of the compilers, libraries and core system tools as > > > possible from this bootable-base so that those can iterate at their > > > own speed, perhaps 4 year for a laptop vendor and 30 day for a > > > experimental ARM device. Fedora as a project might not build output > > > for the whole range, but a build system that allowed us to help others > > > be successful would be a huge help here. > > > > Again what do you even mean by eliminate the compilers? Also how do we > > not change something core, such as a compiler, for 4 years while also > > change it every 30 days? > > "Eliminate the compilers" was meant to mean, make them modules or > non-bootable base components as much as possible. I realize that for > something like glibc that can be hard to impossible and for things > like Fortran a non-issue. > > Communities have different needs, and every time we
Re: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 12:12 PM Peter Robinson wrote: > > On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd > wrote: > > > > On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy wrote: > > > Paul's proposal was definitely a one-time pause for the reasons you > > > state. He requested we follow-up with additional questions and > > > suggestions so I'm questioning and suggesting taking it a step > > > further. We talk about rolling releases, but people are skeptical due > > > to rawhide instability. What does it look like if the "rolling" > > > happens on top of an otherwise stable platform where fundamentals like > > > compilers, libraries and core system tools are held steady, but things > > > on top move fast? Maybe you don't need an F30.1, maybe it means F30 > > > just keeps getting nice incremental updates for as long as the > > > editions want to stick with it. Variable lifecycle or cadence can > > > open up these kinds of options. Some things are better fast. Some > > > things are better slow. > > > > This. Yes This. +100 > > > > I think that Fedora's role as an innovater in the OS space means we > > should be aggressively exploring this. Rolling Releases, Tech-Driven > > Releases and Time-Based Releases all have well known positives and > > negatives. All of the work that has been done on Modularity, > > containers, flatpaks, OSTree, and more, gives us the opportunity to > > really re-think this. While it is true there are dozens (or more) > > additional solutions to the too-fast/too-slow and the > > incompatible-libraries problems, these technologies seem to be gaining > > the most adoption across a variety of use cases. They are all also > > generally well supported in Fedora and we need to aggressively push > > them to achieve this goal or determine where the dead-end is so we can > > move to the next innovation. > > > > I personal am hugely in favor of us adopting a bootable-base model > > that allows us to iterate the kernel and the various user-space pieces > > at the speed of the upstream, the user's desires and the builder's > > desires[^0] all at the same time. While this will require us to do > > some level of NxM matrix building and testing, a base that didn't have > > to change often for most use cases reduces the matrix considerably. > > The above doesn't make sense, you're saying "move as fast as upstream" > and "a base that doesn't change" in the same context, which is it? I've failed to be clear - sorry about that. Let me try again. Please remember that I tend think from the lens of user space, not kernel space. So there may be detail errors in this, I am hoping the concepts are valid though. In general, I can run various versions of my applications against multiple different kernels, for example. Therefore, if I have a kernel that changed once a year, it isn't going to, for many applications, stop me from changing versions multiple times during the year. Therefore if Fedora had a stabilized bootable base, I could move my applications at the cadence of upstream, or a stabilized release (not at all) or at the speed in the middle I want. Fedora might not build the entire range of that, but I am not prevented from choosing amongst multiple Fedora provided options (stable vs devel or all supported upstream releases, for example). The bootable base would change based on Fedora's needs. Perhaps we decide want to new kernels (again sorry for my failings in this field) every 6 months to introduce new drivers and hardware support. Someone who wants faster can self-build for their community/needs more frequently or a hardware vendor might want a kernel that doesn't change as often and is backported. Fedora may not build the whole range here either. > > I'd push Brendans' concept further and suggest that we try to > > eliminate as many of the compilers, libraries and core system tools as > > possible from this bootable-base so that those can iterate at their > > own speed, perhaps 4 year for a laptop vendor and 30 day for a > > experimental ARM device. Fedora as a project might not build output > > for the whole range, but a build system that allowed us to help others > > be successful would be a huge help here. > > Again what do you even mean by eliminate the compilers? Also how do we > not change something core, such as a compiler, for 4 years while also > change it every 30 days? "Eliminate the compilers" was meant to mean, make them modules or non-bootable base components as much as possible. I realize that for something like glibc that can be hard to impossible and for things like Fortran a non-issue. Communities have different needs, and every time we freeze or force change we create challenges for those needs to be met. My point is that by keeping our base to the "light up the machine level (another hated idiom) and get containers/flatpaks/etc running" we can allow the builder to focus on their community's needs or the user to get their own
Re: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd wrote: > > On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy wrote: > > Paul's proposal was definitely a one-time pause for the reasons you > > state. He requested we follow-up with additional questions and > > suggestions so I'm questioning and suggesting taking it a step > > further. We talk about rolling releases, but people are skeptical due > > to rawhide instability. What does it look like if the "rolling" > > happens on top of an otherwise stable platform where fundamentals like > > compilers, libraries and core system tools are held steady, but things > > on top move fast? Maybe you don't need an F30.1, maybe it means F30 > > just keeps getting nice incremental updates for as long as the > > editions want to stick with it. Variable lifecycle or cadence can > > open up these kinds of options. Some things are better fast. Some > > things are better slow. > > This. Yes This. +100 > > I think that Fedora's role as an innovater in the OS space means we > should be aggressively exploring this. Rolling Releases, Tech-Driven > Releases and Time-Based Releases all have well known positives and > negatives. All of the work that has been done on Modularity, > containers, flatpaks, OSTree, and more, gives us the opportunity to > really re-think this. While it is true there are dozens (or more) > additional solutions to the too-fast/too-slow and the > incompatible-libraries problems, these technologies seem to be gaining > the most adoption across a variety of use cases. They are all also > generally well supported in Fedora and we need to aggressively push > them to achieve this goal or determine where the dead-end is so we can > move to the next innovation. > > I personal am hugely in favor of us adopting a bootable-base model > that allows us to iterate the kernel and the various user-space pieces > at the speed of the upstream, the user's desires and the builder's > desires[^0] all at the same time. While this will require us to do > some level of NxM matrix building and testing, a base that didn't have > to change often for most use cases reduces the matrix considerably. The above doesn't make sense, you're saying "move as fast as upstream" and "a base that doesn't change" in the same context, which is it? > I'd push Brendans' concept further and suggest that we try to > eliminate as many of the compilers, libraries and core system tools as > possible from this bootable-base so that those can iterate at their > own speed, perhaps 4 year for a laptop vendor and 30 day for a > experimental ARM device. Fedora as a project might not build output > for the whole range, but a build system that allowed us to help others > be successful would be a huge help here. Again what do you even mean by eliminate the compilers? Also how do we not change something core, such as a compiler, for 4 years while also change it every 30 days? > I recognize that I, like most people, see the world through the lens > of my specific use case, but remember, "Fedora creates an innovative > platform for hardware, clouds, and containers that enables software > developers and community members to build tailored solutions for their > users." As long as we don't block a use cases arbitrarily and we > leave room for that innovation and service we are doing the right > thing. The debate about what use cases should be done fully by > Fedora, enabled for a SIG/WG via our build system or done externally > by those using only the parts that make sense for them is a separate > debate. I agree on some of your points above, but TBH most of it reads like some form of marketing coolaid! Also it does account at all for any and/or all of the resources that we'd need to even enact some of this, even if it's possible? > 0: Builder's desires are the desires of the person who put the entire > system together to fulfill the needs of their community per our > mission statement. If my mythical llama herders need the oldest Libre > Office possible but the newest Rust packaging and whatever random > version of httpd that Fedora deems "stable", then that is what I > desire, even if the upstream or other non-llama herding users desire > something different. However, I'd also push that we should try to > reach a point where if a llama herder for non-llama reasons needs a > different httpd, they can just enable and use it (using the language > of modularity). In case it isn't clear, the "builder's desires" > includes the goals of every current lab, spin, and edition, separately > and where appropriate together. > ___ > 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: >
Re: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy wrote: > Paul's proposal was definitely a one-time pause for the reasons you > state. He requested we follow-up with additional questions and > suggestions so I'm questioning and suggesting taking it a step > further. We talk about rolling releases, but people are skeptical due > to rawhide instability. What does it look like if the "rolling" > happens on top of an otherwise stable platform where fundamentals like > compilers, libraries and core system tools are held steady, but things > on top move fast? Maybe you don't need an F30.1, maybe it means F30 > just keeps getting nice incremental updates for as long as the > editions want to stick with it. Variable lifecycle or cadence can > open up these kinds of options. Some things are better fast. Some > things are better slow. This. Yes This. +100 I think that Fedora's role as an innovater in the OS space means we should be aggressively exploring this. Rolling Releases, Tech-Driven Releases and Time-Based Releases all have well known positives and negatives. All of the work that has been done on Modularity, containers, flatpaks, OSTree, and more, gives us the opportunity to really re-think this. While it is true there are dozens (or more) additional solutions to the too-fast/too-slow and the incompatible-libraries problems, these technologies seem to be gaining the most adoption across a variety of use cases. They are all also generally well supported in Fedora and we need to aggressively push them to achieve this goal or determine where the dead-end is so we can move to the next innovation. I personal am hugely in favor of us adopting a bootable-base model that allows us to iterate the kernel and the various user-space pieces at the speed of the upstream, the user's desires and the builder's desires[^0] all at the same time. While this will require us to do some level of NxM matrix building and testing, a base that didn't have to change often for most use cases reduces the matrix considerably. I'd push Brendans' concept further and suggest that we try to eliminate as many of the compilers, libraries and core system tools as possible from this bootable-base so that those can iterate at their own speed, perhaps 4 year for a laptop vendor and 30 day for a experimental ARM device. Fedora as a project might not build output for the whole range, but a build system that allowed us to help others be successful would be a huge help here. I recognize that I, like most people, see the world through the lens of my specific use case, but remember, "Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users." As long as we don't block a use cases arbitrarily and we leave room for that innovation and service we are doing the right thing. The debate about what use cases should be done fully by Fedora, enabled for a SIG/WG via our build system or done externally by those using only the parts that make sense for them is a separate debate. regards, bex 0: Builder's desires are the desires of the person who put the entire system together to fulfill the needs of their community per our mission statement. If my mythical llama herders need the oldest Libre Office possible but the newest Rust packaging and whatever random version of httpd that Fedora deems "stable", then that is what I desire, even if the upstream or other non-llama herding users desire something different. However, I'd also push that we should try to reach a point where if a llama herder for non-llama reasons needs a different httpd, they can just enable and use it (using the language of modularity). In case it isn't clear, the "builder's desires" includes the goals of every current lab, spin, and edition, separately and where appropriate together. ___ 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: Proposal: Move to an annual platform release starting at F30
On 11/28/18 1:32 AM, Kevin Fenzi wrote: I agree with the folks in this subthread, but I think we are going to have to look at 'redesigning' things more than just 'optimizing'. +1. At the same time, we should also ensure that Devel,QE,Infra,RelEng.. all equal stake holders and are hand in glove with the new design and not fall into their own silo. ie, collect all our inputs and outputs and things we need to do in the process and figure out how to make it modular (no relation) so we can look at just a single changed input and quickly test and generate all the outputs that are affected by that input (and not any of the others). For example, a new xfce4-settings package comes out, we want to test it, test the Xfce live media and if it all passes, perhaps release that media. It may well be that we can figure out a 'base platform' just by looking at these imput/outputs: what things are in most or all outputs? kevin ___ 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: Proposal: Move to an annual platform release starting at F30
On 11/27/18 11:39 AM, Owen Taylor wrote: We can definitely talk about whether moving to a slower cadence for certain parts of the base platform. But people don't judge Fedora on how beautifully we maintain glibc and gcc - they mostly judge it by installing it on a laptop and seeing how well it works. And it doesn't really matter how reliably we can create minimal container images if the workstation image doesn't compose or doesn't log in. It's true that the #1 use case for Fedora is the desktop, but that isn't all Fedora is used for. If Fedora is going to continue to grow it needs to serve more uses. At the same time it needs to keep doing a great job as a desktop- so we have to look at solutions that promote both. How beautifully we maintain platform pieces like gcc, glibc, and other commonly used shared libraries is actually tremendously important to many users, to many developers, because it affects their ability to adopt Fedora as a base to do the things they want to do. We need clear naming for the workstation releases we do. If we want to call them F30, F30.1, F31, F31.1 we can, but that doesn't inherently reduce load on releng or remove the need for infrastructure freezes ... my assumption was that the idea of delaying F31 is to actually *not* do an operating system release for a year, and that's something that I don't think we should do on an ongoing basis. Paul's proposal was definitely a one-time pause for the reasons you state. He requested we follow-up with additional questions and suggestions so I'm questioning and suggesting taking it a step further. We talk about rolling releases, but people are skeptical due to rawhide instability. What does it look like if the "rolling" happens on top of an otherwise stable platform where fundamentals like compilers, libraries and core system tools are held steady, but things on top move fast? Maybe you don't need an F30.1, maybe it means F30 just keeps getting nice incremental updates for as long as the editions want to stick with it. Variable lifecycle or cadence can open up these kinds of options. Some things are better fast. Some things are better slow. Owen On Tue, Nov 27, 2018 at 1:19 PM Brendan Conoboy wrote: On 11/27/18 10:13 AM, Josh Boyer wrote: On Tue, Nov 27, 2018 at 11:21 AM Owen Taylor wrote: On Tue, Nov 27, 2018 at 11:05 AM Josh Boyer wrote: On Tue, Nov 27, 2018 at 10:13 AM Owen Taylor wrote: But for the next thousand or so Fedora developers, the release cycle is actually not a big deal - not something that takes much of their time - and it gives them a regular place to land feature work. And Fedora users appreciate a timely updated operating system (without having random rebases trickle in.) It's not a big deal because they don't participate in making the release nor do they really know about all the duct tape and bailing wire holding all the machinery in place. Just like most of them don't appreciate the heroics involved from Fedora QA and rel-eng and the dozen or so people that regularly go well beyond the extra mile to get it out the door. This isn't done out of malice on their part. It's mostly that they just don't see it. If we distribute this work out across the 1000 developers, we'll make life better for heroes, and it's *still* not going to be a big deal for the 1000 developers. I would say it will be a learning curve and there will be complaints because it's change and people seem to only want change if it's the change they want or otherwise doesn't impact them. That's going to be a big deal to some :) Generally though, yes. We need to distribute the burden to the package sets and whomever maintains them. In other words, the "technical debt" we are trying to solve here is not project wide and doesn't justify slowing down the whole project permanently. I completely disagree. Our release process and tooling is built on heroism and tech debt. At some point, that is going to cause significant burnout and then people will just wonder what happened when those people stop doing releases. I think it's better to raise awareness at the project level, and build something that is sustainable rather than predicated on "small group of people killing themselves for the greater good". That starts with individual package CI gating, and goes all the way through integration testing between packages in a gated manner, into how we actually *create* all of that plus the things we deem worth of releasing. I think you are misunderstanding me somehow. I'm 100% on-board with improving the processes, catching compose problems in an automated and early fashion, making developers fix their own problems, and generally making releases a less heroic process. And if that requires a temporary cadence chance to get the retooling done, then it's worth it. Ah, good! But Brendan's proposal to permanently slow down the cadence seems to make the assumption that the current release cycle is a
Re: Proposal: Move to an annual platform release starting at F30
On 11/27/2018 10:39 AM, Owen Taylor wrote: We can definitely talk about whether moving to a slower cadence for certain parts of the base platform. But people don't judge Fedora on how beautifully we maintain glibc and gcc - they mostly judge it by installing it on a laptop and seeing how well it works. And it doesn't really matter how reliably we can create minimal container images if the workstation image doesn't compose or doesn't log in. I'm not sure that that's fair. I mean, I judge Fedora on how much its features are likely to cause problems 9-36 months down the road in an EL release... or now, in the case of cross-distro integration and support. I could care less about GNOME, but care very much about gcc, glibc, the kernel, and packaging of libraries. *Laptop users* certainly judge Fedora on how well it works on laptops, and Workstation environment users judge Fedora on the Workstation spin. Any other statement would pre-suppose the exact answers this and related discussion would seem to be working towards. -jc ___ 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: Proposal: Move to an annual platform release starting at F30
I agree with the folks in this subthread, but I think we are going to have to look at 'redesigning' things more than just 'optimizing'. ie, collect all our inputs and outputs and things we need to do in the process and figure out how to make it modular (no relation) so we can look at just a single changed input and quickly test and generate all the outputs that are affected by that input (and not any of the others). For example, a new xfce4-settings package comes out, we want to test it, test the Xfce live media and if it all passes, perhaps release that media. It may well be that we can figure out a 'base platform' just by looking at these imput/outputs: what things are in most or all outputs? 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: Proposal: Move to an annual platform release starting at F30
On Tue, Nov 27, 2018 at 1:40 PM Owen Taylor wrote: > > We can definitely talk about whether moving to a slower cadence for > certain parts of the base platform. But people don't judge Fedora on > how beautifully we maintain glibc and gcc - they mostly judge it by > installing it on a laptop and seeing how well it works. And it doesn't > really matter how reliably we can create minimal container images if > the workstation image doesn't compose or doesn't log in. > > We need clear naming for the workstation releases we do. If we want to > call them F30, F30.1, F31, F31.1 we can, but that doesn't inherently > reduce load on releng or remove the need for infrastructure freezes > ... my assumption was that the idea of delaying F31 is to actually > *not* do an operating system release for a year, and that's something > that I don't think we should do on an ongoing basis. Heard, understood, and agreed. Shortening the compose is a root problem to fix if we want to be able to judge reliability of what we want to release. That way we can test it more or less constantly. As for freezes... right now we freeze for a total of roughly 2-3 months out of 12. We can avoid that with a pause -- at least in part, and maybe in total if we finish enough work to minimize freeze coming out of it. That's why taking the break makes sense. Reclaiming that time, year after year, should be a knock-on effect of being able to release more frequently as a non-event. Then there's less (maybe no) reason to freeze -- the worst thing that happens is we pull the lever the next day. So a healthy part of our investment should be in minimizing recovery time. -- Paul ___ 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: Proposal: Move to an annual platform release starting at F30
On Tue, Nov 27, 2018 at 12:19 PM Josh Boyer wrote: > On Tue, Nov 27, 2018 at 11:21 AM Owen Taylor wrote: > > On Tue, Nov 27, 2018 at 11:05 AM Josh Boyer > > wrote: [...snip...] > > > I completely disagree. Our release process and tooling is built on > > > heroism and tech debt. At some point, that is going to cause > > > significant burnout and then people will just wonder what happened > > > when those people stop doing releases. I think it's better to raise > > > awareness at the project level, and build something that is > > > sustainable rather than predicated on "small group of people killing > > > themselves for the greater good". That starts with individual package > > > CI gating, and goes all the way through integration testing between > > > packages in a gated manner, into how we actually *create* all of that > > > plus the things we deem worth of releasing. > > > > I think you are misunderstanding me somehow. I'm 100% on-board with > > improving the processes, catching compose problems in an automated and > > early fashion, making developers fix their own problems, and generally > > making releases a less heroic process. And if that requires a > > temporary cadence chance to get the retooling done, then it's worth > > it. > > Ah, good! > > > But Brendan's proposal to permanently slow down the cadence seems to > > make the assumption that the current release cycle is a heroic effort > > for the entire project - that we're moving too fast to stay on our > > feet. And I don't think that's the case. > > That would be a concern to me as well, assuming we stuck with a > *single* cadence and a *single* platform. With the lifecycle > Objective, aren't we targeting multiple cadences and lifecycles? I > mean, we have this today with Fedora Atomic/CoreOS vs. "regular" > Fedora. Maybe Brendan was thinking singular, but I would very much > like the ability in our tooling a process to have both the faster > moving cadence of today AND a slower moving one. That's another > reason I view a temporary halt as worthwhile. If done correctly, it > enables Fedora to fill more usecases and lifecycles than we could ever > accomplish with a single release. Josh and Owen both have it basically right IMHO. Speeding up the compose, increasing automation, and making it easier for people beyond the core crew to do releases all should allow us to make releases less of a big deal. I would love to get closer to the ostree release (both in terms of content, and cycle) for the majority of current users. That means faster, not slower releases -- and that "release" should be more like a non-event for most people. Not to mention the benefits of being able to revert the platform in case of a problem, etc. But I also agree that a longer cycle can have a place too. The tricky part is to make sure that doesn't turn into multi-stream pain for the proverbial "1000 packagers" group. There should be a way to set the cycle and the overlap to minimize pain. (And I suspect modularity also helps somewhat here.) Take an average packager who cares about long-term. They may have to maintain 5+ streams now if you count EPEL. We want an outcome that is arguably better, or at least no worse. (No, we really want better.) ;-) -- Paul ___ 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: Proposal: Move to an annual platform release starting at F30
We can definitely talk about whether moving to a slower cadence for certain parts of the base platform. But people don't judge Fedora on how beautifully we maintain glibc and gcc - they mostly judge it by installing it on a laptop and seeing how well it works. And it doesn't really matter how reliably we can create minimal container images if the workstation image doesn't compose or doesn't log in. We need clear naming for the workstation releases we do. If we want to call them F30, F30.1, F31, F31.1 we can, but that doesn't inherently reduce load on releng or remove the need for infrastructure freezes ... my assumption was that the idea of delaying F31 is to actually *not* do an operating system release for a year, and that's something that I don't think we should do on an ongoing basis. Owen On Tue, Nov 27, 2018 at 1:19 PM Brendan Conoboy wrote: > > On 11/27/18 10:13 AM, Josh Boyer wrote: > > On Tue, Nov 27, 2018 at 11:21 AM Owen Taylor wrote: > >> > >> On Tue, Nov 27, 2018 at 11:05 AM Josh Boyer > >> wrote: > >>> On Tue, Nov 27, 2018 at 10:13 AM Owen Taylor wrote: > But for the next thousand or so Fedora developers, the release cycle > is actually not a big deal - not something that takes much of their > time - and it gives them a regular place to land feature work. And > Fedora users appreciate a timely updated operating system (without > having random rebases trickle in.) > >>> > >>> It's not a big deal because they don't participate in making the > >>> release nor do they really know about all the duct tape and bailing > >>> wire holding all the machinery in place. Just like most of them don't > >>> appreciate the heroics involved from Fedora QA and rel-eng and the > >>> dozen or so people that regularly go well beyond the extra mile to get > >>> it out the door. This isn't done out of malice on their part. It's > >>> mostly that they just don't see it. > >> > >> If we distribute this work out across the 1000 developers, we'll make > >> life better for heroes, and it's *still* not going to be a big deal > >> for the 1000 developers. > > > > I would say it will be a learning curve and there will be complaints > > because it's change and people seem to only want change if it's the > > change they want or otherwise doesn't impact them. That's going to be > > a big deal to some :) Generally though, yes. We need to distribute > > the burden to the package sets and whomever maintains them. > > > In other words, the "technical debt" we are trying to solve here is > not project wide and doesn't justify slowing down the whole project > permanently. > >>> > >>> I completely disagree. Our release process and tooling is built on > >>> heroism and tech debt. At some point, that is going to cause > >>> significant burnout and then people will just wonder what happened > >>> when those people stop doing releases. I think it's better to raise > >>> awareness at the project level, and build something that is > >>> sustainable rather than predicated on "small group of people killing > >>> themselves for the greater good". That starts with individual package > >>> CI gating, and goes all the way through integration testing between > >>> packages in a gated manner, into how we actually *create* all of that > >>> plus the things we deem worth of releasing. > >> > >> I think you are misunderstanding me somehow. I'm 100% on-board with > >> improving the processes, catching compose problems in an automated and > >> early fashion, making developers fix their own problems, and generally > >> making releases a less heroic process. And if that requires a > >> temporary cadence chance to get the retooling done, then it's worth > >> it. > > > > Ah, good! > > > >> But Brendan's proposal to permanently slow down the cadence seems to > >> make the assumption that the current release cycle is a heroic effort > >> for the entire project - that we're moving too fast to stay on our > >> feet. And I don't think that's the case. > > > > That would be a concern to me as well, assuming we stuck with a > > *single* cadence and a *single* platform. With the lifecycle > > Objective, aren't we targeting multiple cadences and lifecycles? I > > mean, we have this today with Fedora Atomic/CoreOS vs. "regular" > > Fedora. Maybe Brendan was thinking singular, but I would very much > > like the ability in our tooling a process to have both the faster > > moving cadence of today AND a slower moving one. That's another > > reason I view a temporary halt as worthwhile. If done correctly, it > > enables Fedora to fill more usecases and lifecycles than we could ever > > accomplish with a single release. > > Josh has it: I am indeed thinking about how this works with the > lifecycle objective. When we think about things as all or nothing we > rapidly get into a zero sum game: Let's make this part of Fedora worse > to make this other part better. We don't have to do that, we can just > make
Re: Proposal: Move to an annual platform release starting at F30
On 11/27/18 10:13 AM, Josh Boyer wrote: On Tue, Nov 27, 2018 at 11:21 AM Owen Taylor wrote: On Tue, Nov 27, 2018 at 11:05 AM Josh Boyer wrote: On Tue, Nov 27, 2018 at 10:13 AM Owen Taylor wrote: But for the next thousand or so Fedora developers, the release cycle is actually not a big deal - not something that takes much of their time - and it gives them a regular place to land feature work. And Fedora users appreciate a timely updated operating system (without having random rebases trickle in.) It's not a big deal because they don't participate in making the release nor do they really know about all the duct tape and bailing wire holding all the machinery in place. Just like most of them don't appreciate the heroics involved from Fedora QA and rel-eng and the dozen or so people that regularly go well beyond the extra mile to get it out the door. This isn't done out of malice on their part. It's mostly that they just don't see it. If we distribute this work out across the 1000 developers, we'll make life better for heroes, and it's *still* not going to be a big deal for the 1000 developers. I would say it will be a learning curve and there will be complaints because it's change and people seem to only want change if it's the change they want or otherwise doesn't impact them. That's going to be a big deal to some :) Generally though, yes. We need to distribute the burden to the package sets and whomever maintains them. In other words, the "technical debt" we are trying to solve here is not project wide and doesn't justify slowing down the whole project permanently. I completely disagree. Our release process and tooling is built on heroism and tech debt. At some point, that is going to cause significant burnout and then people will just wonder what happened when those people stop doing releases. I think it's better to raise awareness at the project level, and build something that is sustainable rather than predicated on "small group of people killing themselves for the greater good". That starts with individual package CI gating, and goes all the way through integration testing between packages in a gated manner, into how we actually *create* all of that plus the things we deem worth of releasing. I think you are misunderstanding me somehow. I'm 100% on-board with improving the processes, catching compose problems in an automated and early fashion, making developers fix their own problems, and generally making releases a less heroic process. And if that requires a temporary cadence chance to get the retooling done, then it's worth it. Ah, good! But Brendan's proposal to permanently slow down the cadence seems to make the assumption that the current release cycle is a heroic effort for the entire project - that we're moving too fast to stay on our feet. And I don't think that's the case. That would be a concern to me as well, assuming we stuck with a *single* cadence and a *single* platform. With the lifecycle Objective, aren't we targeting multiple cadences and lifecycles? I mean, we have this today with Fedora Atomic/CoreOS vs. "regular" Fedora. Maybe Brendan was thinking singular, but I would very much like the ability in our tooling a process to have both the faster moving cadence of today AND a slower moving one. That's another reason I view a temporary halt as worthwhile. If done correctly, it enables Fedora to fill more usecases and lifecycles than we could ever accomplish with a single release. Josh has it: I am indeed thinking about how this works with the lifecycle objective. When we think about things as all or nothing we rapidly get into a zero sum game: Let's make this part of Fedora worse to make this other part better. We don't have to do that, we can just make Fedora better. That's what having multiple cadences and lifecycles is all about. So it is important to talk about how the rules would change if F30 takes a year, because if the rules don't change it might diminish one of the great things about Fedora. -- 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: Proposal: Move to an annual platform release starting at F30
On 11/27/18 7:54 AM, Ben Cotton wrote: On Tue, Nov 27, 2018 at 8:21 AM Justin Forbes wrote: Long cycles have been done before, and will be done again, it has been 4 or 5 years since the last one. I think skipping to a yearly cadence for every release isn't such a great idea. There are benefits to the cadence we have, but I do think perhaps a plan to regularly do this might be a good thing. Agreed. Doing a long cycle is a tradeoff. In general, the six month cycle works for what we're trying to do. But having the occasional long cycle gives us some space to work on bigger projects or things that can't be done while we're also trying to get a release out the door. With unlimited funding and people, we wouldn't have to make this tradeoff, but we do have limits. I'm sympathetic to the argument that we should do it as needed, but my preference is to schedule it. This allows our community to plan ahead, both for the work to be done during the long cycle and also for things that should get done before and after. Predictability is helpful. If we do say, for example, every 8th release will be a long cycle there's nothing that would prevent us from doing an unscheduled long cycle if we have to. But it would have to be a very compelling reason knowing that we'd have another long release coming up. The other way to slice it is having some parts of the distribution be on a longer cycle and others on a shorter cycle. If there is a 1 year gap between F30 and F31, perhaps the rules for what can be updated in F30 could be revised to maintain the value people get from the 6 month release cycle. -- 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: Proposal: Move to an annual platform release starting at F30
On Tue, Nov 27, 2018 at 11:21 AM Owen Taylor wrote: > > On Tue, Nov 27, 2018 at 11:05 AM Josh Boyer wrote: > > On Tue, Nov 27, 2018 at 10:13 AM Owen Taylor wrote: > > > But for the next thousand or so Fedora developers, the release cycle > > > is actually not a big deal - not something that takes much of their > > > time - and it gives them a regular place to land feature work. And > > > Fedora users appreciate a timely updated operating system (without > > > having random rebases trickle in.) > > > > It's not a big deal because they don't participate in making the > > release nor do they really know about all the duct tape and bailing > > wire holding all the machinery in place. Just like most of them don't > > appreciate the heroics involved from Fedora QA and rel-eng and the > > dozen or so people that regularly go well beyond the extra mile to get > > it out the door. This isn't done out of malice on their part. It's > > mostly that they just don't see it. > > If we distribute this work out across the 1000 developers, we'll make > life better for heroes, and it's *still* not going to be a big deal > for the 1000 developers. I would say it will be a learning curve and there will be complaints because it's change and people seem to only want change if it's the change they want or otherwise doesn't impact them. That's going to be a big deal to some :) Generally though, yes. We need to distribute the burden to the package sets and whomever maintains them. > > > In other words, the "technical debt" we are trying to solve here is > > > not project wide and doesn't justify slowing down the whole project > > > permanently. > > > > I completely disagree. Our release process and tooling is built on > > heroism and tech debt. At some point, that is going to cause > > significant burnout and then people will just wonder what happened > > when those people stop doing releases. I think it's better to raise > > awareness at the project level, and build something that is > > sustainable rather than predicated on "small group of people killing > > themselves for the greater good". That starts with individual package > > CI gating, and goes all the way through integration testing between > > packages in a gated manner, into how we actually *create* all of that > > plus the things we deem worth of releasing. > > I think you are misunderstanding me somehow. I'm 100% on-board with > improving the processes, catching compose problems in an automated and > early fashion, making developers fix their own problems, and generally > making releases a less heroic process. And if that requires a > temporary cadence chance to get the retooling done, then it's worth > it. Ah, good! > But Brendan's proposal to permanently slow down the cadence seems to > make the assumption that the current release cycle is a heroic effort > for the entire project - that we're moving too fast to stay on our > feet. And I don't think that's the case. That would be a concern to me as well, assuming we stuck with a *single* cadence and a *single* platform. With the lifecycle Objective, aren't we targeting multiple cadences and lifecycles? I mean, we have this today with Fedora Atomic/CoreOS vs. "regular" Fedora. Maybe Brendan was thinking singular, but I would very much like the ability in our tooling a process to have both the faster moving cadence of today AND a slower moving one. That's another reason I view a temporary halt as worthwhile. If done correctly, it enables Fedora to fill more usecases and lifecycles than we could ever accomplish with a single release. 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: Proposal: Move to an annual platform release starting at F30
On Tue, 27 Nov 2018 at 17:23, Owen Taylor wrote: > > On Tue, Nov 27, 2018 at 11:05 AM Josh Boyer wrote: > > On Tue, Nov 27, 2018 at 10:13 AM Owen Taylor wrote: > > > But for the next thousand or so Fedora developers, the release cycle > > > is actually not a big deal - not something that takes much of their > > > time - and it gives them a regular place to land feature work. And > > > Fedora users appreciate a timely updated operating system (without > > > having random rebases trickle in.) > > > > It's not a big deal because they don't participate in making the > > release nor do they really know about all the duct tape and bailing > > wire holding all the machinery in place. Just like most of them don't > > appreciate the heroics involved from Fedora QA and rel-eng and the > > dozen or so people that regularly go well beyond the extra mile to get > > it out the door. This isn't done out of malice on their part. It's > > mostly that they just don't see it. > > If we distribute this work out across the 1000 developers, we'll make > life better for heroes, and it's *still* not going to be a big deal > for the 1000 developers. I think this is another important problem we have, it is very difficult for someone interested to help in these domains. So we end up with a dozen of persons being heroic because they are actually the one that have the correct permissions and knowledge to do most of the work. We should definitely look at solving this problem. > > > > In other words, the "technical debt" we are trying to solve here is > > > not project wide and doesn't justify slowing down the whole project > > > permanently. > > > > I completely disagree. Our release process and tooling is built on > > heroism and tech debt. At some point, that is going to cause > > significant burnout and then people will just wonder what happened > > when those people stop doing releases. I think it's better to raise > > awareness at the project level, and build something that is > > sustainable rather than predicated on "small group of people killing > > themselves for the greater good". That starts with individual package > > CI gating, and goes all the way through integration testing between > > packages in a gated manner, into how we actually *create* all of that > > plus the things we deem worth of releasing. > > I think you are misunderstanding me somehow. I'm 100% on-board with > improving the processes, catching compose problems in an automated and > early fashion, making developers fix their own problems, and generally > making releases a less heroic process. And if that requires a > temporary cadence chance to get the retooling done, then it's worth > it. > > But Brendan's proposal to permanently slow down the cadence seems to > make the assumption that the current release cycle is a heroic effort > for the entire project - that we're moving too fast to stay on our > feet. And I don't think that's the case. > > Owen > ___ > 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: Proposal: Move to an annual platform release starting at F30
On Tue, Nov 27, 2018 at 11:05 AM Josh Boyer wrote: > On Tue, Nov 27, 2018 at 10:13 AM Owen Taylor wrote: > > But for the next thousand or so Fedora developers, the release cycle > > is actually not a big deal - not something that takes much of their > > time - and it gives them a regular place to land feature work. And > > Fedora users appreciate a timely updated operating system (without > > having random rebases trickle in.) > > It's not a big deal because they don't participate in making the > release nor do they really know about all the duct tape and bailing > wire holding all the machinery in place. Just like most of them don't > appreciate the heroics involved from Fedora QA and rel-eng and the > dozen or so people that regularly go well beyond the extra mile to get > it out the door. This isn't done out of malice on their part. It's > mostly that they just don't see it. If we distribute this work out across the 1000 developers, we'll make life better for heroes, and it's *still* not going to be a big deal for the 1000 developers. > > In other words, the "technical debt" we are trying to solve here is > > not project wide and doesn't justify slowing down the whole project > > permanently. > > I completely disagree. Our release process and tooling is built on > heroism and tech debt. At some point, that is going to cause > significant burnout and then people will just wonder what happened > when those people stop doing releases. I think it's better to raise > awareness at the project level, and build something that is > sustainable rather than predicated on "small group of people killing > themselves for the greater good". That starts with individual package > CI gating, and goes all the way through integration testing between > packages in a gated manner, into how we actually *create* all of that > plus the things we deem worth of releasing. I think you are misunderstanding me somehow. I'm 100% on-board with improving the processes, catching compose problems in an automated and early fashion, making developers fix their own problems, and generally making releases a less heroic process. And if that requires a temporary cadence chance to get the retooling done, then it's worth it. But Brendan's proposal to permanently slow down the cadence seems to make the assumption that the current release cycle is a heroic effort for the entire project - that we're moving too fast to stay on our feet. And I don't think that's the case. Owen ___ 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: Proposal: Move to an annual platform release starting at F30
On Tue, Nov 27, 2018 at 10:13 AM Owen Taylor wrote: > > On Mon, Nov 26, 2018 at 9:26 PM Brendan Conoboy wrote:> > > On 11/16/18 7:50 AM, Paul Frields wrote: > > [snip] > > > We should skip the F31 release cycle and leave F30 in place longer in > > > order to focus on improving the tooling and testing changes. These > > > tooling changes will improve the overall reliability of Fedora, and > > > will decrease the manual effort and complexities involved in producing > > > the distribution artifacts. Although we’ve done this before to make > > > “editions” happen, the intent is to track this multi-team effort more > > > actively so we can (1) use the time as well as possible, and (2) give > > > the work maximum transparency. > > > > If there is going to be a pause F30 seems like a good place to do it: > > New glibc, new compiler- and a full year for them to mature. It's a > > nice basis for a stable platform. What would the update policy be for > > this year- same as today? It seems like you're proposing this as a > > one-time event to pay down technical debt, which is great, but would > > you perhaps consider doing the same thing for F31, F32, etc? The > > basic reasons for technical debt will continue- why not plan to > > service the debt regularly? > > If we go ahead and skip the F31 release, I see this as a (perhaps > necessary) desperation move - there is a small group of a dozen or so > people who would be key to improving our release processes, but those > people are always busy making releases. > > But for the next thousand or so Fedora developers, the release cycle > is actually not a big deal - not something that takes much of their > time - and it gives them a regular place to land feature work. And > Fedora users appreciate a timely updated operating system (without > having random rebases trickle in.) It's not a big deal because they don't participate in making the release nor do they really know about all the duct tape and bailing wire holding all the machinery in place. Just like most of them don't appreciate the heroics involved from Fedora QA and rel-eng and the dozen or so people that regularly go well beyond the extra mile to get it out the door. This isn't done out of malice on their part. It's mostly that they just don't see it. > In other words, the "technical debt" we are trying to solve here is > not project wide and doesn't justify slowing down the whole project > permanently. I completely disagree. Our release process and tooling is built on heroism and tech debt. At some point, that is going to cause significant burnout and then people will just wonder what happened when those people stop doing releases. I think it's better to raise awareness at the project level, and build something that is sustainable rather than predicated on "small group of people killing themselves for the greater good". That starts with individual package CI gating, and goes all the way through integration testing between packages in a gated manner, into how we actually *create* all of that plus the things we deem worth of releasing. 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: Proposal: Move to an annual platform release starting at F30
On Mon, Nov 26, 2018 at 9:26 PM Brendan Conoboy wrote:> > On 11/16/18 7:50 AM, Paul Frields wrote: > [snip] > > We should skip the F31 release cycle and leave F30 in place longer in > > order to focus on improving the tooling and testing changes. These > > tooling changes will improve the overall reliability of Fedora, and > > will decrease the manual effort and complexities involved in producing > > the distribution artifacts. Although we’ve done this before to make > > “editions” happen, the intent is to track this multi-team effort more > > actively so we can (1) use the time as well as possible, and (2) give > > the work maximum transparency. > > If there is going to be a pause F30 seems like a good place to do it: > New glibc, new compiler- and a full year for them to mature. It's a > nice basis for a stable platform. What would the update policy be for > this year- same as today? It seems like you're proposing this as a > one-time event to pay down technical debt, which is great, but would > you perhaps consider doing the same thing for F31, F32, etc? The > basic reasons for technical debt will continue- why not plan to > service the debt regularly? If we go ahead and skip the F31 release, I see this as a (perhaps necessary) desperation move - there is a small group of a dozen or so people who would be key to improving our release processes, but those people are always busy making releases. But for the next thousand or so Fedora developers, the release cycle is actually not a big deal - not something that takes much of their time - and it gives them a regular place to land feature work. And Fedora users appreciate a timely updated operating system (without having random rebases trickle in.) In other words, the "technical debt" we are trying to solve here is not project wide and doesn't justify slowing down the whole project permanently. - Owen ___ 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: Proposal: Move to an annual platform release starting at F30
On Tue, Nov 27, 2018 at 8:21 AM Justin Forbes wrote: > > Long cycles have been done before, and will be done again, it has been > 4 or 5 years since the last one. I think skipping to a yearly cadence > for every release isn't such a great idea. There are benefits to the > cadence we have, but I do think perhaps a plan to regularly do this > might be a good thing. Agreed. Doing a long cycle is a tradeoff. In general, the six month cycle works for what we're trying to do. But having the occasional long cycle gives us some space to work on bigger projects or things that can't be done while we're also trying to get a release out the door. With unlimited funding and people, we wouldn't have to make this tradeoff, but we do have limits. I'm sympathetic to the argument that we should do it as needed, but my preference is to schedule it. This allows our community to plan ahead, both for the work to be done during the long cycle and also for things that should get done before and after. Predictability is helpful. If we do say, for example, every 8th release will be a long cycle there's nothing that would prevent us from doing an unscheduled long cycle if we have to. But it would have to be a very compelling reason knowing that we'd have another long release coming up. -- 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: Proposal: Move to an annual platform release starting at F30
On Mon, Nov 26, 2018 at 8:26 PM Brendan Conoboy wrote: > > On 11/16/18 7:50 AM, Paul Frields wrote: > [snip] > > We should skip the F31 release cycle and leave F30 in place longer in > > order to focus on improving the tooling and testing changes. These > > tooling changes will improve the overall reliability of Fedora, and > > will decrease the manual effort and complexities involved in producing > > the distribution artifacts. Although we’ve done this before to make > > “editions” happen, the intent is to track this multi-team effort more > > actively so we can (1) use the time as well as possible, and (2) give > > the work maximum transparency. > > If there is going to be a pause F30 seems like a good place to do it: > New glibc, new compiler- and a full year for them to mature. It's a > nice basis for a stable platform. What would the update policy be for > this year- same as today? It seems like you're proposing this as a > one-time event to pay down technical debt, which is great, but would > you perhaps consider doing the same thing for F31, F32, etc? The > basic reasons for technical debt will continue- why not plan to > service the debt regularly? > Long cycles have been done before, and will be done again, it has been 4 or 5 years since the last one. I think skipping to a yearly cadence for every release isn't such a great idea. There are benefits to the cadence we have, but I do think perhaps a plan to regularly do this might be a good thing. Just as a ballpark, perhaps once every 5 releases. This would allow people to actually plan the big workloads for this timeframe. F30 is a 1 year, the next is F35. Once F31 is done, I can start planning the big project for F36. Of course it could also be argued that we only do a long release when needed, but this doesn't really allow us to plan as well, and doesn't set expectations for the community in the same way. Justin ___ 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: Proposal: Move to an annual platform release starting at F30
On Mon, Nov 26, 2018 at 9:27 PM Brendan Conoboy wrote: > > On 11/16/18 7:50 AM, Paul Frields wrote: > [snip] > > We should skip the F31 release cycle and leave F30 in place longer in > > order to focus on improving the tooling and testing changes. These > > tooling changes will improve the overall reliability of Fedora, and > > will decrease the manual effort and complexities involved in producing > > the distribution artifacts. Although we’ve done this before to make > > “editions” happen, the intent is to track this multi-team effort more > > actively so we can (1) use the time as well as possible, and (2) give > > the work maximum transparency. > > If there is going to be a pause F30 seems like a good place to do it: > New glibc, new compiler- and a full year for them to mature. It's a > nice basis for a stable platform. What would the update policy be for > this year- same as today? It seems like you're proposing this as a > one-time event to pay down technical debt, which is great, but would > you perhaps consider doing the same thing for F31, F32, etc? The > basic reasons for technical debt will continue- why not plan to > service the debt regularly? > I'm going to have a longer post to reply about the overall topic brought up over Turkey Day, but for this specific point, I think that it would be a tremendous mistake if we allowed RHEL to influence us into slowing down the core of Fedora (see, I said the "bad" word!). In the past few years, I've been around the block a bit, being involved in different distribution release philosophies and processes. And one thing that is common among all of them is that "stuff rolls downstream". That is, an action from the top part usually has cascading effects downward. Most of us don't consider the "core"/"base platform" of Fedora to be the "top", but it is. All the decisions about how every package is built and shipped is affected by this. It would be incredibly dangerous for Fedora to take a RHEL-like approach to the core, because it means that we're deciding that the core is not a place for innovation and advancement. Now, I'll admit I have a personal stake here: much of what *I* do these days is in that part of the stack, and having that frozen would kill my ability to participate in the development of the distribution. But I'd like us to become less conservative instead of more so. I've been playing with the RHEL 8 beta for a bit now, and I have a pretty good idea what constitutes a "base" system in RHEL, and I'm afraid that it would be terrible if we froze that for a year. However, to the larger point about lifecycles and supporting hardware makers with a Fedora LTS that works for 4 years, this could be a good focus point for a new "Fedora Long-Term" WG that would work to take selected releases of Fedora and stabilize them for a period of time. This would be similar to the original Fedora Legacy and openSUSE Evergreen[1] projects. An interesting twist here is that we could take some inspiration from Debian on how they run their LTS and allow direct sponsorship for releases to be supported past their original life[2]. That means that under the auspices of the Fedora Project, interested volunteers and commercial entities could come together and maintain a release with security fixes past the 13 month life, for an additional 2 years. This approach has some advantages: notably only releases people are interested it would qualify, and the work burden scales with interest and sponsorship. The main disadvantage is that it won't happen "for free", which I think is actually a good thing here. Even Red Hat could participate in this program, though I fully expect that they won't, since they have their hands full with Red Hat Enterprise Linux. But it'd be nice if they did, because it could also be an avenue to improve the transparency between Fedora and RHEL, and give a more direct relationship (and potential for influencing improvements to RHEL that we don't have today!). It would also make it easier for the 22 other product projects that Red Hat has to use Fedora as their upstream rather than CentOS, since some folks in those communities complain Fedora is too fast for them (*hack*RDO*cough*). [1]: https://en.opensuse.org/openSUSE:Evergreen [2]: https://wiki.debian.org/LTS/ -- 真実はいつも一つ！/ 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: Proposal: Move to an annual platform release starting at F30
On Tue, Nov 27, 2018 at 9:39 AM Ralf Corsepius wrote: > > On 11/27/18 9:16 AM, Igor Gnatenko wrote: > > Because if we keep "no breaking updates in stable" policy, then Fedora > > won't be "first anymore". > > Users perceive your "first" as unstable and unreliable. There are plenty > of examples of how e.g. FC30 was broken and still is. Then it means that we have to do releases, otherwise we will stay with one version with outdated software not just for 6 months but for one year. > One such example is you personal favorite: dnf. > > > You can do this only if rawhide will be more > > popular between people. > Rawhide will never be end-user usable. I personally consider rawhide > end-user usability to be a hoax. > ___ > 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: Proposal: Move to an annual platform release starting at F30
On 11/27/18 9:16 AM, Igor Gnatenko wrote: Because if we keep "no breaking updates in stable" policy, then Fedora won't be "first anymore". Users perceive your "first" as unstable and unreliable. There are plenty of examples of how e.g. FC30 was broken and still is. One such example is you personal favorite: dnf. You can do this only if rawhide will be more popular between people. Rawhide will never be end-user usable. I personally consider rawhide end-user usability to be a hoax. ___ 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: Proposal: Move to an annual platform release starting at F30
Because if we keep "no breaking updates in stable" policy, then Fedora won't be "first anymore". You can do this only if rawhide will be more popular between people. On Tue, Nov 27, 2018, 03:34 Brendan Conoboy On 11/16/18 7:50 AM, Paul Frields wrote: > [snip] > > We should skip the F31 release cycle and leave F30 in place longer in > > order to focus on improving the tooling and testing changes. These > > tooling changes will improve the overall reliability of Fedora, and > > will decrease the manual effort and complexities involved in producing > > the distribution artifacts. Although we’ve done this before to make > > “editions” happen, the intent is to track this multi-team effort more > > actively so we can (1) use the time as well as possible, and (2) give > > the work maximum transparency. > > If there is going to be a pause F30 seems like a good place to do it: > New glibc, new compiler- and a full year for them to mature. It's a > nice basis for a stable platform. What would the update policy be for > this year- same as today? It seems like you're proposing this as a > one-time event to pay down technical debt, which is great, but would > you perhaps consider doing the same thing for F31, F32, etc? The > basic reasons for technical debt will continue- why not plan to > service the debt regularly? > > -- > 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 > ___ 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
