Advertisement
Guest User

Untitled

a guest
Oct 4th, 2014
441
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. Libav - FFmpeg cooperation report
  2. =================================
  3. Editor: Stefano Sabatini (saste)
  4.  
  5. Dublin, Google headquarter, h14-16.
  6.  
  7. During VDD 2014 we had a shared session between libav and
  8. FFmpeg developers.
  9.  
  10. Participants attending from the FFmpeg side:
  11. Ben Stiller
  12. Nicolas George
  13. Reimar Doeffinger
  14. Stefano Sabatini
  15. Thilo Borgmann
  16.  
  17. Participants attending from the libav side:
  18. Alexandra Khirnova
  19. Anton Khirnov
  20. Attila Kinali
  21. Diego Biurrun
  22. Diego Pettenò
  23. Janne Granau
  24. Katerina Barone-Adesi
  25. Luca Barbato
  26. Martin Storsjo
  27. Vittorio Giovara
  28.  
  29. Other developers from both projects: Derek Buitenhuis
  30.  
  31. Several developers from other projects were also attending. The
  32. meeting was moderated by Lydia Pintscher from Videolan.
  33.  
  34. The object of the meeting was to discuss about the relationships
  35. between FFmpeg and libav.
  36.  
  37. From the FFmpeg side: since the fork, most interactions on
  38. mailing-list have been smooth, and no major flames happened. FFmpeg
  39. daily merges are perceived as painful from many developers, and they
  40. pose several API and ABI compatibility issues. Since FFmpeg tries to
  41. be backward-compatible, FFmpeg needs to add a compatibility layer
  42. which increases the overall complexity of the codebase. Also because
  43. of this the FFmpeg log history is twisted, and sometimes it is hard to
  44. track changes when merges are involved. This happens especially when a
  45. change is done first on the FFmpeg side, and the corresponding change
  46. is then done on libav and merged back on FFmpeg. Most FFmpeg
  47. developers though seem to agree that as long as Michael Niedermayer is
  48. able to keep up with the merging work, they are going to accept this
  49. situation.
  50.  
  51. On the libav side they ask that FFmpeg developers should restrain from
  52. insults and accusations towards libav. These accusations are casting
  53. bad light on the reputation of libav, especially as they can leak into
  54. real life and job relationships of the people involved with the
  55. project. Both FFmpeg and libav developers seem to agree that it would
  56. be useful for both projects to restrain from such accusations. On the
  57. other side most FFmpeg developers state that the level of accusations
  58. is supposedly very low or absent on the ffmpeg-devel mailing lists at
  59. the present time, and those accusations don't represent the official
  60. FFmpeg point of view but are only expression of personal positions.
  61.  
  62. In order to improve cooperation it is proposed to have a common
  63. mailing-list, which could be used to discuss API/ABI compatibility
  64. issues. This would be especially useful in case there is a developer
  65. on the other side with special knowledge on an area affected by a
  66. design proposal. Such mailing-list would foster cooperation and would
  67. allow to have a shared communication channel between the two
  68. projects. On the other hand the final choice about an interface design
  69. should not be enforced by a discussion happening on such mailing
  70. list. Some developers express a concern that the creation of such
  71. mailing-list couldn't work because of technical and social issues, and
  72. there is no final agreement about its creation.
  73.  
  74. Some FFmpeg developers propose to remove the ban on Michael on the
  75. libav development mailing-lists and on the IRC channel for a limited
  76. period (say, one month), and to organize a common IRC meeting between
  77. FFmpeg and libav developers moderated by a third party, which Michael
  78. Niedermayer could attend.
  79.  
  80. Finally, it is proposed to have a shared code of conduct or guidelines
  81. about the reciprocal relationships between the two projects, in order
  82. to improve cooperation and avoid reciprocal accusations. Such document
  83. should be edited by developers belonging to both projects.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement