Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3535 bytes --]

On Thu, Apr 18, 2024 at 10:19:50AM +0200, Stefano Sabatini wrote:
> On date Wednesday 2024-04-17 19:21:39 -0700, Aidan wrote:
> > The best option is to figure stuff out.
> [...]
> > I use FFmpeg to download HLS streams from the internet or convert files
> > like probably most people do. FFmpeg is the ultimate way of doing this
> > because there is no better option.
> > 
> > But there are issues:
> [...]
> 
> > I submitted a patch for a TTML decoder because I thought it would be great.
> > It was completely ignored.
> 
> Please ping the patch or send a new one.
> 
> > If my patch was seriously bad, then fine. But seriously *no one cared*.
> 
> I think contribution management is a serious issue here.
> 
> What happens when you send a patch is that if you're lucky someone
> will be interested and put some effort to review and eventually get it
> pushed, which depending on several factors might require several
> interactions.
> 
> Sometimes contributors are side-tracked or frustrated and the review
> process is interrupted. Sometimes the reviewer won't reply, and the
> review also might be stuck (in this case you might want to ping the
> patch).
> 
> Sometimes there is no qualified or interested developer around, or
> maybe those ones are busy with other things (and it's easy to miss
> a patch, especially if you don't check emails since a few days and you
> got hundreds of backlog emails).
> 
> In general, this is done on a best effort basis (read as: most
> developers are volunteers and they might have job/families/stuff to
> tend to), there is no guarantee that a patch might be reviewed in a
> timely fashion.
> 
> This is not a problem specific with FFmpeg, but in general with most
> FLOSS projects.
> 
> Probably we should find ways to fund such activites, so that a
> developer can spend more time on reviewing work, but this comes with
> other risks/issues (since managing money is also complex of potential
> tensions in a mostly volunteering-based project).
> 
> It's also very difficult to track the sent patches, and that's why
> having a Pull-Request process a-la github has been proposed several
> times; we cannot switch to github for several reasons (licensing and
> affilitation issues with platform owner) and handling your own gitlab
> is costly and we lack volunteers at the moment.
> 
> We are using patchwork to mitigate the tracking issue:
> https://patchwork.ffmpeg.org/project/ffmpeg/list/
> 
> but that's not really providing an effective workflow.
> 
> Personally I find the status tracking confusing, e.g.:
> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=&submitter=&state=&q=TTML&archive=both&delegate=
> 
> I cannot easily figure out what was integrated and what not.

Would it help if i add a "patch" type to trac.ffmpeg.org ?

If patches are missed on patchwork or its confusing, then
patch authors could open such a ticket type=patch that points to the patchwork patch

as tickets have all the metadata from keywords over priority to component
and do also allow voting. It may help keeping track of patches and also
allow the community to express their preferance with voting.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".