[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