[pulseaudio-discuss] PA now compiles on OS X

[Colin Guthrie]

'Twas brillig, and Kim Lester at 31/07/09 17:22 did gyre and gimble:
> 
> On 01/08/2009, at 12:55 AM, Lennart Poettering 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.

Yeah, I think git brought about that change - inline reviews of emails 
and the fact that "a patch is an email" kinda makes this the case.

Generally you'll commit separate patches as separate posts to the list - 
git send-email makes this a breeze. For and example see Lennarts own 
post to the alsa list today:

http://mailman.alsa-project.org/pipermail/alsa-devel/2009-July/thread.html#19861

(neer the bottom : the subject start: [PATCH 1/4] .....

It makes it easy for inline review of changes/comments etc. (which I did 
to Lennart's commit over there as you'll see!)

> 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.
> 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?
> 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.

I think it's more about the what the fixes do. In this case to "make OS 
X work, there are several small but ultimately unrelated (in the wider 
picture) changes.

With git is quite easy to create these separate commits locally (on a 
branch), post separately for peer review  and then make changes to 
indivudual commits+reapply other commits.

Ultimately the git tree you start off with initially is unlikely to be 
the one used after review, but git makes this pretty easy (git checkout 
-b new try <last good commit ref> + git cherry-pick and such like are 
your friend here)


>> 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.

For the record, I agree with you. I also like balanced braces (e.g. if 
one side of an if/else has braces, both should have them), but that's 
another tangent. I code for several projects with various different 
styles. It's annoying switching around but you get used to it :)

> Still at least you're very sensible with 4 space indents. I just don't 
> get these 3-space indent weirdos!!! :-)

I prefer 2. /me ducks.


:p

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]