[FFmpeg-devel] [PATCH] rtsp - alternate protocol

[Michael Niedermayer]

On Wed, Jan 02, 2008 at 08:01:00PM +0100, Diego Biurrun wrote:
> On Sat, Dec 29, 2007 at 01:54:26AM +0100, Michael Niedermayer wrote:
> > On Sat, Dec 29, 2007 at 12:08:59AM +0100, Diego Biurrun wrote:
> > > On Fri, Dec 28, 2007 at 09:53:24PM +0100, Michael Niedermayer wrote:
> > > > On Fri, Dec 28, 2007 at 02:57:08PM -0500, Ronald S. Bultje wrote:
> > > > > 
> > > > > On Dec 28, 2007 2:42 PM, Aurelien Jacobs <aurel at gnuage.org> wrote:
> > > > > 
> > > > > > Either an #ifdef VERSION or a version bump. I personaly don't care.
> > > > > >
> > > > > 
> > > > > No need yet for a version bump, this stuff will go away by itself... New
> > > > > version of patch#3 attached.
> > > > 
> > > > patch ok
> > > 
> > > May I propose granting Ronald commit access?
> > 
> > iam against it!
> > 
> > > His patches may need some review rounds to be acceptable, but he has a
> > > history of following through and beating them into shape.  Also, there
> > 
> > he has a history of broken patches with alot of stuff never being approved
> > I see RDT and related code, 90% is not in svn
> > I see the url_split() patches, first cleanup (introduced a bug) and a
> >   purpoted fix which introduced more bugs but all this is one page of code
> > Then the resolve_host() stuff, it should have been replaced by standard
> > (POSIX) functions, this never happened
> > various http improvements like seeking support, these did reach svn and
> > work fine AFAIK
> > Then there are many small fixes all over the place, these are nice ...
> > 
> > I certainly dont want to loose ronald as contributor, but iam scared of
> > him having direct svn write access!
> 
> All of this would only be a problem if he committed non-approved patches.
> Avoiding this cannot be so hard, can it?

Noone was able to keep track of his patches ...
You assume he, himself succeeds keeping track of them :)


[...]
> 
> > > are a ton of his patches floating around and we have trouble getting all
> > > the approved ones applied.  I always get confused which ones can be
> > > committed and which ones cannot.  It would be a pity to have them slip
> > > through the cracks.  Moreover he seems to intend to continue working on
> > > FFmpeg in the future.
> > 
> > I also have my problems keeping track of his patches, i think if he would
> > keep 1 patch per thread and never create a new thread for the same patch.
> > Nor post another patch in the same thread, it would be much easier to
> > keep track of his patches.
> > Anyway its not a big issue for me to commit approved patches from him myself.
> 
> Then please commit them, because many patches are being dropped on the
> floor, which is very unfortunate.

Well i dont keep track of patches after approving them ...
Ill change that from now on (for ronalds patches), but i cant do anything for
past patches from him anymore.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080102/ecb69d04/attachment.pgp>