[FFmpeg-devel] [FFmpeg-commits] lavf: replace all uses of url_fskip with avio_seek

Reimar Döffinger Reimar.Doeffinger
Wed Mar 2 22:06:01 CET 2011


On Wed, Mar 02, 2011 at 08:23:06PM +0000, M?ns Rullg?rd wrote:
> Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
> 
> > On date Wednesday 2011-03-02 11:49:09 -0800, Baptiste Coudurier encoded:
> >> More than one developper is not happy with these changes, and I don't
> >> think it was a good change.
> >> Furthermore, it seems API changes are made way too faster before anybody
> >> can raise concerns.
> >
> > +1
> >
> > In general I would like to support this rule: all changes which affect
> > all the developers (policy, administration, API changes) need a
> > minimum amount of time before they can be applied since the first post
> > on the list (be this three days or one week), for giving all the
> > interested developers time to comment on them.
> >
> > This should be especially true for API changes, which can easily lead
> > to much damage to the project if not well thought and discussed with
> > the original authors of the API (when available). "Getting the f*cking
> > things done" is not a valid reason for spoiling the public API.
> >
> > This was true with the old "regime" and should still apply, this is
> > one of the areas where the one-post-one-review-one-commit rule is
> > completely nonsensical and unfair.
> 
> All of the recent API changes have been posted to the mailing list at
> least a week before they were committed.  If you don't like something,
> say so immediately instead of whining after it has been committed.

To be honest I don't manage to follow the amount of patches, thanks
to git the always come in one huge dump and if I don't have time I
end up just deleting them all.
I would be really useful if purely "cosmetical" renaming following a
rule discussed before "url_ -> avio_" wasn't dumped together with
more invasive stuff like removing a function that really changes
code quite a bit in many places.



More information about the ffmpeg-devel mailing list