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?
On Fri, Mar 28, 2014 at 5:37 PM, Josh Stone jistone@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.
josh
On 03/28/2014 03:02 PM, Josh Boyer wrote:
On Fri, Mar 28, 2014 at 5:37 PM, Josh Stone jistone@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.
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).
On 29.03.2014 01:24, Josh Stone wrote:
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.
That's exactly what I wanted to say to a namesake of your. It is good to know that I'm not the only optimist here.
On Fri, Mar 28, 2014 at 8:24 PM, Josh Stone jistone@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@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
On 03/29/2014 07:35 AM, Josh Boyer wrote:
On Fri, Mar 28, 2014 at 8:24 PM, Josh Stone jistone@redhat.com wrote: 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.
Yeah, I just meant the git snapshot on upstream. Obviously the tag would have to be pushed somewhere. When I grab patch-3.14-rc8-git1.xz from fedpkg, it would be nice to know what commit that corresponds to, that's all.
Getting that from the log of the 'sources' file is ok. It would be even easier if the patch files were named in git-describe style, but I realize the kernel.spec isn't prepared to deal with that.
So this is good enough, thanks!
On 28.03.2014 22:37, Josh Stone 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?
http://pkgs.fedoraproject.org/repo/pkgs/kernel/ Brother from another mother. :)
poma
kernel@lists.fedoraproject.org
-
Josh Boyer -
Josh Stone -
poma