Re: [PATCH] mingw: make stderr unbuffered again

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I think you misread me.

Regarding 'pu', there is a chicken-and-egg problem involved. Most of the days, the tip of 'pu' passes the test at least for me.

At the end of day's integration cycle, I may find that 'pu' does not pass the test for me [*1*]. It is not unusual to see new multiple topics come to 'pu', each of which may test well in isolation but have hidden interactions with topics already in 'next' or 'pu' that are exposed only when merged to 'pu', and it may be too late in the day for me to find which one of these new topics is problematic.

I could choose not to merge any of them and push 'pu' out with no new topics. Or I may choose to push it out anyway, so that other people who are working during the remainder of 24-hour in different timezones can notice and find which new topic is broken [*2*].

And that is why I explicitly say that 'pu' may not even build. It shouldn't be taken as a discouragement to people from looking at it, which seems to be how I read you to misinterpret it. It is the opposite---a breakage at the tip of 'pu' is an invitation for people to help.

If nobody steps up and says "the tip of 'pu' does not build and that is because of this topic", I'd be irritated enough to find which topic is broken myself and then ask the author of the offencing topic for help. If the topic is left broken after that, it will be ejected from 'pu', because I cannot use 'pu' for helping to polish other new topics that wants to cook there unless I do so.

Of course there are platform- or environment-dependent breakages that would not cause my tests to fail [*3*]. Again, people with different environment can step up to help, if these topics are included in 'pu'. You would recall that you called out one topic [*4*] that did not build in your environment and the topic was ejected after your message (but not before---there wasn't a way for Window-less folks to tell that it was broken IIRC) from 'pu'.

In a near-by thread, somebody wondered if we can add an integration branch 'pr' that is beyond 'pu' and includes everything ever posted to the list, and I explained why I won't have time for that. But I think the spirit of suggested 'pr' is what 'pu' already is---it is a collection of promising topics that can be merged into a seemingly consistent whole, which may or may not build and the purpose of the branch is to contain them in one place so that people can find which ones need unbreaking. Testing the tip of it alone and complaining that it is broken does not help much, but figuiring out which topic merged to it is broken does, by unblocking other topics in 'pu'.

[Footnote]

*1* If any other integration branch (including 'jch', which is
    somewhere between 'master' and 'pu' and beyond the commit with a
    tree that matches 'next' aka "pu^{/^### match next}") does not
    build, I pull overtime ;-)

*2* When there is only a new topic that breaks 'pu' for me, it is
    easy to decide not to queue it and send a note to the author of
    the offending topic, and that does happen a lot, but not always.

*3* I do not have p4 and I may not have svn installed so my tests
    may not even cover them.

*4* I think it was nd/worktree-move but may have been another topic.