Re: Install issues

[Andreas Ericsson <ae@op5.se>]

H.Merijn Brand wrote:
> On Mon, 10 Nov 2008 18:51:23 +0100, Miklos Vajna
> <vmiklos@frugalware.org> wrote:
> 
>> On Mon, Nov 10, 2008 at 05:31:01PM +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
>>> --- Makefile.org	2008-11-10 17:29:53.000000000 +0100
>>> +++ Makefile	2008-11-10 17:29:39.000000000 +0100
>>> @@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
>>>  	./test-sha1.sh
>>>  
>>>  check: common-cmds.h
>>> +	@`sparse </dev/null 2>/dev/null` || (\
>>> +	    echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
>>> +	    echo "Did you mean 'make test' instead?" ;\
>>> +	    exit 1 )
>>>  	for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
>> Please read Documentation/SubmittingPatches, your patch lacks a signoff
>> and a commit message.
> 
> You're not making things easier for people that do not use git from a
> git repo, something that happens quite a lot when you build from a
> released tarball.
> 

I think it's assumed that most git developers will clone the git repo so
they can send their patches against the very latest code. Usually, that's
part of "how to submit patches" of all projects.

> git-1.6.0.4 $ git format-patch -M
> fatal: Not a git repository
> Exit 128
> 
> I don't like this at all. How much more work is it for you to add the
> subject and sign-off yourself, instead of requiring that from people
> that like to help?
> 

"Ask not what a bunch of oss devs can do for you, but what you can do
for them. Especially if you want your changes accepted".

The harsh reality is that this is your itch. Noone else cares very
much either way, so if you want your change included, you'll have to
do it the way the project maintainer wants it.

> In the perl development, the only thing we *require* is a diff that
> either uses unified (preferred) or context diff.
> 

Nothing's required here, but since nobody else seems to have problems
with the check/test stuff here, noone else will fix it up for you.

Besides that, I'm sure you require a teensy bit more than that. If I
send you a 14k line patch without a reasoning behind it, you won't
just go ahead and apply it, will you? If I send an algorithm for a new
hash that might actually be proprietary code from an anonymous email
address, wouldn't you want some sort of verification that I'm actually
allowed to send that algorithm to you?

In git, those two steps are formalized into "Sign your patches!" and
"Write a proper commit message!". Since they *are* formalized, we
provide handy tools for doing just that. It's up to you if you want to
use them. Dictating the patch submission (or rather, acceptancy policy)
is not. Patches submitted incorrectly will have one of the following
things happen to them:
1. The patch is forgotten entirely, since nobody cares about it enough
   to make it a "proper" patch (by git standards).
2. The patch author resubmits it in the proper format.
3. Someone else resubmits it in the proper format.
4. Junio accepts it anyway.

4 is the least likely to happen, and will pretty much only occur if
someone finds some really horrible bug that absolutely and obviously
has to go in the git code. Even in those cases, 3 usually happens
before Junio wakes up.

3 is not very likely to happen unless the feature you're suggesting
is of interest to a lot of people.

Ofcourse, *after* the patch has been submitted in the proper format,
it can still get rejected. Submitting it properly is only the first
step towards getting any kind of review on it (basically).

> I did follow the ideal patch flow so far:
> --8<---
> An ideal patch flow
> 
> Here is an ideal patch flow for this project the current maintainer
> suggests to the contributors:
> 
>  (0) You come up with an itch.  You code it up.
> 
>  (1) Send it to the list and cc people who may need to know about
>      the change.
> -->8---
> 
> Code speaks louder than words, so I proposed a patch.
> This might be my last patch. git is not just another project I want to
> loose so much time in.
> 

That would be sad. We're a tad short on perl folks, although I guess
that's not much of an issue since we're rewriting most of it in C
anyways.

If you should decide to relent though, I seriously suggest using the
tools git provides for sending patches. If you do, you'll be able to
able to send (properly formatted) patches very easily indeed.

Rant aside, thanks for the re-send. I'm sure Junio can sed s/Author/From/
on the mail and have git accept it properly in case he accepts it.
Otherwise, I'll resubmit it, faking you as the author.

> --8<---
> Author: H.Merijn Brand <h.m.brand@xs4all.nl>
> Date:   Mon, 10 Nov 2008 17:31:01 +0100
> 
>     Make check needs sparse. If sparse is not available, it might as
>     well be a user error who really wanted make test.
> 
> Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl>
> ---
> 
> diff --git a/Makefile.org b/Makefile
> index becd008..718ddf2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
>         ./test-sha1.sh
> 
>  check: common-cmds.h
> +       @`sparse </dev/null 2>/dev/null` || (\
> +           echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
> +           echo "Did you mean 'make test' instead?" ;\
> +           exit 1 )
>         for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
> 
>  remove-dashes:
> -->8---
> 


-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231