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

[Tilghman Lesher]

On Sunday 30 April 2006 11:36, Joshua Colp wrote:
> Denis Smirnov wrote:
> > On Fri, Apr 28, 2006 at 10:41:27PM -0300, Joshua Colp wrote:
> >
> > JC> Of course you'll have access to the bug tracker. Just because
> > a few of your JC> bugs were deleted does not mean you're going to
> > lose access.
> >
> > I think, that _deleting_ (not closing) bugs is _very_ bad anyway.
>
> You'd have to ask Corydon why exactly he deleted them.

I deleted them because I thought Kevin had already rejected them.
Casper has a way of endlessly reopening bugs after they've been
rejected, and I was attempting to avoid that pattern.  Kevin has since
clarified that he didn't really reject them.  Casper is certainly
welcome to repost these patches on the bugtracker.

In the future, to avoid these types of problems, I recommend that if
one of your bugs is closed, that you seek out either the person who
closed them or another bug marshal, either via email or via IRC, to
discuss why you think a bug should be reconsidered.  The benefit of
IRC is that the discussion can take place with multiple developers at
the same time, so if your patch is still rejected, you can find out
quickly and move on.

> Corydon manages func_odbc for example, but he still puts some
> changes as a bug note on the bug tracker and in a team branch so
> others can try it before it goes straight in.

Indeed.  Anything that is a feature enhancement and not a clear
bugfix is something that I attempt to solicit feedback on, before
it goes into trunk.  In fact, I've even had requests for this feature
to be backported to 1.2, which is why there is a backport which lives
at http://svncommunity.digium.com/svn/func_odbc/1.2/

> >>> Corydon is known to be particularly "active" in the negative
> >>> sense on the bugtracker conflicting as much as he can.

While I could post "Looks good" on every single bug, that is not
generally helpful (unless I have gone through and tested the patch,
in which case, it is).  What is helpful to look through bugs and find
problems, so they can be fixed.

> >>> I know dozens of people who had conflicts with him Tilghman.
> >>> Can you confirm it, Mr. Lesher?

I don't doubt that there are dozens of people for whom I have closed
bugs after the patches have been rejected.  However, I don't think
that this qualifies as a conflict, merely as a difference of opinion.
I, myself, have had dozens of patches that have been rejected (mostly
by Mark), but I would not consider myself to be in conflict with any
of those maintainers.

I'm not quite sure why Casper seems to have such a problem; I have
committed several of his patches, most of them fairly recently.  What
I have also done, however, is to reject some of his patches.  I'm not
sure why he thinks this is a personal attack.  I think I've outlined
some ways to avoid these types of misunderstandings in the future.

> > JC> Corydon may come across as negative but he is a very smart
> > individual who is JC> looking out for the best for Asterisk. We
> > all are.
> >
> > Ok, he very smart. But last my conflict with him was because he
> > doens't want to read fseek(3), and see that he doesn't know how
> > it works. I don't think, that it's smart to close bug, when
> > reporter has knowledge how this works, and bug marshall doesn't.

In reality, what happened was I applied a fix in SVN for the problem
that was reported, but the fix was different from the patch that Denis
posted.  Denis subsequently informed me that the extra code in the
patch that I applied was unnecessary, and I corrected the problem.
Other people reading this thread might conclude from Denis' post that
I obstinately refused to read the manpage for fseek(), and that is
simply not true.

> > E.g. come time ago I disclaim my patches for ztdummy, that really
> > improve it quality. This patch used by many peoples, that give it
> > from bugtracker, and all my clients. They are happy with it.
> > _Your_ clients complain about MeetMe problems without zaptel
> > hardware.
> >
> > My clients now has product with more quality, than your clients.
> > Why, if I give you this patches?
>
> Specific bug numbers help so I can look and see.

The problem many patches experience is that they are fairly complex,
and therefore, even those with commit access do not feel comfortable
committing them, especially if they do not have time to exhaustively
test the patch.  What we need (and what you need to solicit, if you
are dedicated to having the patch committed) is to find more people
who are willing to apply and test the patch.  In some ways, oej's
branch has gone a long way towards making patches easy to test, and
this is probably the way forward.  In order to get your patch into
oej's branch, though, you need to contact him directly.

The other approach that may help is to participate in one of the
realtime sessions, such as either a) IRC, or b) a developer conference
call, where you can discuss your patch with multiple developers and
get a real sense of what other developers think and if and how your
patch is lacking.

> > Why Corydon76 can't do his work without conflicting with other
> > developers?
> >
> > Why he close bugs without comment?

Generally, we close bugs without a comment after first asking, "Hey,
we pointed out a problem, are you going to fix it?" and then waiting
3 days for a response.  In fact, for most bugs which are closed this
way, more than 30 days pass without comment, and we have to conclude
that the reporter has lost interest.

> > 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.

Bug 6889.  What we have here is a replacement of 2 lines of code with
1 line of code.  It's not complex, and it's not easy to make a
mistake coding this.  All this substitution does is to create wholly
another macro that must be learned in order to code to the coding
guidelines.  We have other macros, for fairly complex operations, such
as linked list maintenance, in which it is fairly easy to accidently
code something wrong.  Macros are for making coding easier, and I
don't believe that these macros make coding any easier.  This is why I
rejected his patch.

In this case, Casper then made a plea for his patch, on this list, and
Kevin intervened.  Please note that the bug remains open to this day.

-- 
Tilghman