For a while, diffs in the Fedora kernel have followed the form
linux-2.6-*.patch
Then, we started seeing some git snapshots show up as
git-*.diff
and lately, everything seems to have gone bananas, with no particular scheme at all..
nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc.
Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else.
So, what are peoples thoughts on this?
Dave
Dave Jones wrote:
For a while, diffs in the Fedora kernel have followed the form
linux-2.6-*.patch
Then, we started seeing some git snapshots show up as
git-*.diff
and lately, everything seems to have gone bananas, with no particular scheme at all..
nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc.
Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else.
So, what are peoples thoughts on this?
Dave
If we'd prefix them with the source package name, in this case "kernel", it would make it a lot easier to find things in /usr/src/redhat/SOURCES when we've got SRPMs from different packages installed. We should probably avoid using names that refer to a specific upstream version, because the name becomes misleading once we rebase. When there's a suitable upstream patch name, like the names Andrew Morton uses in -mm, we should probably use those (perhaps prepended with kernel-) to make it clear what it corresponds to upstream.
-- Chris
On Friday 10 October 2008 17:27:00 Chris Snook wrote:
Dave Jones wrote:
For a while, diffs in the Fedora kernel have followed the form
linux-2.6-*.patch
Then, we started seeing some git snapshots show up as
git-*.diff
and lately, everything seems to have gone bananas, with no particular scheme at all..
nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc.
Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else.
So, what are peoples thoughts on this?
Dave
If we'd prefix them with the source package name, in this case "kernel", it would make it a lot easier to find things in /usr/src/redhat/SOURCES when we've got SRPMs from different packages installed. We should probably avoid using names that refer to a specific upstream version, because the name becomes misleading once we rebase. When there's a suitable upstream patch name, like the names Andrew Morton uses in -mm, we should probably use those (perhaps prepended with kernel-) to make it clear what it corresponds to upstream.
Yeah, I'd be happy with <pkgname>-<tree id>-<description>.patch, omitting the tree id portion if there isn't one, or some variant thereof. Being able to do an 'ls kernel*.patch' is definitely useful.
On Fri, Oct 10, 2008 at 05:55:50PM -0400, Jarod Wilson wrote:
On Friday 10 October 2008 17:27:00 Chris Snook wrote:
Dave Jones wrote:
For a while, diffs in the Fedora kernel have followed the form
linux-2.6-*.patch
Then, we started seeing some git snapshots show up as
git-*.diff
and lately, everything seems to have gone bananas, with no particular scheme at all..
nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc.
Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else.
So, what are peoples thoughts on this?
Dave
If we'd prefix them with the source package name, in this case "kernel", it would make it a lot easier to find things in /usr/src/redhat/SOURCES when we've got SRPMs from different packages installed. We should probably avoid using names that refer to a specific upstream version, because the name becomes misleading once we rebase. When there's a suitable upstream patch name, like the names Andrew Morton uses in -mm, we should probably use those (perhaps prepended with kernel-) to make it clear what it corresponds to upstream.
Yeah, I'd be happy with <pkgname>-<tree id>-<description>.patch, omitting the tree id portion if there isn't one, or some variant thereof. Being able to do an 'ls kernel*.patch' is definitely useful.
kernel-* is sacred. Tab completion ftw. :)
Dave
On Friday 10 October 2008 20:37:24 Dave Jones wrote:
On Fri, Oct 10, 2008 at 05:55:50PM -0400, Jarod Wilson wrote:
On Friday 10 October 2008 17:27:00 Chris Snook wrote:
Dave Jones wrote:
For a while, diffs in the Fedora kernel have followed the form
linux-2.6-*.patch
Then, we started seeing some git snapshots show up as
git-*.diff
and lately, everything seems to have gone bananas, with no particular scheme at all..
nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc.
Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else.
So, what are peoples thoughts on this?
Dave
If we'd prefix them with the source package name, in this case "kernel", it would make it a lot easier to find things in /usr/src/redhat/SOURCES when we've got SRPMs from different packages installed. We should probably avoid using names that refer to a specific upstream version, because the name becomes misleading once we rebase. When there's a suitable upstream patch name, like the names Andrew Morton uses in -mm, we should probably use those (perhaps prepended with kernel-) to make it clear what it corresponds to upstream.
Yeah, I'd be happy with <pkgname>-<tree id>-<description>.patch, omitting the tree id portion if there isn't one, or some variant thereof. Being able to do an 'ls kernel*.patch' is definitely useful.
kernel-* is sacred. Tab completion ftw. :)
Ah, good point, s/kernel/linux/ then maybe?
Jarod Wilson wrote:
On Friday 10 October 2008 20:37:24 Dave Jones wrote:
On Fri, Oct 10, 2008 at 05:55:50PM -0400, Jarod Wilson wrote:
On Friday 10 October 2008 17:27:00 Chris Snook wrote:
Dave Jones wrote:
For a while, diffs in the Fedora kernel have followed the form
linux-2.6-*.patch
Then, we started seeing some git snapshots show up as
git-*.diff
and lately, everything seems to have gone bananas, with no particular scheme at all..
nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc.
Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else.
So, what are peoples thoughts on this?
Dave
If we'd prefix them with the source package name, in this case "kernel", it would make it a lot easier to find things in /usr/src/redhat/SOURCES when we've got SRPMs from different packages installed. We should probably avoid using names that refer to a specific upstream version, because the name becomes misleading once we rebase. When there's a suitable upstream patch name, like the names Andrew Morton uses in -mm, we should probably use those (perhaps prepended with kernel-) to make it clear what it corresponds to upstream.
Yeah, I'd be happy with <pkgname>-<tree id>-<description>.patch, omitting the tree id portion if there isn't one, or some variant thereof. Being able to do an 'ls kernel*.patch' is definitely useful.
kernel-* is sacred. Tab completion ftw. :)
Ah, good point, s/kernel/linux/ then maybe?
Works for me, as long as we enforce it universally. If we end up with a mix of linux- and linux-2.6-, it'll just be even more of a PITA.
-- Chris
On 11.10.2008 02:37, Dave Jones wrote:
On Fri, Oct 10, 2008 at 05:55:50PM -0400, Jarod Wilson wrote:
On Friday 10 October 2008 17:27:00 Chris Snook wrote:
Dave Jones wrote:
For a while, diffs in the Fedora kernel have followed the form linux-2.6-*.patch Then, we started seeing some git snapshots show up as git-*.diff and lately, everything seems to have gone bananas, with no particular scheme at all.. nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc. Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else. So, what are peoples thoughts on this?
If we'd prefix them with the source package name, in this case "kernel", it would make it a lot easier to find things in /usr/src/redhat/SOURCES when we've got SRPMs from different packages installed. We should probably avoid using names that refer to a specific upstream version, because the name becomes misleading once we rebase. When there's a suitable upstream patch name, like the names Andrew Morton uses in -mm, we should probably use those (perhaps prepended with kernel-) to make it clear what it corresponds to upstream.
Yeah, I'd be happy with <pkgname>-<tree id>-<description>.patch, omitting the tree id portion if there isn't one, or some variant thereof. Being able to do an 'ls kernel*.patch' is definitely useful.
kernel-* is sacred. Tab completion ftw. :)
Just a note: Isn't there some rule or suggestion hidden in our guidelines somewhere(¹) that suggests to prefix all patches for package "foo" with "foo-" (or simply "%{name}-" in practice)? That should avoid that files from one srpm on install accidentally replace files that are were installed earlier by a different srpm.
Cu knurd
(¹) I could not find it, but there are people that know those long and complicated guidelines way better than I do
On Fri, 2008-10-10 at 15:01 -0400, Dave Jones wrote:
For a while, diffs in the Fedora kernel have followed the form
linux-2.6-*.patch
Then, we started seeing some git snapshots show up as
git-*.diff
and lately, everything seems to have gone bananas, with no particular scheme at all..
nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc.
Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else.
So, what are peoples thoughts on this?
The linux-2.6 thing groups nicely for ls, but make tab complete a waste of time, and is pretty pointless as you say.
nvidia-agp I apologise for, it just came with that name from upstream, I meant to rename it to at least agp-nvidia.
I don't suppose we could use a subdirectory called patches if we want to keep ls clean.. this being the 21st century :)
Dave.
Dave
On Friday 10 October 2008 21:23:34 Dave Airlie wrote:
On Fri, 2008-10-10 at 15:01 -0400, Dave Jones wrote:
For a while, diffs in the Fedora kernel have followed the form
linux-2.6-*.patch
Then, we started seeing some git snapshots show up as
git-*.diff
and lately, everything seems to have gone bananas, with no particular scheme at all..
nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc.
Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else.
So, what are peoples thoughts on this?
The linux-2.6 thing groups nicely for ls, but make tab complete a waste of time, and is pretty pointless as you say.
nvidia-agp I apologise for, it just came with that name from upstream, I meant to rename it to at least agp-nvidia.
I don't suppose we could use a subdirectory called patches if we want to keep ls clean.. this being the 21st century :)
I vaguely recall trying a test implementation of this at one point, and if I recall correctly, it made rpm very unhappy. However, its been a while, maybe this is doable with the latest rpm and/or maybe my recollections are wrong. A patches subdir would certainly clean things up considerably, and then I think a constant patch name prefix matters a lot less (certainly still could stand to apply some standard formula to naming, of course, but it wouldn't impact tab completion near as much anymore).
On Mon, 2008-10-13 at 10:59 -0400, Jarod Wilson wrote:
On Friday 10 October 2008 21:23:34 Dave Airlie wrote:
nvidia-agp I apologise for, it just came with that name from upstream, I meant to rename it to at least agp-nvidia.
I don't suppose we could use a subdirectory called patches if we want to keep ls clean.. this being the 21st century :)
I vaguely recall trying a test implementation of this at one point, and if I recall correctly, it made rpm very unhappy. However, its been a while, maybe this is doable with the latest rpm and/or maybe my recollections are wrong. A patches subdir would certainly clean things up considerably, and then I think a constant patch name prefix matters a lot less (certainly still could stand to apply some standard formula to naming, of course, but it wouldn't impact tab completion near as much anymore).
rpm still doesn't like this. Adding it isn't _that_ hard, last time I looked, and it's not like it introduces any new collision opportunities for people who use the system-wide %_sourcedir. Probably worth running this past rpm-maint@ though.
- ajax
Dave Jones wrote:
For a while, diffs in the Fedora kernel have followed the form
linux-2.6-*.patch
Then, we started seeing some git snapshots show up as
git-*.diff
and lately, everything seems to have gone bananas, with no particular scheme at all..
nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc.
Urk, even though Dave says he wasn't picking on me, 2/3 of those mentioned were mine. Oops. Sorry. :) One of them was from the upstream patch queue, the other was just whatever name popped into my head when I imported it into a quilt stack.
As an aside - but maybe relevant - how much description / lineage / whatever should go into the spec file comments vs. into the TODO file?
-Eric
On Fri, Oct 10, 2008 at 08:43:34PM -0500, Eric Sandeen wrote:
As an aside - but maybe relevant - how much description / lineage / whatever should go into the spec file comments vs. into the TODO file?
The TODO is pretty free form, put whatever you want in there. Pointers to upstream discussion (if any exists) is a good start, as is any other info on its upstream progress.
The specfile - One liners are fine. Think about the sort of thing that goes in the git shortlog upstream. If bugzillas exist, referencing them with (#123456) at the end seems to be the standard way of mentioning them.
I don't want to get beurocratic about all this (hey, it's Fedora, not RHEL :) so I'm not going to be imposing any kind of enforcement on the above. Just go with what feels 'right'.
General rule of thumb: Some info is better than no info.
Dave
kernel@lists.fedoraproject.org
-
Adam Jackson -
Chris Snook -
Dave Jones -
David Airlie -
Eric Sandeen -
Jarod Wilson -
Thorsten Leemhuis