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

[Joshua Colp]

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.

> 
>>> Do you really? Are you really open?
> JC> Yes, we are. Your suggestions though have to make sense and people have to
> JC> agree with them. It may not seem like it but we actually do discuss bugs in
> JC> realtime on IRC if it is brought up. A few of your bugs for example were
> JC> brought up and everyone made their point. Some of your patches were
> JC> accepted, some were not. It's the way it goes.
> 
> IRC is very time consuming.

It's only time consuming if you stay on there all the time. If you are 
simply trying to push your bug along, all you have to do is go into 
#asterisk-bug or #asterisk-dev and say so. If a bug marshal is around, 
or someone who can help you then it actually goes quite fast.

I even specifically ask people in #asterisk and #asterisk-dev if they 
have bugs open that I can do while I'm working on the bug tracker 
because the real time element REALLY helps.

> 
> I have time for creating and reviewing asterisk patches.

Great.

> I have time for discussing them in bug tracker and maillists.

Peachy.

> I hasn't time for discussing them in any realtime communication method.
> 

Then you'll have to deal with the pace at which things go. We look at a 
bug, paste a note then wait for a reply. Some time later when we then 
have time to look at bugs again we then go back to the bug and see if 
there is a reply and go from there. Due to the fact that everyone has 
their own schedule and everyone is in their own timezone it can go quite 
slow. The bigger the change the more discussion may go on as well.

> I suuppport now greater then 50 patches localy. It's like fork today.
> I can help team with 

I'd like to note one thing here. Just because a person is a bug marshal 
does not mean their own patches will go directly to SVN unless they have 
absolute responsibility over it, and even then not always. A bug marshal 
might not also have commit access to subversion. It takes time to earn 
it, we have to get to know you.

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.

North Antara/Qwell is the new sole maintainer of chan_skinny (way to go 
Qwell!) and he puts all of his changes in a team branch for people to 
try before merging.

While these people do have commit access to their respective items - 
they still put it out there for testing like you do on the bug tracker.

> 
>>> Corydon is known to be particularly "active" in the negative sense on
>>> the bugtracker conflicting as much as he can.
>>>
>>> I know dozens of people who had conflicts with him Tilghman. Can you
>>> confirm it, Mr. Lesher?
> 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.

Find another bug marshal then. If you believe the bug has been treated 
wrongly, then get someone else to look at it. This goes back to the IRC 
point - if you go on IRC you can talk to more then one bug marshall at a 
time, along with the original one, and come to a group decision.

> 
> Ok. I'm stupid lamer. But I know how works some parts, and know how to fix
> it. I have time for do this work. And I _would_ do this work anyway.  If
> Digium whant to use my work -- use it! If don't want -- say "We doesn't
> need your contributions", and conflict ends. I create my own fork, and my
> and my clients would be happy.

The people who decide whether your patch goes in are not all Digium 
employees. Control of the core source tree has been opened up to others.

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

> 
> Now I write patch in team/oej/codecnegotiation branch. It's very simple
> API _addon_, that doesn't break anything, and can be easily added before
> full freeze. But this really can make future changes in codec negotiation
> (like 4825) easier.
> 
> But it nor reviewed or commited.
> 
> Why?

We don't control that branch, it's oej's and it's up to other people to 
test it. We depend on the community as a whole to test things to make 
sure they work fine before going in. When oej feels that branch, or even 
parts of it, are fine for merging then he will bring it up. If you feel 
it's going slowly - then get people to test it and report back.

> 
> Why I and many others need to spend time for flame?
> 
> JC> While more people do have SVN commit access though, we are still having
> JC> problems with the bug tracker. As it is there are very few bug marshals left
> JC> to handle things. It's a HUGE job and while people make the best effort they
> JC> can, it's still futile because you get burned out so fast and it takes so
> JC> much of your time. Eventually everyone just needs a break and their
> JC> participation fades.
> 
> Why you doesn't get help from community? Some peoples can take part of
> this work.

We have gotten help from the community. MANY people have given up time 
to help in the past, and exactly what I said above has happened. Right 
now there's only about 8 active bug marshals including myself, 3 being 
Digium employees who, while it is part of their job, do have other 
duties and projects. I thank everyone who has given up their time to 
help with the bugs. If anyone does want to give a go at being a bug 
marshal - drop me a line via email.

> 
> JC> This isn't true exactly, some people who contribute to OpenPBX.org do also
> JC> contribute back to Asterisk.
> 
>  - OpenPBX now _have_ T.38 support, and we hasn't;

T.38 passthrough support is going to be going in before 1.4.

>  - OpenPBX use automake, but we doesn't;

We just recently moved to using autoconf and are still ironing out the 
bugs for that and learning it. Tackling too many build related things at 
once will just slow everything down.

>  - OpenPBX move some parts to libopenpbx, that simplify automatic finding
>    for unresolved symbols, but we doesn't;

They chose a different path. OpenPBX.org is a completely different 
project then Asterisk, and they can go how they want. As always I wish 
Nathan (the OpenPBX.org leader) the best of luck.

> 
> JC> I'm going to be honest with you, and everyone out there. The Asterisk
> JC> community is a very diverse group of people. We are all aiming for the same
> JC> thing though, to make Asterisk bigger and better. In order to do this we
> JC> must learn to cooperate, help each other and come to the realization that
> JC> while you may post a patch that seems perfectly logical and great - it may
> JC> not appear to others to be that way. By posting a bug you're opening
> JC> yourself up to others to come in and take a look and decide whether it is
> JC> really valid or not. If the answer is no, then you must learn to accept and
> JC> deal with that.
> 
> But who has rights to accept or reject patches? _Any_ bug marshall?

A bug marshal looks over the bug tracker, all the bugs, and patches. If 
they look at a patch and determine that the patch there is no good and 
won't be accepted (for whatever) reason they can then either give the 
reasons for not yet accepting it and let the person update it, or close 
it saying why.

They also push bugs along that are stuck due to no reply from the 
reporter. If you don't reply with needed information that someone has 
requested then chances are your bug is going to get closed out. You have 
to keep on top of your bugs.

> 
> E.g. Russel commit many of my patches. Often, if patch have simple bugs,
> he silently fix this bugs and commit my patch with fix. If he doesn't
> accept patch, he always say _why_. And I hasn't any conflicts with him.
> Today he revert one of my changes, and I know _why_. And I know that he is
> right.
> 
> Why Corydon76 can't do his work without conflicting with other developers?
> 
> Why he close bugs without comment?
> 
> Why you say, that developing open, if my bugs can be closed without
> comment _why_?
> 
> 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 id 4825 is needed for any big installation. It live in bugtracker
> about a year, and was marked as [post 1.2]. Why it doesn't integrated?
> Many peoples use it. It save processor time, it helps with scalability.
> It fix some transcoding problems (because it transcode when _reading_
> frame, not _writing_, and this fix some races).
> 
> Why noone know "why this patch not commited?".

Russell is already trying to get the individual who wrote the patch for 
4825 to come onto the weekly developer conference call so we can talk 
about it and see if we can get it committed.

> 

-- 
Joshua Colp
Software Developer
Digium
P - 256-428-6066
C - 506-878-0147
jcolp at digium.com