On Tue, Jan 22, 2019 at 3:35 PM Martin Kolman <mkolman(a)redhat.com> 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
for future generations, who might no longer remember the reasoning.
There might be even cases where you find software referencing some strange other
only to find two old Fedora change pages, one documenting the project being added to
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
> 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
> 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.