Am Freitag, 3. Juni 2011, 09:24:21 schrieb Luiz Augusto von Dentz: > Hi Hendrik, > > On Thu, Jun 2, 2011 at 5:42 PM, Luiz Augusto von Dentz > > <luiz.de...@gmail.com> wrote: > > Hi Hendrik, > > > > On Wed, Jun 1, 2011 at 2:11 PM, Hendrik Sattler <p...@hendrik-sattler.de> wrote: > >> Zitat von Luiz Augusto von Dentz <luiz.de...@gmail.com>: > >>> Hi Hendrik, > >>> > >>> On Fri, May 27, 2011 at 2:04 PM, Hendrik Sattler > >>> > >>> <p...@hendrik-sattler.de> wrote: > >>>> Am Freitag, 27. Mai 2011, 09:54:13 schrieb Luiz Augusto von Dentz: > >>>>> > Note that those are build warnings, not build errors (except when > >>>>> > using maintainer mode). > >>>>> > >>>>> Which is the whole point to force fixing and not just ignore them. > >>>> > >>>> Your commit message is wrong, that's what I meant! > >>> > >>> I did rebase your changes on top of my build fixes here: > >>> git://gitorious.org/~vudentz/openobex/vudentz-clone.git > >>> > >>> If you are ok, I will resend my 2 build fixes again. I also did a > >>> quick review on the other changes and noticed at least one use of c++ > >>> comment style '//' > >> > >> Citing from the ISO 9899-1999 (C99) standard: > >> "6.4.9 Comments > >> 1 Except within a character constant, a string literal, or a comment, > >> the characters /* introduce a comment. The contents of such a comment > >> are examined only to identify multibyte characters and to find the > >> characters */ that terminate it. > >> > >> 2 Except within a character constant, a string literal, or a comment, > >> the characters // introduce a comment that includes all multibyte > >> characters up to, but not including, the next new-line character. The > >> contents of such a comment are examined only to identify multibyte > >> characters and to find the terminating new-line character." > >> > >> It's the year 2011, so using > >> /* some comment */ > >> or > >> // some comment > >> are both absolutely valid C. Johan also mentioned this and I gave him > >> the same response. > > > > You are right that it is in fact a valid comment format as per C99, > > but you should have know that we mostly follow linux kernel code style > > (http://www.kernel.org/doc/Documentation/CodingStyle), which say: > > > > Linux style for comments is the C89 "/* ... */" style. > > Don't use C99-style "// ..." comments. > > > > Coding style is a matter of personal preference, please lets not start > > arguing about it now, besides you didn't really responded if the > > patches do look ok to you so I will assume you are and will resent > > them in a moment so we don't waste more time with this.
"linux kernel code style" has lots of non-sense beyond reasoning, not just comments. It is written nowhere that this style is used with OpenOBEX, neither was it discussed ever. And yes, I reject this coding style in many parts. > >>> and missing note about action command support on > >>> ChangeLog, can you fix those? > >> > >> Yes. I _was_ already mentioned but I changed it: - Add new definitions from OBEX 1.3 errata + Add new definitions from OBEX 1.3 errata: ACTION command and headers > >>> And please lets be more careful with > >>> codestyle, there are some files with space mixed with tabs and a lot > >>> of empty likes with tabs. > >> > >> I'll check that. The long week-end in Germany should give me enough time > >> :) > >> > >>> If those issues are fixed we can do 2.0 release. > >> > >> Where? > > > > In your tree, also please send them as a proper git patch (git > > format-path + git send-email) so we got them in the mail archive > > properly, if the series is too big e.g 10 > commits if possible break > > them in sub series waiting each series to be properly applied upstream > > before sending the next. I will try to help Johan to review your > > changes like sometimes I do for obexd. > > In case you meant where we will do the release, I was talking about > tag 2.0 upstream on git.kernel.org repository and create the tarball > as usual. Hint: "git send-email" itself is enough. I changed the patch you edited and reordered the patch set. I will send them. For the "trailing spaces" issue: how do I tell git to give me a warning for a _present_ patch? HS ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
