On Sun, Apr 30, 2006 at 04:28:41PM -0500, Tilghman Lesher wrote: TL> In the future, to avoid these types of problems, I recommend that if TL> one of your bugs is closed, that you seek out either the person who TL> closed them or another bug marshal, either via email or via IRC, to TL> discuss why you think a bug should be reconsidered. The benefit of TL> IRC is that the discussion can take place with multiple developers at TL> the same time, so if your patch is still rejected, you can find out TL> quickly and move on.
It needs that bug marshals email would added to bug tracker docs. At now I hasn't emails all bug marshals. TL> In reality, what happened was I applied a fix in SVN for the problem TL> that was reported, but the fix was different from the patch that Denis TL> posted. Denis subsequently informed me that the extra code in the TL> patch that I applied was unnecessary, and I corrected the problem. TL> Other people reading this thread might conclude from Denis' post that TL> I obstinately refused to read the manpage for fseek(), and that is TL> simply not true. Ok. Problem was because I see one, you see another situation. I post bug. Bug was right, patch was right. You say that you apply another patch. Ok. I see in svn-commit that your patch worse and reopen bug. You _silently_ close. I reopen with text from manpage. You _silentlty_ close. What I can think? Only that you doesn't want to read my comments. I post message to asterisk-dev, because I doesn't like bloating code, and think that it's bad and you are doesn't right here. After that I see in svn-commit that you fix it applying my patch. All bug marshals can apply or reject patch, it's ok. But as contributor I need to _know_ was patch applied? Was not? Why it not applied? It's my bug, or bug marshal's? We need policy that can solve this conflicts. If you say nothing and close bug it's conflict situation. If you say "you are lamer, and doesn't know ..........." it _can_ be conflict or no, dependend by contributor. I would not complain for this answer, I need information, not conflicts. If you say "I doesn't want apply this patch, because ...." it's ok for all. At now we have first variant, that for me, and some others, looks bad. TL> The problem many patches experience is that they are fairly complex, I know it, and break all my internal patches to small independent parts. TL> and therefore, even those with commit access do not feel comfortable TL> committing them, especially if they do not have time to exhaustively TL> test the patch. What we need (and what you need to solicit, if you TL> are dedicated to having the patch committed) is to find more people TL> who are willing to apply and test the patch. In some ways, oej's TL> branch has gone a long way towards making patches easy to test, and TL> this is probably the way forward. In order to get your patch into TL> oej's branch, though, you need to contact him directly. I contact with oej directly, and he help me. But oej hasn't enought time for all this work. > >> Why Corydon76 can't do his work without conflicting with other > >> developers? > >> Why he close bugs without comment? TL> Generally, we close bugs without a comment after first asking, "Hey, TL> we pointed out a problem, are you going to fix it?" and then waiting TL> 3 days for a response. In fact, for most bugs which are closed this TL> way, more than 30 days pass without comment, and we have to conclude TL> that the reporter has lost interest. It's not closing without a comment. Closing without a comment was when I have conflict about fseek. > >> I think that today logging API in asterisk is a crap. Casper try > >> to fix it. Instead of helping him for choose right way, his bugs > >> was closed. Why? >> If you give me specific bug numbers I can try to find out. TL> Bug 6889. What we have here is a replacement of 2 lines of code with TL> 1 line of code. It's not complex, and it's not easy to make a TL> mistake coding this. All this substitution does is to create wholly TL> another macro that must be learned in order to code to the coding TL> guidelines. We have other macros, for fairly complex operations, such TL> as linked list maintenance, in which it is fairly easy to accidently TL> code something wrong. Macros are for making coding easier, and I TL> don't believe that these macros make coding any easier. This is why I TL> rejected his patch. TL> In this case, Casper then made a plea for his patch, on this list, and TL> Kevin intervened. Please note that the bug remains open to this day. Because I start to support this patch. Without patch like this I and Casper need to know -- is this interesting? And _why_ it's not commited? What doesn't right with this patch, and how can it be rewrited more clean? I has time for this work. But I hasn't time for flame. I need two things -- strict policy, and info about what patch would be commited, if some issues would fixes, and what patch would not be commited, and I doesn't need to spend my time for supporting this patches. I spend about 2 hours a day for trunk building tests and updating some patches. -- JID: [EMAIL PROTECTED] ICQ: 58417635 (please, use jabber, if you can) http://freesource.info/ _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev