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

[Michael Niedermayer <michael@niedermayer.cc>]

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

On Thu, Apr 18, 2024 at 11:15:48PM +0200, epirat07@gmail.com wrote:
> 
> 
> On 18 Apr 2024, at 22:15, Michael Niedermayer wrote:
> 
> > 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.
> 
> Just stating the obvious here but GitLab/Gitea/Forgejo or similar
> would solve this without needing absolutely weird workarounds
> like this…

a small change to trac is easy to do and easy to undo, if it helps,
iam not sure a switch to GitLab/Gitea/Forgejo will happen, or even if it is a good idea.

we lack people with time and interrest to review and apply patches
switching the tools will cost more time, and working
with these tools would also add burden (at least to me)

other projects also seem not to have switched if i look at LKML for
example

IMO, if we can keep the mailing list workflow and at the same time
provide people who prefer it a "in browser" way to interact with
patches, submit, approve and so on. That would be best.
It seems patchwork does not fully fill this role.
Can something be done to improve patchwork so it works better maybe ?

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.

[-- 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".