RE: nanosleep.c & winsock.h (was Re: Windows Build Broken - Feature Branch)

[Conrad T. Pino]

Hi Derek,

> From: Derek Robert Price
> 
> The impetus behind using the GNULIB functions is to offload some of
> the CVS maintenance, sharing it between several projects that also use
> GNULIB.  CVS has only three full time committers at the moment and its
> a big project.  With GNULIB, when one project hits a portability snag,
> the fix can be shared between several projects.

This seems like is a good direction I can support.

> As for why I direct a newbie to talk to another project, it is for
> several reasons, not the least of which being that I don't really have
> the time.  I don't have the time for the stuff I do accomplish!

That's one reason I agreed but let's not forget the Peter Principle.

> Secondarily, you are also the reporter of the problem and, at least in
> theory, have knowledge of the problem's parameters and access to the
> appropriate environment to test out solutions.

Hmm... I didn't know reporting a problem carries the responsibility to
       fix it.  Thank you.
Ahh... Now I understand why the issue was known but not reported.

Nice theory.  Too bad it doesn't always work on newbies.  Sigh...

My goal is to work cooperatively when time permits and includes the
testing of ideas that may not look promising since negative results
are frequently useful.

> If I was to talk to
> them I would mostly be a go-between in this case.

Hmm... I feel the same way.  I believe the technical issues are now
well known.  What remains appears to be which compromise is best for
both projects and that requires a knowledgeable value judgment call
in a negotiation process I don't feel qualified to conduct.

The last proposal forwarded was to ask Jim Meyering to consider adding
a "struct timeval" definition in "nanosleep" in some fashion.  IMO it's
merits are low when compared to using "usleep" which make its prospects
look dim to me.

Since the "usleep" question posed to Jim Meyering was aborted abruptly
and without consultation I fail to see an incentive to participate but
perhaps that was unintended.  Nevertheless I suggest forwarding both
proposals and deferring to them the final judgment on the disposition
of their code.  If this is an acceptable proposal, I'll carry the ball
otherwise it will remain in your good care.

> Thirdly, the GNULIB
> folks tend to have a much better handle on portability and standards
> than I and you will likely find yourself on similar footing to me when
> you talk to them, and possibly better due to my lack of Windows knowledge.

Thank you for the credit despite my skepticism but I won't let that
stop me when forward movement is required.

> Finally, my avoidance of adding code that only runs on Windows is
> because it has a tendency to suffer from bitrot when the main code
> changes.  Like we're seeing now.

What!!!  No Windows maintainer!?!

Bitrot will *always* be there because there more bases to cover than
there are players.  Nothing new here.

In the meantime the Windows build has been broken for 2 weeks for the
lack of a hack.  I'm well aware of the tendency of hacks to accrete.
But what difference does it *really* make if the Windows code rots at
point B rather than point A?

> I'm glad that you are taking an
> interest in the Windows code, and I am grateful for your help, but I
> am yet to see that you will still be maintaining the Windows code a
> few months or years from now.

Thank you for the kind words and making your appreciation known.

I believe you *never* will know who the *future* Windows maintainer
will be since working crystal balls aren't available.

The issue isn't peering into the future.  The subtext is trust.

Trust is required in personal relationships but has limited value
in goal oriented enterprises.  In any population there will *always*
be good guys *AND* bad guys.

An enterprise should be concerned only with the distribution.  If the
distribution of good guys is greater than 50% then an admission policy
should be loose since the benefit of a larger group will exceed the
losses incurred by the bad guys that make it in the door.  Yes there
*will* be messes to clean but there will be more players to help too.

I'm not saying the entry barrier should be zero.  But low may serve
much better than high since in my experience good guys *do* prevail.

I assume committer privilege isn't tenure and is withdrawn for cause
which is a necessary predicate to such a recruitment strategy.

> If we offload on GNULIB or find
> solutions using widely accepted standards which the folks at M$ were
> generous enough to support, then we don't need the full-time Windows
> maintainer who has yet to make themselves known.

The M$ crew has created many $ opportunities for me and I'm grateful.
Nevertheless I really hate those guys because you can *always* count
on them putting their interests first and they'll not hesitate to kill
you commercially when the opportunity presents itself.  I want to be
part of bringing them down a notch hence my presence here.

CVS can succeed despite M$ but I don't look to them to make it easy.
Maintaining a Windows bridge can make a positive difference to draw
more users.  I don't want Windows support to go away.

The GNULIB is showing limitations but IMO not sufficient to warrant
abandonment.

What puzzles me is why "windows-NT" code tries to be POSIX compliant
*within* itself when IMO that only aggravates the rot problem on the
M$ side since they *do* play late and loose with POSIX standards.

IMO "windows-NT" should base it's implementation *directly* on the
Windows API since that's what M$ can't change quickly without hosing
their customers.

I wasn't aware committers created themselves.  All I've read on open
source projects implied committers/maintainers earn it & are invited.

Nevertheless I now make my willingness to maintain the Windows build
and "windows-NT" code *formally* known however I reserve the right to
die anytime with or without notice.

And while we're at this, I nominate Dennis Jones and Wolfgang Loch
for consideration *with* my application since IMO more is better.

> As I said, I have a
> Windows machine and a copy of MSVC++ 6.0, but I simply don't have the
> time.

This looks like a delegation opportunity to me.

> Sorry for the rant and any frustration on your part, but the CVS
> maintainers are all volunteers, we do have some idea what we are
> doing, and generally we try to do the things we think are in the best
> interests of CVS.

I'm a big supporter of recreational ranting and whining.  I find them
soothing to the heart and spirit.  Apology optional since I see it all
as intrinsic.  Frustration is one of many reasons it's called work.  

I'm interested in the wealth of knowledge I presume is already here.

I have no questions regarding motives of the CVS team.  "Best" is a
value judgment and coming to a values consensus is the challenge.

> Cheers,

Ditto.

> Derek

Conrad