"Davide G. M. Salvetti" <sa...@debian.org> wrote: >>>>>> AT == Andreas Tille [2009-8-20] > > AT> Your arguing actually was: > > DGMS> ... you can start by studying how the software > DGMS> is packaged and of course you are welcome to send in patches. > > AT> as a response to a patch which was provided inside #539749. I'd > AT> call this weak arguing (at best). > > Then I suppose my English is not up to yours, as I still fail to > understand how that paragraph above of mine can qualify as "arguing".
I don't want to "argue" about the meaning of english words (which isn't my native language, too). But I also think that your style of working is not encouraging for collaborators. You actually *do* accept patches, sometimes as-is, sometimes you take them as inspiration, but solve the issue your way. That's okay. But you do not talk to the patch submitters, you often don't tell them whether you think it's the right approach, whether you'll fix the bug soon, or whether you plan an upload at all. Remember my NMU somewhen just before the freeze of etch (I think)? It was completely useless, but you never said anything but "I'll upload in time", and when I NMU'ed it was about 1 day "too early" before the very last chance... In this case, it would have helped if you could have provided the packages you were working on at some public place, so that I could have seen how far you actually got. And so that I could notice that you were really working hard on the final polishing. Without that knowledge, I feared that you might misjudge the effort needed, and just miss the deadline. So I NMUed... > I already stated that I intend to keep maintaining the package. Why do > you say that "(I) leave potential helpers completely unclear about (my) > intentions"? If you are looking for a timeline, I'm sorry, but I don't > feel like promising. I'd rather work on it and upload it when I'm > ready. That's an important point: If you want real collaboration, not just "anyone may send patches, and I may take them or not", you'll have to start talking about timelines. That doesn't mean you have to commit to them like in a commercial project, but they should be discussed. Without that, you'll soon loose your collaborators again, I fear. > AT> So I'm forced to find a private solution if I do not want to > AT> conflict to our social standards. > > I can't parse the meaning of this sentence. If you're saying that you > need some sort of official blessing to have the problem "qualify for a > NMU", you have mine. If you're saying that you would rather to have > myself working on the issue, then please wait. If you mean something > other, sorry, I do not understand. He means (I think) that the problem is pressing enough for him to want a solution *really*soon*. Since he can't NMU for a non-RC bug without your explicit Okay, the only "solution" for him would be to use a locally patched package, which is bad. And "please wait" is exactly what discourages people. If you would say "I will make an upload end of next week", fine. If you'd say "I'll not manage an upload until end of next month, but the patch looks fine. Feel free to NMU after thorough testing", also fine. But "please wait", and nothing else, is just awful. > I do not see how I am blocking any package. You need not to maintain a > package to help packaging, nor do you need it to upload it. It seems you block people from testing emacs23 if one of their main uses is TeX stuff. BTDT - using different emacs versions for different tasks is not an option if you want to do real work. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
