[asterisk-dev] Corydon76 Issue Deleted: 0006925, 04-28-06 17:49 Corydon76 Issue Deleted: 0006920

[Denis Smirnov]

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: ds at im.seiros.ru
ICQ: 58417635 (please, use jabber, if you can)

http://freesource.info/