Where do rcX-gitY patches come from?

[Josh Boyer]

On Fri, Mar 28, 2014 at 8:24 PM, Josh Stone <jistone at redhat.com> wrote:
> On 03/28/2014 03:02 PM, Josh Boyer wrote:
>> On Fri, Mar 28, 2014 at 5:37 PM, Josh Stone <jistone at redhat.com> wrote:
>>> I know there used to be a linux-2.6-snaps.git tree that had rcX-gitY
>>> tags, but I haven't seen that in a while, I think since the kernel.org
>>> rebuild.  Yet rawhide still uses patches of this form.  Is there a git
>>> tree where these are maintained?
>>
>> Yes.  Linus Torvald's git tree.  ;)
>>
>> More verbosely, we have a script in the kernel package called
>> "scripts/generate-git-snapshot.sh" that takes an environment variable
>> which points to a local git checkout of Linus' tree.  It then
>> generates the git snapshots based on whatever is present in the tree
>> after the current -rcX tag.
>>
>> So whenever I do a new bump, I update my local tree copy immediately
>> with 'git pull', use the script, and upload the resulting patch with
>> fedpkg.  Then I do a local test build of the Fedora kernel package and
>> try it out on a few machines.  Assuming it works, the changes are
>> committed and pushed and an official build is kicked off.
>>
>> The local upstream git tree checkout is kept pristine on the master
>> branch.  There are no additional patches committed to it, ever.  Those
>> go in as patches in the spec file if needed.
>
> Ok, sure, I wasn't expecting this had diverged from upstream at all.  I
> was just hoping you'd have tags, so if/when we notice any regression
> between two snapshots, we might easily see the new commits, bisect, etc.

Tags where, and corresponding to what?  E.g. a tag for the git
snapshot, or a tag matching it to the NVR of the build?  Given they're
generated from my (or another maintainer's) local tree, that wouldn't
do anyone much good since it isn't pushed anywhere.

And to head this off, we've been asked about an exploded Fedora kernel
source git tree before.  It's not impossible at all, but it also isn't
of much value.  In order to maintaining it sanely, it would have to
rebase with every upstream rebase (git snapshot, rc, whatever).
That's how the it maps practically to the spec file and doing it
otherwise would just be a nightmare in the git history.  So it's not
impossible to have, but I doubt it would get much _use_.

It would be an interesting thought experiment to build _from_ an
exploded git tree and stop using patches in the spec file entirely.
Just generate a git archive when we wanted an RPM build.  However
that's still fairly impractical because of the rebases we do.

> I see that you note a more precise version in your commit messages, e.g.
> "Linux v3.14-rc8-12-g75c5a52", so that's probably good enough, although
> you might want to bump up your core.abbrev (Linus says 12).

Right, that is literally the output of 'git describe' at the time the
snapshot is made.  It's, IMO, just as precise (actually more so) than
a tag.  I'll look at bumping it up to 12, but that's not going to make
a practical difference for a while.

josh