[FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

Soft Works softworkz at hotmail.com
Sun Aug 15 00:34:39 EEST 2021



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Ronald S.
> Bultje
> Sent: Saturday, 14 August 2021 19:32
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with
> GitHub
> 


> I'm not sure I support it, I'd have to look closely. I understand the
> appeal of "dev env wrappers" for drive-by development and would encourage
> it for that, but I'm not sure I would use it myself unless adopted
> project-wide. Using a wrapper is always a somewhat suboptimal experience.


I would see it in a slightly different way: it would surely start as an 
experiment initially, but will quickly become something like a trial without
obligations. It allows to step with one foot into GitHub, experience how it 
works out and see how it will get used and adopted by developers, even though 
it might not work in all details like with a full migration.

But at the same time it avoids doing a full migration from one day to 
another. It doesn't require a consensus decision and it doesn't require
a vote or poll. It can just be opened up as an option to try out, but
it doesn't need to stay like this forever. The outcome will be 
open: it could either be abandoned at some point or it could end up
in a full migration.

Thinking it the other way round: assume there would be a decision to 
migrate to GitHub. How could such kind of migration be done smoothly?
There are a lot of (partially) good and interesting patches left on 
patchwork and a hard transition would cause a lot of trouble and 
dissatisfaction. 
Essentially - even with an upfront decision to move to GitHub, that
suggestion that I have made would still be a good way for making the
transition.

I just think that starting into something without needing to make
hard commitments might be a way that would cause less contradiction,
disagreement and dispute.

softworkz 















More information about the ffmpeg-devel mailing list