On Tue, Jan 22, 2019 at 3:35 PM Martin Kolman <mkolman@xxxxxxxxxx> wrote: > > On Tue, 2019-01-22 at 08:21 -0500, Matthew Miller wrote: > > On Tue, Jan 22, 2019 at 10:29:28AM +0100, Jakub Jelinek wrote: > > > I'm sorry, I forgot to create the every year feature request for GCC this > > > year and only realized that when I've successfully built first non-scratch > > > gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild > > > has been discussed and GCC updates is something that has been done every > > > year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back > > > in 2007). > > > > That's all true, but the change process still helps us coordinate. There are > > many new people in Fedora every year, and the more we have documented and > > explicit rather than "oh yeah, this happens every year", the better. > It also be of historical importance later on - it documents why and when the change was done > for future generations, who might no longer remember the reasoning. > > There might be even cases where you find software referencing some strange other project, > only to find two old Fedora change pages, one documenting the project being added to Fedora and > another one documenting it being replaced by something else later on. I don't think the Change process actually helps that. If anything, some of the Change pages just contribute to that. > This can be really helpful when hunting down obscure bugs or untangling reasons for past design decisions. I mean this in the most constructive way, but the Change process is not a design/architecture process. It is a collection of things that individual teams want to do that impacts the rest of the distro, which get approved if nobody objects (or notices too late). A design decision implies an overall architecture to the distribution that is not really present in Fedora. > > It sounds like you're thinking of it a little as "bureaucratic paperwork > > where we pretend that there's some debate about whether we're going to > > continue doing a completely normal thing". But it's not that. It's "the > > process for making sure our routine update to GCC across the whole distro > > goes smoothly for everyone". Perhaps I have a tinted view at this point, but I think Fedora has to outgrown the Change process. At the very least, turn it into something that is far less rubber-stampy and more coordinated and planned. Things like the yearly GCC rebase should be fundamental requirements that drive other actions, not something that has to be remembered to be filed in on a wiki every year as if we suddenly would stop doing that if the page didn't get created one time. E.g. we know we'll update GCC in a similar window of time year to year, so if we know that then perhaps we can use it to start articulating what a Fedora Platform really means. Perhaps we use that to drive a lifecycle for a particular ring/platform/whatever that other applications can build and rely on. I happened to sit in on two talks today that had pieces that resonated with me around affecting change, and how we tell ourselves we work in some particular way but in reality we are doing something else. We keep circling around a lot of things in Fedora that we want to investigate or change or improve, but then we continue to do the same things day in and day out. Perhaps instead of looking for completely new ways to do things, we can look at what we *really* do and not what we tell ourselves we do, and correct or build from those things towards what we want. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
