Faking sign offs is bad

Faking sign offs is bad

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

It seems some people have taken to faking sign off in patches, which is
a bad thing. I would like to propose to revert anything that has fake
signed-off-by lines.

Case in point:
http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=28bc48904e31c3a63cf5a60bc005ed8fb359cc52

Can that please get reverted? Andrea didn't ask me for a sign off and I
didn't give one.

Apart from that, the commit is bogus, it just adds a
'udev/udev-151/udev-compat-static.patch' file in ${S} (of all places!)
instead of actually patching the udev init file.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMAOBzMkyGM64RGpERApnUAJ9ZTsHRLSeP2ZEFdqGuzReFNhDjfQCgrB38
ddIujBP67BVQSsk6IBXZBJc=
=ihUE
-----END PGP SIGNATURE-----

Re: Faking sign offs is bad

[Frans Meulenbroeks]

2010/5/29 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> It seems some people have taken to faking sign off in patches, which is
> a bad thing. I would like to propose to revert anything that has fake
> signed-off-by lines.
>
> Case in point:
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=28bc48904e31c3a63cf5a60bc005ed8fb359cc52
>
> Can that please get reverted? Andrea didn't ask me for a sign off and I
> didn't give one.

Andrea, do you want to comment on this? (or explain it)

Without knowing  the other side of the story I won't comment on this
specific example, but I would like to say something on it in general.
Personally I feel that faking sign-off's or acked-by's is very bad.
If this happens due to an accident or unawareness, I'm inclined to
give the person a second chance, but if it happens repeatedly or
intentionally, I suggest a revocation of commit rights.

And in order to avoid yes/no discussions I strongly suggest that
people express their acks in a way that it can be traced back should
any argument arise (e.g. by ack-ing by mail or on a logged irc
channel).

Frans.

>
> Apart from that, the commit is bogus, it just adds a
> 'udev/udev-151/udev-compat-static.patch' file in ${S} (of all places!)
> instead of actually patching the udev init file.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFMAOBzMkyGM64RGpERApnUAJ9ZTsHRLSeP2ZEFdqGuzReFNhDjfQCgrB38
> ddIujBP67BVQSsk6IBXZBJc=
> =ihUE
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Faking sign offs is bad

[Andrea Adami]

The patch was sitting since long time (I had no time to test it
before) and recently udev has been changed. I wanted to give it a bump
before 'static' recipe renaming.

I'm sorry if its signature not conform.
My intent was to properly give credits to the author (koen).

Lesson: never commit at 2 o' clock..

Regards

Andrea

Re: Faking sign offs is bad

[Holger Freyther]

On 05/29/2010 07:14 PM, Andrea Adami wrote:
> The patch was sitting since long time (I had no time to test it
> before) and recently udev has been changed. I wanted to give it a bump
> before 'static' recipe renaming.
> 
> I'm sorry if its signature not conform.

Hi,

first of all thank you for your contribution. The issue here is that a
"Signed-off-by:" is not to give credit but at least in the classic sense
gives the origin (route of the patch to the tree).

In case you want to give credit you can use it in the commit message,
lile this patch is based on work of... or if it is fully written by
someone else use the --author on git commit.

happy hacking
	z

Broken recipes

[butters]

Hi there,

Can someone tell me the reason for keeping broken recipes in the tree? 
Examples are the maemo task and image, the openmoko task doesn't compile 
because its missing stuff. Are these things going to eventually be 
fixed, or are they there for some other reason that I'm not 
understanding? I'm not trying to be insulting to anyone, but I think 
having broken things that don't even make it to the compile stage in the 
tree will confuse a lot of people.

Thanks,
Bill

Re: Broken recipes

[Dr. Michael Lauer]

Hi Bill,

> Can someone tell me the reason for keeping broken recipes in the tree?

Define 'broken'; some packages only build for a certain combination of $MACHINE and $DISTRO,
and sometimes perhaps even $OUT_OF_TREE_OVERLAY.

If a package is definitely broken, we should move it to 'broken' (if there is still
any interest in it), or remove it altogether. Most of the time it's maintainers disappearing
and who knows when or if they will appear again, so why annoy them by removing the recipe?

There's also lack of manpower to throw into the equation.

Which concrete recipes do you mean? I'd agree with removing a dozen of openmoko ones
for distributions that noone works on any longer (i.e. Openmoko 2007.2 and Openmoko 2008),
but please tell me exactly which ones.

Cheers,

:M:

Re: Broken recipes

[butters]

I think I just did mention some packages... Maemo is missing "outo" 
during the initial stages of checking for all available recipes and 
tasks and it's missing things. This is the same thing with the 
task-openmoko.bb ...

I'm compiling for the mini2440 board. It's an armv4t board. The majority 
of the things that I can see will and should compile for it. But when I 
say broken, I am talking about recipes that don't even make it to 
running the queue part... the recipes that stop before that because of 
missing components. I understand that certain packages might not compile 
for obscure hardware.

As I said in my previous post, I think that more people get confused and 
waste a lot of time trying to fix broken things. From what I understand 
of Maemo, not all of it is available as open source so it shouldnt be 
included at all, right???

I've not tried to build everything. So I don't have a list. I'm just 
mentioning two that I tried today, and that I've tried over the past few 
months with the same results.

Thanks for your reply :)

Bill

On 5/30/2010 3:14 PM, Dr. Michael Lauer wrote:
> Hi Bill,
>
>    
>> Can someone tell me the reason for keeping broken recipes in the tree?
>>      
> Define 'broken'; some packages only build for a certain combination of $MACHINE and $DISTRO,
> and sometimes perhaps even $OUT_OF_TREE_OVERLAY.
>
> If a package is definitely broken, we should move it to 'broken' (if there is still
> any interest in it), or remove it altogether. Most of the time it's maintainers disappearing
> and who knows when or if they will appear again, so why annoy them by removing the recipe?
>
> There's also lack of manpower to throw into the equation.
>
> Which concrete recipes do you mean? I'd agree with removing a dozen of openmoko ones
> for distributions that noone works on any longer (i.e. Openmoko 2007.2 and Openmoko 2008),
> but please tell me exactly which ones.
>
> Cheers,
>
> :M:
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>    

Re: Faking sign offs is bad

[Andrea Adami]

> Apart from that, the commit is bogus, it just adds a
> 'udev/udev-151/udev-compat-static.patch' file in ${S} (of all places!)
> instead of actually patching the udev init file.

The hack must be temporarly.
I though tit's more clean if we overwrite the file than diffing and patching it.
Perhaps I was wrong.

Andrea

Re: Faking sign offs is bad

[Andrea Adami]

>> Apart from that, the commit is bogus, it just adds a
>> 'udev/udev-151/udev-compat-static.patch' file in ${S} (of all places!)
>> instead of actually patching the udev init file.
>
> The hack must be temporarly.
> I though tit's more clean if we overwrite the file than diffing and patching it.
> Perhaps I was wrong.
>
> Andrea
>

Oh, I see now...yes..my bad:

I had locally some more changes, which got lost importing your
modified init. 3 magic lines.

do_configure_prepend() {
        cp ${S}/patches/udev-compat-static.patch ${S}/init
}

Please forget: I'm preparing a proper v2 patch to be sent on the ML.

Sorry again for the noise

Andrea