[pulseaudio-discuss] PA now compiles on OS X

[Lennart Poettering]

On Sat, 01.08.09 02:22, Kim Lester (kim at dfusion.com.au) wrote:

>> Please, next time attach them uncompressed and inline, makes it easier
>> to comment on.
>
> Ok - but historically newgroup readers have tend to flame people who add 
> 20K+ of patches inline on a discussion group....
> Times change.

20K bytes of patches should be fine.
10K (as in number) seperate patches to the ML would of course not be fine ;-)

As long as you only have 5 or maybe 10 patches sending to the ML is
fine. Otherwise a git repo is great, too.

>> Also, could you please split those patches into logical units?
>> i.e. one patch that adds the clock_xxxx stuff, and another one that
>> adds the semaphore stuff?
>
> Hmmm. I probably can but it's going to take me a number of hours to sort 
> out and I can't do it until later next the week.

Should be easy to do actually. "git add -p" is a wonderful invention
to make this very very easy. i.e. if you made a lot of changes in your
checkout and want to split them now into seperate commits just do a
"git add -up" and git will ask you for every little change whether you
want to stage it or not.

git add -p is one of the reasons why git is heaven, and svn is not.

> If you _have_ to have it let me know and I'll try and get around to it.
> I understand they are orthogonal edits but surely they are of relatively 
> little value individually?

Seperate changes really matter. You don't need to seperate your
commits too much. But otoh a single commit for everything is a bit too
little, too. Just be reasonable. I'd probably split your changes up into
3 seperate or so.

> I have always tended to commit a logically related and self consistent  
> set of changes - in this case "make OS X compile/run".
> Is it a "git" mindset or a "PA" mindset to commit minimal deltas ?
> I will stay minimal in future.

That's a git mindset. And I am not sure if "minimal" really hits the
nail here. We don't want one-commit-per-line commits. All we want is
that the patches can be digested easily and understood seperately.

>> Also, you'd do me a great favour if you could follow the rules pointed
>> out here:
>>
>> http://pulseaudio.org/wiki/CodingStyle
>
> I say tom-ah-to .. you say tom-a-to.
> I've read it now.
> I happen to voilently disagree with point 3 :-)  given space is not a  
> problem these days. I *like* my braces to line up vertically. Its far  
> more elegant IMHO than opening braces way off in never-never land on RHS 
> of screen.
> Still at least you're very sensible with 4 space indents. I just don't  
> get these 3-space indent weirdos!!! :-)
> I'm getting too old and grumpy to follow everyone else's preferences but 
> I'll try next time :-)

Coding style is a matter of taste. As such people can discuss it for
ages and ages. The wiki page just describes how indenting should look
like in PA, but I am very pragmatic about it and am trying not to be a
dick. 

>> I think most of this should be documented in the commit msgs or even
>> in comments, or in the wiki.
>
> Is there a recommended maximum length/style for commit messages?
> Surely you wouldn't want most of that README in a commit message - I  
> don't mind - I didn't see any wiki commit message standards/ 
> recommendations.

Sometimes commit messages can be just one line, sometimes they can be
much longer. It really depends what your commit is about. It's always
good to reduce the commit message to what the commit is actually about
instead of writing novels. Again, just try to be reasonable, common sense.

>>> * Calls to clock_*  have been replaced with pa_clock_* wrapper except
>>> for the one file alsa-time-test.c  where there didn't seem any point
>>> !?
>>
>> Sounds good. pa_clock_settime() should be dropped though, since we
>> don't need that, do we?
>
> Probably but it's a threesome group of missing functions. I was just  
> trying to be complete...

Having code in PA that is never tested and hence bit rots quickly is
bad.

> I was thinking of creating a standard "missing" library for OS X that  
> others could use in the future.

There might be one already. Names like libiberty or libbsd come to my
mind here.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4