From 8cee055ec4fac00e59f19620ab06e2b30dccee3c Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 11 Jul 2012 22:39:59 +0200 Subject: IRC. --- hurd/debugging/rpctrace.mdwn | 80 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 79 insertions(+), 1 deletion(-) (limited to 'hurd/debugging/rpctrace.mdwn') diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn index fd24f081..df6290f7 100644 --- a/hurd/debugging/rpctrace.mdwn +++ b/hurd/debugging/rpctrace.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011 Free Software +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -89,6 +89,84 @@ See `rpctrace --help` about how to use it. braunr: the output of rpctrace --help should tell the default dir for msgids +* IRC, freenode, #hurd, 2012-06-30 + + hello. Has anyone faced with problem when translator works + fine, but when it is started via rpctrace it hangs? Probably you know + what can cause this? + mcsim: rpctrace itself is quite buggy + zhengda once did a number of improvements, but they never went + upstream... + well, he never explained how his fixes worked :) + GNU/Hurd is no different from other projects in that regard: if + you don't explain how your patches work, there's low chance that they + are applied + unless the maintainer has time to dive himself, which we don't + "it compiles, ship it!" + pinotree: i guess the hurd is different in that particular + regard :p + not different from linux + eh, they include staging drivers now :) + we have a sort-of staging tree as well, with netdde + we don't really care about stability there + youpi: actually, I think by now (and not to a small part + because of this episode) that we are too strict about patch + submission + well, review really is needed, otherwise source gets into a bad + shape + while zhengda's variant might not have been ideal (nobody of + us understands the workings of rpctrace enough to tell), I have + little doubt that it would be an improvement... + it happened quite a few times that a fix revealed to be + actually bogus + in that particular case, I agree + the problem is that usually what happens is that questions are + asked + and the answers never happen + and thus the patch gets lost + after all, when he when he submitted that patch, he had a much + better understanding of rpctrace than any of us... + sure + Linus is actually quite pragmatic about that. from what I've + seen, if he can be convinced that something is *probably* an + improvement over the previous status, he will usually merge it, even + if he has some qualms + when there is a maintainer, he usually requires his approval, + doesn't he? + in particular, for code that is new or has been in a very bad + shape before, standards shouldn't be as high as for changes to known + good code. and quite frankly, large parts of the Hurd code base + aren't all that good to begin with... + sure + well, sure. in this case, we should have just appointed + zhengda to be the rpctrace maintainer :-) + BTW, as his version is quite fundamentally different, perhaps + instead of merging the very large patch, perhaps we should just ship + both versions, and perhaps drop the old one at some point if the new + one turns out to work well... + (and perhaps I overused the word perhaps in that sentence + perhaps ;-) ) + about that particular patch, you had needed raised a few bits + and there was no answers + the patch is still in my mbox, far away + so it was *not* technically lost + it's just that as usual we lack manpower + yeah, I know. but many of the things I raised were mostly + formalisms, which might be helpful for maintaining high-quality code, + but probably were just a waste of time and effort in this case... I'm + not surprised that zhengda lost motivation to pursue this further :-( + it would help a lot to get the ton of patches in the debian + packages upstream :) + braunr: there aren't many, and usually for a good reason + some of them are in debian for testing, and can probably be + commited at some point + youpi: we could mark (with dep3 headers) the ones which are + meant to be debian-specific + sure + well, there are also a few patches that are not exactly + Debian-specific, but not ready for upstream either... + antrik: yes + # See Also -- cgit v1.2.3