perhaps i'm just being clueless about the authorship protocol here,
but i'm a bit hacked off by noticing that at least one submitted patch
of mine was apparently re-submitted (albeit slightly modified) a few
days later by another poster and applied under that poster's name.
on sun, dec 3, i submitted to the list:
http://marc.theaimsgroup.com/?l=linux-kernel&m=116516635728664&w=2
and yet, just by accident this morning, i see the log for that file
ipc/sem.c contains:
======================================================
commit 4668edc334ee90cf50c382c3e423cfc510b5a126
Author: Burman Yan <[email protected]>
Date: Wed Dec 6 20:38:51 2006 -0800
[PATCH] kernel core: replace kmalloc+memset with kzalloc
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
diff --git a/ipc/sem.c b/ipc/sem.c
index 21b3289..d3e12ef 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1070,14 +1070,13 @@ static struct sem_undo *find_undo(struct
ipc_rcu_getref(sma);
sem_unlock(sma);
- new = (struct sem_undo *) kmalloc(sizeof(struct sem_undo) + sizeof(short)*nsems, GFP_KERNEL);
+ new = kzalloc(sizeof(struct sem_undo) + sizeof(short)*nsems, GFP_KERNEL);
if (!new) {
ipc_lock_by_ptr(&sma->sem_perm);
ipc_rcu_putref(sma);
sem_unlock(sma);
return ERR_PTR(-ENOMEM);
}
- memset(new, 0, sizeof(struct sem_undo) + sizeof(short)*nsems);
new->semadj = (short *) &new[1];
new->semid = semid;
======================================================
admittedly, mr. yan's patch is technically cleaner since it removes
the superfluous cast applied to kzalloc(). however, i very
*deliberately* left that cast in, and i explained why a couple days
later here in another context:
http://marc.theaimsgroup.com/?l=linux-kernel&m=116553652920469&w=2
quite simply, as per the guidelines given for creating and
submitting kernel patches, i'm trying to keep each submission
well-defined, as i was going to follow up the above with another
submission to remove *all* superfluous casts in one fell swoop. but
it's not just a matter of proper patch attribution.
i've submitted a number of patches recently and, every time i do a
"git pull", i check the log to see if any of them have been applied so
i can delete them from my personal "submitted but not applied"
directory. if they've been applied by another author, then naturally
i'll never notice and i'll keep wondering about the delay.
so what's the protocol here? are more senior kernel developers
allowed to poach on my patch submissions, tidy them up slightly, then
drop any attribution to me? enquiring minds *definitely* want this
cleared up.
rday
p.s. it's possible that this is all just a wild coincidence, of
course. stranger things have happened.
> p.s. it's possible that this is all just a wild coincidence, of
> course. stranger things have happened.
... or a genuine mistake.
Ben.
Robert P. J. Day wrote:
> i've submitted a number of patches recently and, every time i do a
> "git pull", i check the log to see if any of them have been applied so
> i can delete them from my personal "submitted but not applied"
> directory. if they've been applied by another author, then naturally
> i'll never notice and i'll keep wondering about the delay.
>
> so what's the protocol here? are more senior kernel developers
> allowed to poach on my patch submissions, tidy them up slightly, then
> drop any attribution to me? enquiring minds *definitely* want this
> cleared up.
>
> rday
>
> p.s. it's possible that this is all just a wild coincidence, of
> course. stranger things have happened.
The protocol is simply to do best to give credit where credit is due.
If your patch is taken directly, most likely it is a mistake if
attribution was dropped. If your patch was modified, often that patch
will get checked in under the name of the person who last touched the
change before commit -- and it is their responsibility to make sure and
note that the change originally came from you.
Jeff
On Sat, 9 Dec 2006, Benjamin Herrenschmidt wrote:
> > p.s. it's possible that this is all just a wild coincidence, of
> > course. stranger things have happened.
>
> ... or a genuine mistake.
sure, as i wrote above, i'm willing to accept that. but it still
leaves an open issue -- once one submits a patch, is there *any*
official feedback that one can look for to see if it's been
accepted/rejected/dropped on the floor/whatever?
at last count, i have eight patches in the queue. or do i? i have no
way of knowing. (actually, that's not entirely true -- one of the
patches was Ack'ed so i'm assuming it will go in eventually, but i
still have no idea when.)
but given that i'm trying to follow the kernel guidelines and keep
each submission as a logically-related chunk, in many cases, i have to
wait for one patch to be applied before i can submit the next one.
and, at the moment, there's no way of knowing what's going on.
rday
p.s. WRT to the example i described above, if it was a coincidence
that someone else submitted a duplicate patch to mine, i don't think
it's unreasonable to suggest that my submission should have been
replied to on the list with something like "this patch is a duplicate
of so-and-so's," rather than silently throwing it away.
a few seconds of that kind of courtesy seems a small price to pay to
let me avoid days of wondering what's happening.
On Sat, 9 Dec 2006, Jeff Garzik wrote:
> The protocol is simply to do best to give credit where credit is
> due. If your patch is taken directly, most likely it is a mistake if
> attribution was dropped. If your patch was modified, often that
> patch will get checked in under the name of the person who last
> touched the change before commit -- and it is their responsibility
> to make sure and note that the change originally came from you.
and just to finish off this still-twitching horse, i'm not that
concerned if someone else gets the attribution. that patch was so
trivial, it's not like i'm going to parade it around as my
contribution to the kernel. (and, as i said, it's entirely possible
that this was just one of those wild coincidences.)
i'm far more interested in at least knowing what happens to patches
once they enter the system, so i can plan on what kind of cleanup i
can work on next.
rday
> but it still leaves an open issue -- once one submits a patch, is there
> *any* official feedback that one can look for to see if it's been
> accepted/rejected/dropped on the floor/whatever?
You can regularely pull Linus' tree (or the tree of the maintainer you
sent your patch) and see whether your patches still apply cleanly.
Whenever they cause a reject, they need your attention: either they were
applied, or they got out of date because something else changed.
(akpm also sends out automatic notification emails for patches in the -mm
tree based on a similar method.)
> but given that i'm trying to follow the kernel guidelines and keep
> each submission as a logically-related chunk, in many cases, i have to
> wait for one patch to be applied before i can submit the next one.
> and, at the moment, there's no way of knowing what's going on.
Well, you can send out a patch series:
[patch 01/02] Prepare foo for blah
[patch 02/02] Apply blah to foo
Ideally you would finish the patch description for patch 02 with something
like
---
This patch depends on [patch 01/02] Prepare foo for blah
But usually people will assume they have to apply the patches in order
even without you explicitly telling them.
Unless you are keen on particular feedback about patch 01 before doing
much work on patch 02, this should work out well.
Tim
On Sat, 9 Dec 2006, Tim Schmielau wrote:
> i wrote:
> > but given that i'm trying to follow the kernel guidelines and keep
> > each submission as a logically-related chunk, in many cases, i
> > have to wait for one patch to be applied before i can submit the
> > next one. and, at the moment, there's no way of knowing what's
> > going on.
>
> Well, you can send out a patch series:
> [patch 01/02] Prepare foo for blah
> [patch 02/02] Apply blah to foo
> Ideally you would finish the patch description for patch 02 with something
> like
>
> ---
> This patch depends on [patch 01/02] Prepare foo for blah
... snip ...
wait a minute. that's not what i've understood all this time as the
rationale for a multi-part patch -- to show dependency. certainly,
that's not what you read in "SubmittingPatches":
"If one patch depends on another patch in order for a change to be
complete, that is OK. Simply note "this patch depends on patch X" in
your patch description."
that doesn't say anything about using the multi-part notation. are
you sure about this?
rday
On 12/9/06, Robert P. J. Day <[email protected]> wrote:
> perhaps i'm just being clueless about the authorship protocol here,
> but i'm a bit hacked off by noticing that at least one submitted patch
> of mine was apparently re-submitted (albeit slightly modified) a few
> days later by another poster and applied under that poster's name.
>
> on sun, dec 3, i submitted to the list:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=116516635728664&w=2
It really seems to be Burman Yan's patch from November 22. Notice how
your patch still has the redundant cast whereas the applied one
doesn't.
On 09/12/06, Robert P. J. Day <[email protected]> wrote:
> On Sat, 9 Dec 2006, Tim Schmielau wrote:
>
> > i wrote:
>
> > > but given that i'm trying to follow the kernel guidelines and keep
> > > each submission as a logically-related chunk, in many cases, i
> > > have to wait for one patch to be applied before i can submit the
> > > next one. and, at the moment, there's no way of knowing what's
> > > going on.
> >
> > Well, you can send out a patch series:
> > [patch 01/02] Prepare foo for blah
> > [patch 02/02] Apply blah to foo
> > Ideally you would finish the patch description for patch 02 with something
> > like
> >
> > ---
> > This patch depends on [patch 01/02] Prepare foo for blah
>
> ... snip ...
>
> wait a minute. that's not what i've understood all this time as the
> rationale for a multi-part patch -- to show dependency. certainly,
> that's not what you read in "SubmittingPatches":
>
> "If one patch depends on another patch in order for a change to be
> complete, that is OK. Simply note "this patch depends on patch X" in
> your patch description."
>
> that doesn't say anything about using the multi-part notation. are
> you sure about this?
>
I've done this several times. It's quite a common way of doing it.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Robert P. J. Day wrote:
> i'm far more interested in at least knowing what happens to patches
> once they enter the system, so i can plan on what kind of cleanup i
> can work on next.
The maintainers handle this differently. If you don't get feedback nor
see your patch appearing in the maintainer's repo after a while, just ask
what happened or repost your patch (with a [resend] flag or a respective
note below the patch description).
--
Stefan Richter
-=====-=-==- ==-- -=--=
http://arcgraph.de/sr/
On Sat, Dec 09, 2006 at 07:11:21AM -0500, Robert P. J. Day wrote:
> i'm far more interested in at least knowing what happens to patches
> once they enter the system, so i can plan on what kind of cleanup i
> can work on next.
>
Trivial patches tend not to be a priority for most people, especially
during a period when people are gearing up for the close of the merge
window (unless they happen to fix a serious bug, in which case it's
another matter, and it should also be brought to -stable's attention).
Timing has a lot to do with expected feedback for these sorts of things.
[email protected] exists to handle the rest of the bits, where Adrian
has a tendency to queue up many trivial and related patches at once, and
sending out pull requests at a time where it will be less disruptive to
the rest of development. You might be better off simply CC'ing trivial@
on these patch submissions and routinely checking the trivial git tree to
see whether they've been queued or not.
However, if you're changing or reordering functionality that isn't an
obvious bugfix, you're still going to have to get an ack from the
maintainer.
> On Sat, 9 Dec 2006 05:22:32 -0500 (EST) "Robert P. J. Day" <[email protected]> wrote:
>
> perhaps i'm just being clueless about the authorship protocol here,
> but i'm a bit hacked off by noticing that at least one submitted patch
> of mine was apparently re-submitted (albeit slightly modified) a few
> days later by another poster and applied under that poster's name.
>
> on sun, dec 3, i submitted to the list:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=116516635728664&w=2
>
> and yet, just by accident this morning, i see the log for that file
> ipc/sem.c contains:
>
> ======================================================
> commit 4668edc334ee90cf50c382c3e423cfc510b5a126
> Author: Burman Yan <[email protected]>
> Date: Wed Dec 6 20:38:51 2006 -0800
>
> [PATCH] kernel core: replace kmalloc+memset with kzalloc
>
> Signed-off-by: Andrew Morton <[email protected]>
> Signed-off-by: Linus Torvalds <[email protected]>
>
> diff --git a/ipc/sem.c b/ipc/sem.c
>
> ...
>
> course. stranger things have happened.
Not at all wild, actually. Quite a few people are doing kzalloc
conversions and I reguarly see overlaps.
On Sun, Dec 10, 2006 at 02:09:20PM +0900, Paul Mundt wrote:
>...
> [email protected] exists to handle the rest of the bits, where Adrian
> has a tendency to queue up many trivial and related patches at once, and
> sending out pull requests at a time where it will be less disruptive to
> the rest of development. You might be better off simply CC'ing trivial@
> on these patch submissions and routinely checking the trivial git tree to
> see whether they've been queued or not.
>...
Checking the tree won't help since it's only different from Linus' tree
in the few hours between me asking Linus to pull and Linus actually
pulling.
Patches to [email protected] simply go into a mail folder, and I'm
going through this during the two week merge window.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed