August 13, 2021 9:30 PM, "Soft Works" <softwo...@hotmail.com> wrote:
>> -----Original Message----- >> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Lynne >> Sent: Saturday, 14 August 2021 03:08 >> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> >> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with >> GitHub >> >> The situation is far from perfect. In my opinion, mirroring will just >> result in such an incredible amount of noise on the ML, the ML >> will turn useless anyway, and due to needing to maintain both, >> one will fall out of favour with developers and will break, while >> limiting the integration for the other. > > I'm don't think it would create much noise, please see my reply to > Michael from 1.5h ago. > > There's no need to maintain both, because what happens on GitHub is > automated and the ML remains the core instrument. > > Should it turn out over time that activity would converge away > from the ML, then this would be a natural and democratic evolvement. > Then, it would be time to reconsider the organization, obviously. > >> I'd rather move to either a self-hosted Gitea or Gogs instance, >> or failing that, Github. IMO Gitea is pretty good and fast. As bad >> as that could be, it'll be better than what we have now or could have >> with Gitlab. > > These kinds of proposals have been talked down too often, that's > why I'm suggesting something with a more realistic chance for acceptance > and that won't hurt or affect anybody in his work if he doesn't want. > > Also, the stakes are much lower than with a full migration. > If it wouldn't work out well, it can be abandoned easily, while a > migration is usually a way of no return. Agreed. I mean if anything goes wrong, we just switch it off. There's nothing wrong with trying new things. Trying new things is how ffmpeg, nihav, and all great new software comes into existence. People need to be able to challenge things when they don't make sense in order to be competitive. By the people against softworkz appeal's logic they should never submit a patch to ffmpeg that includes something new or improved, since then there is a very small chance the commit isn't good and has to be reverted. > > softworkz > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
