Hi Dominik, On Tue, 2012-11-27 at 09:41 +0100, Dominik George wrote: > Ask the person who wrote the RFS template generator. On the other hand, > it's the Debian communities package. Maybe it should say "my version xyz > of package foo". If you take any offence on this, I really pity you. I don't take it as an offence, I was just curious why did you write it as your package.
> > Why do you NMU immediately when I'm known for quick reply? > First, because I can, second, because that's what the DDs at the BSP told > me to do. It's always friendly to ask the maintainer first, s/he may have other things waiting in the queue and/or know a better way to achieve the same goal. > > Why do you ignore other fixes that I've mentioned to you in > > my previous mail? That includes collation with RMs. > You did not mention any fixes. You mentioned a pending upload. I thought > you were referring to the pending upload of 1.2.0-2 to *wheezy*, which > does not include any fix for the issue we are discussing. I gave you the URL to check and you noted that it doesn't fix the bug you are referring to. For me, it was look like you checked the attached diff before answering. There's no need to do an extra upload to make an already uploaded version available in testing (Wheezy this time). A freeze exception is enough from a release manager. > How about being a bit more specific next time? I also find that you failed > to post any details of your fix to the BTS. Even though you may be known > for "quick reply", other parties might be interested in how to fix the > problem beforehand. You even may want testers for a patch before uploading > it. In any case, the BTS report log lacks any hint whatsoever about your > fix. ? Please check again #682172 [1], it contains details and attached diff files. Sure, I'll CC everything next time to the relevant bugreports. > > Anyway, I've included your patch in -3, even if I'm not convinced about > > it. I think it would have been better to send HUP signal first, then > > after a specified time send TERM signal to couchdb. > > Abusing SIGHUP for shutdown in my opinion is a major violation of > well-estabished standards that should be discussed with upstream. As noted, it's not CouchDB upstream, but the Erlang VM. It does not ignore SIGHUP itself, but inherit that mask from apt-get . The Erlang VM actually doesn't have any possibility to change the signal ignorance mask as I know. Thus even if I note it to upstream, it's a language barrier and known already. > In conclusion, Debian is a community-effort. I am very convinced that no > single person owns any part of it, so no single person should ever take > offence on someone else helping them. I agree on this. As a community effort, it needs coordination. You missed to ask the maintainer first, that you've an RC bugfix, would s/he upload soon or an NMU would be better after twenty-four hours. Instead, you immediately ignored the maintainer and asked everyone for NMU sponsorship. I asked questions to learn what I can do better next time to prevent misunderstanding. It was you who make offence and even CC to a closed bugreport. > If you had e-mailed your own patch > for the problem to the BTS right when you wrote it, also mentioning that > you are about to upload it, would have both solve the problem you see > *and* saved me and the fellows at the BSP quite a few hours of work. A discussion was going on an other bugreport and you were given with an URL of that. You are right that only when I've learnt you are working on that issue. I had the presupposition that you'll check it and when you replied that doesn't fix the issue, I thought you did. > Please note that you posted your tiny little hint about some pending > upload only *after* you realized that we were doing work on the issue. I agree on this, I should have tag the bug as pending. The little hint about upload pending contained the URL with the attached diff and the information release managers are involved in discussion. > Please also realize that Frank and I spent almost two full days on the > issue, discussing with dpkg and apt developers and shell gurus all > possible ways of solving this issue in a way that does *not* violate > upstream's ideas of signal handling. Although you included the fix in the > end, and although you claim to be *quick* at it, please try to recognize > your fellow community members' work and also try to understand if they > like to get credits for it. I do note others work in changelogs, see some quick examples[2][3][4]. About the SIGHUP change, you mentioned '[varacanero]', that I couldn't parse. On the other hand, you are noted in couchdb_sighup.patch as it was your work and I do honor it. Regards, Laszlo/GCS [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682172 [2] http://packages.qa.debian.org/s/sqlite3/news/20120516T212014Z.html [3] http://packages.qa.debian.org/p/python-eventlet/news/20121117T144838Z.html [4] http://packages.qa.debian.org/w/whatweb/news/20120605T213524Z.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
