[FFmpeg-devel] [RFC] Creating ffmpeg-distmaint mailing list

Alexander Strasser eclipse7 at gmx.net
Sun Dec 29 21:15:02 CET 2013


On 2013-12-29 15:54 +0100, Michael Niedermayer wrote:
> On Sun, Dec 29, 2013 at 03:29:11PM +0100, Alexander Strasser wrote:
> > On 2013-12-29 14:42 +0100, Michael Niedermayer wrote:
> > > On Sun, Dec 29, 2013 at 01:17:36PM +0100, Alexander Strasser wrote:
> > > > Hi all,
> > > > 
> > > >   would it be good to have a distribution maintainers mailing list?
> > > > 
> > > >   I thought about it this way:
> > > > 
> > > >   Developers interested in fixing problems related to FFmpeg
> > > > distribution packages (at least I would) and FFmpeg packagers
> > > > would subscribe there.
> > > > 
> > > >   The packagers would report run-time or build problems related
> > > > to their packages. Fixes would be proposed and tested. Proposed
> > > > fixes that turned out to work well would be posted to ffmpeg-devel
> > > > and the ffmpeg-distmaint list would be notified again once the
> > > > patches hit the repository.
> > > > 
> > > >   My intents are (in *no* particular order)
> > > 
> > > >   - lessen the noise of distribution specific topics on ffmpeg-devel
> > > 
> > > trying to fix a non existent problem
> > > and worse, what are "distribution specific topics"? we have none
> > > so one cant even argue if they would not actually belong to
> > > ffmpeg-devel and should be seen by all developers
> > 
> >   That was not meant that way! I only meant if something affects
> > only a specific group that uses a particular package on a particular
> > OS then it may not be relevant to the development list as a whole.
> 
> something, specific group, particular package, particular OS
> do you have an example(s) ? Iam not sure we have the same things in
> mind about this ...

  I am thinking mostly about build related stuff that only happens
with a specific tool chain and/or ffmpeg configuration and/or specific
versions of dependencies.

> > One can argue though, that it can be ignored. I do not say anything
> > against that.
> >
> > > >   - getting notified earlier and more clearly about distribution problems
> > > 
> > > That assumes that all developers read another list and do it before
> > > they look at ffmpeg-devel, i would be quite surprised if that would
> > > happen
> > 
> >   First probably not all developers are interested in fixing that
> > stuff if they are not affected.
> 
> IMHO if theres a problem, lets say with the avi demuxer on debians
> ffmpeg package (possibly even caused by a debian specific patch)
> then the avi maintainer should be interrested in it equally as if its
> unrelated to debian. (he is the most qualified to at least say
> something about the issue)
> The alternative would be that maintainers dont care about their code
> working on some random distro, which i dont think really applies
> to any maintainer

  I do not disagree. In that case the report should be taken to
to the ffmpeg-devel list or a ticket should be opened depending
on the issue at hand. Also it should be considered that not all
parts of FFmpeg are actively maintained. So getting the attention
of few non-maintainer developers would still be helpful.

  In general I was mostly thinking about problems related to the
build and problems with other packages that depend on FFmpeg
or packages FFmpeg depends on.

> > Second on ffmpeg-devel it can easily
> > get lost if other discussions are going on. Third there might be
> > developers particularly interested in fixing problems that affect
> > the distribution of FFmpeg.
> > 
> > > >   - getting proposed patches tested more widely and quickly
> > > 
> > > how ?
> > 
> >   If packagers are subscribed I would assume they test the patches
> > and may even pre-release them in their packages if they judge the
> > fix to be good.
> > 
> > > besides patches belong to ffmpeg-devel
> > 
> >   To quote myself:
> > 
> > > > Proposed
> > > > fixes that turned out to work well would be posted to ffmpeg-devel
> > > > and the ffmpeg-distmaint list would be notified again once the
> > > > patches hit the repository.
> > 
> >   The workflow could also be defined this way:
> > 
> >   Post a patch to ffmpeg devel and post a link to that patch to
> > ffmpeg-distmaint. As far as I am concerned I would like it better
> > this way.
> 
> I think adding a CC: would be simpler and easier for later replies

  Sure, agreed.


  Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131229/ba69f010/attachment.asc>


More information about the ffmpeg-devel mailing list