[OpenAFS-devel] warnings fix

[Russ Allbery]

Marcus Watts <mdw@umich.edu> writes:

> Ok.  Many of the changes are indeed yours.  But

In case people are curious:

> dae49105c81b526f7fb3c3832984e9411c5c7ac2	jaltman@secure-endpoints.com

Bug fix for a patch from Simon that didn't quite do the right thing on
Windows.

> 73cef96bb335056963c31a6ec382cb4fa969b29e	jaltman@secure-endpoints.com

Likewise.

> c8920835ae9e33555a7d023cd0bd3a2f26a98b98	rra@stanford.edu

Something that I noticed while verifying one of Simon's changes.  I saw
the Linux warning about an insecure function being used and tracked down
why the right one wasn't being called.

> 215838d65734ad819d3bd27a2f715d1d6f68394a	rra@stanford.edu

This is entirely unrelated to Simon's work.  It was a prerequisite that I
needed in order to merge the Debian PAM patch.  The last happened because
we have Git now, which means that trying to do development isn't nearly as
painful as it used to be and it's much easier for me to take the patches
in Debian and figure out how to integrate them properly.  (I have one more
significant one to go.)

> Really, I'm thrilled to see things fixed.  I don't really care who or
> why these things were suddenly committed starting friday.  It still
> means that part or all of the changes I had duplicate changes that are
> "en train" by you or others.

Yeah, in general I would warn everyone doing OpenAFS development that the
new tools are so much better that the pace of development is likely to
increase.  In the short term, a lot -- in the long term, not as much as at
first, but hopefully still significantly.

This means that maintaining a large monolithic patch set outside of the
tree is going to require constant and significant rebasing.  You want to
get self-contained portions of it into the tree as soon as possible so
that everyone shares the work instead of having to keep it current outside
the tree.

Also, we may be doing some global cleanups in the future.  We'll try to
warn everyone in advance and discuss that on the list, particularly if it
will cause significant problems for pending out-of-tree patches.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>