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

[Denis Smirnov]

On Sun, Apr 30, 2006 at 01:36:08PM -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.
JC> You'd have to ask Corydon why exactly he deleted them.

_deleting_ bugs anyway is very bad practice.

Closing is ok, if there is comment _why_ it is closed.

>>IRC is very time consuming.
JC> It's only time consuming if you stay on there all the time. If you are 
JC> simply trying to push your bug along, all you have to do is go into 
JC> #asterisk-bug or #asterisk-dev and say so. If a bug marshal is around, 
JC> or someone who can help you then it actually goes quite fast.
JC> I even specifically ask people in #asterisk and #asterisk-dev if they 
JC> have bugs open that I can do while I'm working on the bug tracker 
JC> because the real time element REALLY helps.

I think, that it is better to have ICQ/JID contacts in bugtracker user
info.

>>I have time for creating and reviewing asterisk patches.
JC> Great.
>>I have time for discussing them in bug tracker and maillists.
JC> Peachy.
>>I hasn't time for discussing them in any realtime communication method.
JC> Then you'll have to deal with the pace at which things go. We look at a 
JC> bug, paste a note then wait for a reply. Some time later when we then 
JC> have time to look at bugs again we then go back to the bug and see if 
JC> there is a reply and go from there. Due to the fact that everyone has 
JC> their own schedule and everyone is in their own timezone it can go quite 
JC> slow. The bigger the change the more discussion may go on as well.

bugtracker has mail notification ability. All bugs, that interesting to me
I subscribe.

>>I suuppport now greater then 50 patches localy. It's like fork today.
>>I can help team with 
JC> I'd like to note one thing here. Just because a person is a bug marshal 
JC> does not mean their own patches will go directly to SVN unless they have 
JC> absolute responsibility over it, and even then not always. A bug marshal 
JC> might not also have commit access to subversion. It takes time to earn 
JC> it, we have to get to know you.

Yes, it's right. If anyone have ability to commit patches without revieing
it by other peoples, than we can't have stable product.

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

It's right.

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

I ask many times -- how can developers get access to only own branch?
Without this I can't distribute my modifications without creating my own
distribution resources (public svn and web page).

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

And it's right.

>>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?
JC> Specific bug numbers help so I can look and see.

5971 -- ztdummy patch
6725 -- work for adding new API, that simplify codec negotiation changes
in future
6542 -- this patch doesn't matter, but can be useful for simplify code.
First patch that I upload was my development version with a bug (that was
reviewed by Corydon, and he point me that patch wrong), I upload new
patch, and... no one review it after.

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

4825 not in oej branch.

team/oej/codecnegotiation contains my work for 6725.

Please, see to patch in 6725. Simple changes like that doesn't need
_testing_, only small review for trivial bugs.

This patch internally contains two parts -- adding some functions to
channel.h, and trivial changes in code for using this functions.

JC> We have gotten help from the community. MANY people have given up time 
JC> to help in the past, and exactly what I said above has happened. Right 
JC> now there's only about 8 active bug marshals including myself, 3 being 
JC> Digium employees who, while it is part of their job, do have other 
JC> duties and projects. I thank everyone who has given up their time to 
JC> help with the bugs. If anyone does want to give a go at being a bug 
JC> 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;
JC> T.38 passthrough support is going to be going in before 1.4.

It's would not treated as architecture changes?

>> - OpenPBX use automake, but we doesn't;
JC> We just recently moved to using autoconf and are still ironing out the 
JC> bugs for that and learning it. Tackling too many build related things at 
JC> once will just slow everything down.

Adding autoconf/automak, and later menuconfig can be done faster, than
this way :(

>> - OpenPBX move some parts to libopenpbx, that simplify automatic finding
>>   for unresolved symbols, but we doesn't;
JC> They chose a different path. OpenPBX.org is a completely different 
JC> project then Asterisk, and they can go how they want. As always I wish 
JC> Nathan (the OpenPBX.org leader) the best of luck.

I think that asterisk project can get good ideas from OpenPBX.

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

keyword "saying why". Some my bugs was closed without saying why (it was
my conflict with Corydon). 

>>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?
JC> If you give me specific bug numbers I can try to find out.

6889. I don't like the way, that Casper choose for this, and I think that
this task can be done better. But Casper's version better than what we
have now.

>>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?".
JC> Russell is already trying to get the individual who wrote the patch for 
JC> 4825 to come onto the weekly developer conference call so we can talk 
JC> about it and see if we can get it committed.

I propose path to make it simpler.

This patch has many changes in about all asterisk modules, that is very
bad. Most of this changes contains work with chan->nativecodecs (that
changed from integer to structure by 4825). I propose incapsulate most
work with nativecodecs and read/write codecs in several inline functions.

After this changes (part of these changes in 6725 now) 4825 patch would be
more compact and easer to review, testing and finding bugs.

I know, that reviewing big patches is a BIG job. And I can write many
small patches for some functions, that can do job for bug marshals that
want to review my patches easier.

-- 
JID: ds at im.seiros.ru
ICQ: 58417635 (please, use jabber, if you can)

http://freesource.info/