Thread-, Signal- and Cancellation-safety documentation

[Alexandre Oliva]

On Mar 26, 2013, "Joseph S. Myers" <joseph@codesourcery.com> wrote:

> In general, where you've found bugs in glibc as a result of this work, 
> please file them in Bugzilla if not already filed there.

Yup, that's the plan (I filed one last week already).  How about cases
like those I brought up upthread, that are not so clearly bugs but
perhaps design decisions with consequences?  Should bugs be filed before
we decide they're bugs, even if ones we decide we don't want to fix?  Or
should they wait until we come to a consensus on whether there's even a
problem?

<side-rationale>

Personally, I have a profound dislike for composing text on/for web
interfaces, so I tend to prefer to keep my interfacing with wikis or bug
repositories to a minimum; I like wikis I can edit in local copies, then
check in/push changes to the server, like ikiwiki and svnwiki; I wish
there were bug tracking systems that enabled me to keep a similar
workflow, and that we'd adopt it ;-) That doesn't mean I oppose the
existence of alternate interfaces for those who prefer them, mind you
;-)

And no, the It's All Text plugin isn't quite enough :-), even if it
saves me from the additional annoyance of Cut&pasting from emacs: it
doesn't help when I'm offline, and even the subsecond latency of a web
interaction when I'm online is sometimes too annoying for me.

</side-rationale>

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer