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

[Derek Robert Price]

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

Conrad T. Pino wrote:

>>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.


Well, it does when the maintainers don't have the time, inclination,
or resources necessary to fix it.  Unless, of course, someone else
picks up the ball.  You never know with open source.  If you were
paying us to maintain CVS, we might be obligated to fix the problems
you report.  :)

>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.


Yes.  I think I'm leaning towards a nanosleep macro as suggested by
Shaun Tancheff or simply implementing nanoslep in woe32.c, as you
suggested earlier.  I just wanted to feel I'd exhausted the other
possibilities first.

>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.  


It was.  I believe I mentioned usleep to you again for lack of  my own
sleep...  I jumped in when I saw you had brought it up on bug-gnulib
and I remembered that it wasn't really an option.

>>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 agree, but I tend to be the de facto Windows maintainer and I'd
rather not be since I don't have the time.  As such, I prefer general
solutions, as I've explained.

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


Actually, traditionally, it has been tenure, but the same unanimous
vote that makes a committer probably, at least practically,
corresponds to a unanimous -1 vote to unmake one, if conditions were
serious enough, but the situation has never come up.

>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.


Well, I haven't experienced them _removing_ POSIX compliant functions
yet.  Windows just tends to lack them, AFAICT.

>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.


Interesting idea.

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


What's the difference?  You create yourself, as mentioned in the
DEVEL-CVS file, by showing sustained interest and quality patches over
a period of time.  Remaining reasonable, patient, and considerate of
others doesn't hurt.  Then, you might be invited.

>>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.


Good luck.  Send $$ or patches.  :)

Cheers,

Derek

- --
                *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFApMSpLD1OTBfyMaQRAnpzAJ90reygeQGkXyxsqj1IMTURxPHY2wCg3IfP
w0aIAtnRKrtIwKm36L+jH1k=
=6JEg
-----END PGP SIGNATURE-----