Bug 40000

This has already basically been done on master, in commit b1e28fba0bcb, so I omitted b0b5f9b when I merged dbus-1.4 into master.

Please get patches reviewed as described in HACKING rather than just committing things, and please make pure bugfixes on the dbus-1.4 branch (and merge that branch into master) rather than cherry-picking.

Hi Simon, 

(In reply to comment #1)
> This has already basically been done on master, in commit b1e28fba0bcb, so I
> omitted b0b5f9b when I merged dbus-1.4 into master.
> 
> Please get patches reviewed as described in HACKING rather than just committing
> things, 

nice to hear that there are reviewers for the windows stuff :-) 

> and please make pure bugfixes on the dbus-1.4 branch (and merge that branch into master) rather than cherry-picking.

Also if this issue is already fixed in master ? 
Does this case not need a backport ? 

> (and merge that branch into master) rather than cherry-picking.

Which git command sequence should be used for does 

BTW: I tracked in the last month only the master branch and recognized some win32 compile errors in master, which i fixed first. 

After that I recognited different compile problems in dbus-1.4 which I fixed then.

(In reply to comment #2)
> (In reply to comment #1)
> > Please get patches reviewed as described in HACKING rather than just committing
> > things, 
> 
> nice to hear that there are reviewers for the windows stuff :-)

I'm aware that we're short of people who develop on Windows, but it seems better to have review from someone who doesn't fully understand Windows (e.g. me) than no review at all - particularly for things that touch cross-platform code, like this does.

(Now that I've got Autoconf cross-compiling to mingw64 to work, I can at least compile Windows-specifics; one day the regression tests might even all pass under Wine...)

> > and please make pure bugfixes on the dbus-1.4 branch (and merge that branch into master) rather than cherry-picking.
> 
> Also if this issue is already fixed in master ? 
> Does this case not need a backport ? 

If a bug is fixed on master but not in dbus-1.4, then that means someone fixed the wrong branch :-) but yes you'd need to cherry-pick (and perhaps backport) in this case.

> > (and merge that branch into master) rather than cherry-picking.
> 
> Which git command sequence should be used for does 

git checkout master
git merge dbus-1.4
fix the conflicts (usually just NEWS)
git add ${the_files_that_had_conflicts}    (or use git gui, like I do)
git commit

(In reply to comment #0)
> Instead of using DBUS_INLINE, define "inline" to have its C99 meaning

For the record: fixed in git for 1.4.16 and 1.5.8 (I've merged it into master).

Thank you for committing this, but if you apply patches from someone else (e.g. me in this case), could you please set the author to be the patch submitter and add a "Reviewed-by: you" pseudo-header, rather than the other way round? I didn't review this patch, I wrote it!

For patches from Bugzilla that were produced with git format-patch, like all of mine, you can use something like "git am < 0001-Fix_some_stuff.patch" to apply the patch with authorship information, and "git commit --amend" to add the Reviewed-by.

The other way to do patch review is to comment and say you've reviewed it and it looks OK, and the patch submitter can apply it themselves (this is what we normally do in Telepathy, if the patch submitter has commit access, since they usually know how to test the patch better than the reviewer does).

> Thank you for committing this, but if you apply patches from someone else (e.g.
> me in this case), could you please set the author to be the patch submitter and
> add a "Reviewed-by: you" pseudo-header, rather than the other way round? I
> didn't review this patch, I wrote it!

This is clear, but in this specific case I cherry-picked the related patch from master, so someone else is the author. Because your patch is identically you made the review :-) 

> For patches from Bugzilla that were produced with git format-patch, like all of
> mine, you can use something like "git am < 0001-Fix_some_stuff.patch" to apply
> the patch with authorship information, and "git commit --amend" to add the
> Reviewed-by.
> 
> The other way to do patch review is to comment and say you've reviewed it and
> it looks OK, and the patch submitter can apply it themselves (this is what we
> normally do in Telepathy, if the patch submitter has commit access, since they
> usually know how to test the patch better than the reviewer does).

Thanks for this hints.