[PATCH] Have the smbcli_session record the OS and Native LANMAN of the remote server

[Gerald Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Sam,

> I realise that you and Metze think that is 
> what I've done, but I think you've mostly
> been looking at Samba code which happens
> to follow your preferred style (perhaps you
> wrote most of what you look at).

Hahah...Sorry.  :)  On this one you are making an
invalid assumption.  I've in fact spent most of
the past 12 - 18 months in the likewise-open code
base which has an entirely differently style.
For example:

http://git.likewise.com/?p=likewise-open.git;a=blob;f=lwio/server/pvfs/fileBasicInfo.c;h=84734fc3da7d4d579e73665d04e887bbe582bcab;hb=c7153ecc58a2047669c6d95a870cf58283bd6a54

> However I've not used styles which aren't widely 
> used in the samba4 codebase, as I show in answer
> to a point below.

Coding style in Samba has been more oral tradition
in the past.  Think of the styles as rings in a tree.
You could normally figure out out how old code was by
the indents. :-)

I think even now, there is not strict adherence as
you point out.  So three issues at risk of starting an
even longer thread.

(a) Shared repositories will code style divergences
    unless there is some peer pressure to enforce
    guidelines.

(b) Migrating a code base (and in this case two
    branches historically driven by different teams)
    to a consistent coding style is hard.

(c) Rewriting other patches inhibits the growth of
    the project's broader developer community.

So then iot follows that (a) is an internal issue
for the core dev team, while (c) is an external
facing problem.  (b) can only be solved once
(a) and (c) are solved.


> I'm more worried about how much I have to re-work 
> patches to meet other personal styles, and then I
> have to hack up my wip tree afterwards to
> contain the new "approved" patch, sometimes after 
> our own tree has undergone internal testing.
...
> There's more than one established convention widely
> present in the code base.

Agreed.  But this should not really be a question of
personal style.  If it matches README.Coding and
prog_guide4.txt you should be safe.  If you follow
that and the patch is refused due to style reasons,
it is the project's fault and not yours.

> Whether or not this patch is accepted, I'm still
> worried about the other 150.

I can't really comment on accepting patches.  I removed
myself from commit access to the main repo in lieu of
working strictly in my personal branches.  But in response
to the other 150 patches,

(a) It's always better to know what the rules are, and
(b) it's always better to separate the drafting stage
    from the publishing stage.

Metze or Volker hold to power to accept the patch.
I just like discussions about distributed development
and community processes ;)

All this opinion and $1.87 will buy you a tall coffee
at Starbucks.



cheers, jerry

- --
=====================================================================
http://git.plainjoe.org/                                         CODE
"What man is a man who does not make the world better?"      --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ+IEsIR7qMdg1EfYRAnohAJwNvUwQIzrPGc0fep6qkG6Zzl+JZQCeNKt5
lME1RbXArEMdJmDvwnWYUu4=
=xAlC
-----END PGP SIGNATURE-----