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

[Alexander Strasser]

On 2013-12-29 14:43 +0000, Carl Eugen Hoyos wrote:
> Alexander Strasser <eclipse7 <at> gmx.net> writes:
> 
> >   - lessen the noise of distribution specific topics 
> > on ffmpeg-devel

  Any of the threads where people have some problem only
reproducible on particular OS with a particular version
of some external tool or library. Not all software distribution
ship exactly the same version of all software and not all
ffmpeg packages use identical configure options. Most often
this causes problems for the build. Most of the subscribers
of this list can probably build ffmpeg fine but for some it
doesn't work.

  I could try to dig up specific examples, but I will rather
advice you to just ignore this point for now. It is just a
side effect and I should probably have never mentioned it at
all. It is probably the most uninteresting of all points
I stated. Feel free to ignore.

> Could you point to examples of such emails?
> (I currently don't remember any.)
> 
> >   - getting notified earlier and more clearly about 
> > distribution problems
> 
> We currently have a user-mailing list and a bug tracker to 
> report issues and the last (two) packaging issues were fixed 
> within days.
> Are you sure we can improve?
> Why should people who do not want to report issues now do 
> that on a new mailing list?

  This seems to be a misunderstanding. I just want to have
improved bi-directional communication with ffmpeg packagers.
  
  One recent example  is the Freetype >=2.5.1 include breakage.
I didn't have any problem on my machines and I only got aware
because IIRC one of the persons creating FFmpeg static builds
(which I also consider distribution of FFmpeg) reported it on
the #ffmpeg-devel channel on Freenode and I happened to notice
it. Upon that I started to investigate the issue and posted
patches to ffmpeg-devel.

  Only way after that I realized the problem was reported
at least once about a week before. Had it been reported by
a packager on a separate list that is more low-traffic I
would have seen it before and worked on it before. Be sure
some of the packagers noticed it and reacted. They reacted
fast because it broke the build for them. What I want is
motivate packagers to report it whenever they have a problem
with their packages or add custom fixes to their package.

> >   - getting proposed patches tested more widely and quickly
> >   - getting fixes into the packages more widely and quickly
> 
> I don't understand that at all:
> We do not backport new features currently and assuming 
> that no additional manpower appears, I hope we do not 
> change this.
> Regression fixes are currently backported after they are 
> tested, what exactly do you want to change?

  If a package maintainer integrates the proposed fixes before
the discussion is finished it is useful to know about it. Or
if some packager has just added a patch to one of his packages.
OTOH it is also useful for package maintainers to know when
the stuff hits the repositories because they could drop custom
patches and rebuild if applicable. Then give feedback.

  If we get to know more about that it is better for us. ATM
the only way is to dig into all possible directions and find
out what was done to the individual packages and what was
discussed on the package specific communication channels.
This is extremely tedious and non-obvious at times too.

  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/cb3ea3ee/attachment.asc>