Fedora kernel git tree and package maintenance

Josh Boyer jwboyer at fedoraproject.org
Wed Jun 17 16:45:33 UTC 2015


Hi All,

The kernel team has been running an exploded git tree since Flock last
year.  This has been mostly a "nice to have", but several people have
commented on how useful it is for them when debugging issues, etc.
Having the exploded sources with the patches we carry included lets
them easily see what we have changed and how.

While not a huge burden, this has been mostly an additional effort on
top of what we already do.  In order to make us a bit more efficient,
we've been looking at ways to automate or ease this, as well as make
it possible for more than one person to maintain it.  This has lead to
some discussion around moving to making the exploded git tree the
canonical source location for Fedora kernel work.  I'm sending this
email to start a conversation around that.

So what would this mean?  It means we'd maintain the exploded source
tree very similar to today, with it rebasing on top of whatever
upstream we're using as our base.  For info on how that works, see the
blog post I did about that a while ago.

Using this exploded tree, I've created some scripts to generate the
pkg-git content.  This is probably the biggest workflow change
involved.  We still need to use pkg-git to do builds in koji, but
direct commits to that repo would be disabled outside of a few of us
needed to do the syncs.  Patches and config changes could be done via
email to this list, or possibly via pull request to the branch
maintainer of the exploded tree.

Why would we do this?  A few reasons.  First, it allows us to
eliminate duplicate maintenance in multiple spots while still
providing all the same things we are right now.  Second, it moves us
to more of an upstream kernel development model and hopefully
increases both visibility and communication in terms of what
patches/changes go in, etc.  It also makes our job easier during
rebases, as we can literally use 'git rebase' and work via that
instead of having to copy around patches to different trees or
manually adjust patches outside of a normal git workflow.

Who does this impact?  Honestly, not many.  There are exactly 4 people
that commit to pkg-git today on anything resembling a regular basis.
However, it is my hope that changing the workflow a bit makes this
somewhat easier for others to work against a tree and submit patches
and changes.  I'm not under any impressions that it will exponentially
increase our contributors, but it will quite possibly make things a
bit more transparent.

Is this a done decision?  No.  Not at all.  In fact, the scripts
aren't even finished yet.  I wanted to get the discussion started
before really investing heavily in finishing them off.  Justin and
Laura have copies of the (unfinished) scripts and a howto document on
various tasks.  I'll likely send the howto out once I get a few of the
last remaining steps working for people to read over.  But the general
idea isn't going to change much, which is why we're talking about this
now.

When would this happen?  Unclear.  Certainly not this month as one of
the primary stakeholders is on PTO.  If the discussion goes well and
this direction is something we're going to do, then it might be next
month or at some natural cut-over point.

Will the exploded tree go away if we don't change to this model?  Also
unclear.  I'd hesitantly say it would stick around, but it might
change in the way it is created and published.

I'm sure there will be more questions, so please ask away.  Looking
forward to hearing other's thoughts.

josh


More information about the kernel mailing list