[ QUOTE ]
Hi all,
[The mirroring on kernel.org is being slow again ...]
Changes since 20101213:
New tree: vfs-scale
The vfs-scale tree gained a conflict against the fuse tree.
The ieee1394 tree lost its build failure.
The wireless tree gained conflicts against the wireless-current tree.
The sound tree lost its conflict.
The input tree gained a conflict against Linus' tree.
The voltage tree gained a build failure so I used the version from
next-20101213.
The swiotlb-xen tree lost its build failure.
The cleancache tree gained a conflict against the vfs-scale tree.
[ /QUOTE ]
First of all congrats to all involved parties so that the work of Nick
was accepted as "vfs-scale" into linux-next!
I played yesterday with the new refreshed patchset (manually merged
and fixed) against systemd-v15 with kgdb/kdb.
Oh yes, there is a "dmesg" command :-) and with "btp $pid" I yesterday
night saw a NULL dereference in the backtrace.
Currently, I am compiling linux-next (next-20101214) and will take
some pictures with my digicam.
Some recommends (not that I want to teach you as GIT is for me new
playground and I follow mostly the commit-messages, which not means I
understand the complexity of the patchset), but ...
1. Please give commits a proper/sane "commit subject"
"Build fix" or "Fixed build failure" is not saying much.
2. Add credits for people investing time to test and report
Same commits did not have also credits for people reporting the build failures.
A reference to LKML posting would be fine in the "commit-body" (sorry
for my comparison with Email, do not know the GIT term).
This all is not to punish you, it is for following and documenting the
whole process.
Peter Hutterer has a wonderful blog article "On commit messages"
concerning this topic.
If all of us would follow them, the working-together will be more fruitful.
My 0.02EUR.
- Sedat -
[1] http://who-t.blogspot.com/2009/12/on-commit-messages.html
Hi Sedat,
On Tue, 14 Dec 2010 10:38:35 +0100 Sedat Dilek <[email protected]> wrote:
>
> [ QUOTE ]
> Hi all,
>
> [The mirroring on kernel.org is being slow again ...]
>
> Changes since 20101213:
>
> New tree: vfs-scale
>
> The vfs-scale tree gained a conflict against the fuse tree.
>
> The ieee1394 tree lost its build failure.
>
> The wireless tree gained conflicts against the wireless-current tree.
>
> The sound tree lost its conflict.
>
> The input tree gained a conflict against Linus' tree.
>
> The voltage tree gained a build failure so I used the version from
> next-20101213.
>
> The swiotlb-xen tree lost its build failure.
>
> The cleancache tree gained a conflict against the vfs-scale tree.
> [ /QUOTE ]
>
> First of all congrats to all involved parties so that the work of Nick
> was accepted as "vfs-scale" into linux-next!
The "Nick" associated with the vfs-scale tree is Nick Piggin (cc'd).
> I played yesterday with the new refreshed patchset (manually merged
> and fixed) against systemd-v15 with kgdb/kdb.
> Oh yes, there is a "dmesg" command :-) and with "btp $pid" I yesterday
> night saw a NULL dereference in the backtrace.
> Currently, I am compiling linux-next (next-20101214) and will take
> some pictures with my digicam.
>
> Some recommends (not that I want to teach you as GIT is for me new
> playground and I follow mostly the commit-messages, which not means I
> understand the complexity of the patchset), but ...
>
> 1. Please give commits a proper/sane "commit subject"
> "Build fix" or "Fixed build failure" is not saying much.
>
> 2. Add credits for people investing time to test and report
> Same commits did not have also credits for people reporting the build failures.
> A reference to LKML posting would be fine in the "commit-body" (sorry
> for my comparison with Email, do not know the GIT term).
>
> This all is not to punish you, it is for following and documenting the
> whole process.
>
> Peter Hutterer has a wonderful blog article "On commit messages"
> concerning this topic.
> If all of us would follow them, the working-together will be more fruitful.
>
> My 0.02EUR.
>
> - Sedat -
>
> [1] http://who-t.blogspot.com/2009/12/on-commit-messages.html
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Tue, Dec 14, 2010 at 10:33:39PM +1100, Stephen Rothwell wrote:
> Hi Sedat,
>
> On Tue, 14 Dec 2010 10:38:35 +0100 Sedat Dilek <[email protected]> wrote:
> > I played yesterday with the new refreshed patchset (manually merged
> > and fixed) against systemd-v15 with kgdb/kdb.
> > Oh yes, there is a "dmesg" command :-) and with "btp $pid" I yesterday
> > night saw a NULL dereference in the backtrace.
> > Currently, I am compiling linux-next (next-20101214) and will take
> > some pictures with my digicam.
Thanks for testing, I would be very interested to know if your bug
has gone away or not, we never quite got to the bottom of that. BTW.
capturing the top of the oops is important, if possible. If you don't
have a serial console or anything to capture it, could you try
increasing the resolution of your console so it fits more in?
> > Some recommends (not that I want to teach you as GIT is for me new
> > playground and I follow mostly the commit-messages, which not means I
> > understand the complexity of the patchset), but ...
> >
> > 1. Please give commits a proper/sane "commit subject"
> > "Build fix" or "Fixed build failure" is not saying much.
Yes, that will be folded in properly before upstream merge.
> > 2. Add credits for people investing time to test and report
> > Same commits did not have also credits for people reporting the build failures.
> > A reference to LKML posting would be fine in the "commit-body" (sorry
> > for my comparison with Email, do not know the GIT term).
> >
> > This all is not to punish you, it is for following and documenting the
> > whole process.
> >
> > Peter Hutterer has a wonderful blog article "On commit messages"
> > concerning this topic.
> > If all of us would follow them, the working-together will be more fruitful.
That is a good point, and if I don't give testers enough credit, I'm
sorry because they're a vital part of the chain. Probably because I
have too many bugs that it would clutter my changelogs to credit
everyone who finds one :)
I definitely like to credit testers and reporters in bugfix patches to
upstream kernel, but I find that when they're testing a development
kernel, then the bugfix patches get merged back into the patch that
introduces the bug before being merged.
It wouldn't hurt to keep references to these problems though, not only
to acknoledge the testers, but also as a reference to potential pitfalls
or problematic areas in the commit.
So, I'll try to take your suggestion on board.
Thanks,
Nick