[FFmpeg-devel] [PATCH] fix speex sample
Thu Apr 9 16:40:39 CEST 2009
On Thu, Apr 09, 2009 at 04:23:23PM +0200, Michael Niedermayer wrote:
> On Thu, Apr 09, 2009 at 03:59:43PM +0200, Reimar D?ffinger wrote:
> > On Thu, Apr 09, 2009 at 03:48:05PM +0200, Michael Niedermayer wrote:
> > > On Thu, Apr 09, 2009 at 09:33:26AM +0200, Diego Biurrun wrote:
> > > > On Wed, Apr 08, 2009 at 06:30:56PM -0700, Baptiste Coudurier wrote:
> > > [...]
> > > > Now while we're speaking of maintainer duties... I agree with your
> > > > position much more than I agree with Michael's, but I have to point out
> > >
> > > i think we should clarify once and for all what duties a maintainer has
> > > because people apply worse than double standards here
> > > and because this is a matter very critial to keeping the project functioning
> > >
> > > Theres no question that until recently a submited patch was reviewed,
> > > and when suggestions for improvments where provided, the patch author
> > > then had to fix the patch if he wanted it in svn or explain why the
> > > suggestions where undesireable.
> > >
> > > Do you propose that maintainers should fix patches themselfs now?
> > > Or do you propose that patches failing review should still be commited?
> > > Or do you propose not to review patches?
> > >
> > > If none of above, then where do you disagree with me?
> > I think the disagreement is about what should happen when the patch
> > submitter is not willing or able to fix the patch so it passes review.
> > In particular depending on whether the patch is supposed to address a
> > feature request/bug/crash bug/exploitable security issue (not that we
> > would always even agree on the categorization) resolving the issue IMHO
> > can be considered the maintainer's responsibility.
> ok, now i understand
> heres my current oppinion on who should be responsible
> incapable unwilling
> feature request noone submitter
> bug depends on time and complexity submitter
> crash bug mainteiner submitter
> exploitable security maintainer maintainer
> where do we disagree?
While this discussion is not really between me and you, I'll take the
chance to point out one issue I have with it:
depending on how literally you take "incapable" I probably don't fall
into the "incapable" column for almost anything.
Taking your table literally then means if I work on any of the H.264
bugs I most likely will _decrease_ the probability that the bug will be
fixed. That's not exactly a great motivation...
More information about the ffmpeg-devel