Re: [FFmpeg-devel] GitHub releases section is very old
On Sat, Oct 29, 2022 at 09:31:04PM +0200, Michael Niedermayer wrote: > On Sat, Oct 29, 2022 at 02:53:34PM +0200, Timo Rothenpieler wrote: > > On 29.10.2022 14:36, * Neustradamus * wrote: > > > Hello all, > > > > > > It is possible to remove all releases from GitHub? > > > Because at right, we can see and it is not good promotion for this active > > > project: > > > - https://github.com/FFmpeg/FFmpeg > > > > > > Releases 11 > > > FFmpeg 3.0 Release > > > Latest on 15 Feb 2016 > > > + 10 releases > > > - https://github.com/FFmpeg/FFmpeg/releases > > > > > > The important part is here: > > > - https://github.com/FFmpeg/FFmpeg/tags > > > > > > But it is possible to add all time in releases section, a new release > > > with changelog... > > > > We should probably delete all existing releases instead, so they don't cause > > confusion like this. > > Github is just a mirror, not any kind of official release channel. > > ill wait a few days so others can comment and then remove all releases from > github if thats the consensus at the time > > i was not aware we had a old subset of releases listed there Done, deleted all these (ancient) releases thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] GitHub releases section is very old
On 29.10.2022 14:36, * Neustradamus * wrote: Hello all, It is possible to remove all releases from GitHub? Because at right, we can see and it is not good promotion for this active project: - https://github.com/FFmpeg/FFmpeg Releases 11 FFmpeg 3.0 Release Latest on 15 Feb 2016 + 10 releases - https://github.com/FFmpeg/FFmpeg/releases The important part is here: - https://github.com/FFmpeg/FFmpeg/tags But it is possible to add all time in releases section, a new release with changelog... We should probably delete all existing releases instead, so they don't cause confusion like this. Github is just a mirror, not any kind of official release channel. ___ 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] GitHub releases section is very old
Hello all, It is possible to remove all releases from GitHub? Because at right, we can see and it is not good promotion for this active project: - https://github.com/FFmpeg/FFmpeg Releases 11 FFmpeg 3.0 Release Latest on 15 Feb 2016 + 10 releases - https://github.com/FFmpeg/FFmpeg/releases The important part is here: - https://github.com/FFmpeg/FFmpeg/tags But it is possible to add all time in releases section, a new release with changelog... Thanks in advance. Regards, Neustradamus ___ 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".
Re: [FFmpeg-devel] GitHub Integration
> -Original Message- > From: ffmpeg-devel On Behalf Of Soft Works > Sent: Sunday, January 2, 2022 7:16 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] GitHub Integration > > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of Lynne > > Sent: Sunday, January 2, 2022 3:04 PM > > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] GitHub Integration > > > > 2 Jan 2022, 04:28 by softwo...@hotmail.com: > > > > > > > > > > >> -Original Message- > > >> From: ffmpeg-devel On Behalf Of Soft > > Works > > >> Sent: Tuesday, December 28, 2021 10:58 PM > > >> To: FFmpeg development discussions and patches > > >> Subject: Re: [FFmpeg-devel] GitHub Integration > > >> > > >> One component of the GitHub "Bridge" is a mirror of the ffmpeg-devel > > >> mailing list as a Git repository which provides a web interfaces, can be > > >> cloned via Git and can also be accessed from Atom feed readers. > > >> This allows to follow the mailing list without subscribing. The web UI > > >> might not be everybody's taste, though. It's the same that is used for > > >> Linux kernel mailing lists (https://lore.kernel.org/git/). > > >> I had to set this up as it's a requirement for the GitHub "Bridge", but > > >> maybe it's useful for someone in other ways: > > >> > > >> https://master.gitmailbox.com/ffmpegdev/ > > >> > > > > > > > > > I have just ACTIVATED patch submission via GitHub and submitted the first > > > patch through this method. > > > > > > Pull requests can be created in this repository (for now): > > > > > > https://github.com/ffstaging/FFmpeg > > > > > > > > > What's not nice is that the submitted e-mail shows "ffmpegagent" as > sender > > > and patchwork is showing it under that name as well. > > > > > > We'll need to see how this can be improved. > > > > > > > I don't like it. Can't it use the author's name for emails? > > I don't like this either. I'll try to find a way. This is fixed now. See my patch from today: [FFmpeg-devel] libavutil/tests/md5: Avoid warnings Also, it appears correctly attributed on Patchwork: (no longer as ffmpegagent) https://patchwork.ffmpeg.org/project/ffmpeg/patch/pull.20.ffstaging.ffmpeg.1642727870274.ffmpegag...@gmail.com/ Regards, 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".
Re: [FFmpeg-devel] GitHub Integration
> -Original Message- > From: ffmpeg-devel On Behalf Of Lynne > Sent: Sunday, January 2, 2022 3:04 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] GitHub Integration > > 2 Jan 2022, 04:28 by softwo...@hotmail.com: > > > > > > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of Soft > Works > >> Sent: Tuesday, December 28, 2021 10:58 PM > >> To: FFmpeg development discussions and patches > >> Subject: Re: [FFmpeg-devel] GitHub Integration > >> > >> One component of the GitHub "Bridge" is a mirror of the ffmpeg-devel > >> mailing list as a Git repository which provides a web interfaces, can be > >> cloned via Git and can also be accessed from Atom feed readers. > >> This allows to follow the mailing list without subscribing. The web UI > >> might not be everybody's taste, though. It's the same that is used for > >> Linux kernel mailing lists (https://lore.kernel.org/git/). > >> I had to set this up as it's a requirement for the GitHub "Bridge", but > >> maybe it's useful for someone in other ways: > >> > >> https://master.gitmailbox.com/ffmpegdev/ > >> > > > > > > I have just ACTIVATED patch submission via GitHub and submitted the first > > patch through this method. > > > > Pull requests can be created in this repository (for now): > > > > https://github.com/ffstaging/FFmpeg > > > > > > What's not nice is that the submitted e-mail shows "ffmpegagent" as sender > > and patchwork is showing it under that name as well. > > > > We'll need to see how this can be improved. > > > > I don't like it. Can't it use the author's name for emails? I don't like this either. I'll try to find a way. sw ___ 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".
Re: [FFmpeg-devel] GitHub Integration
2 Jan 2022, 04:28 by softwo...@hotmail.com: > > >> -Original Message- >> From: ffmpeg-devel On Behalf Of Soft Works >> Sent: Tuesday, December 28, 2021 10:58 PM >> To: FFmpeg development discussions and patches >> Subject: Re: [FFmpeg-devel] GitHub Integration >> >> One component of the GitHub "Bridge" is a mirror of the ffmpeg-devel >> mailing list as a Git repository which provides a web interfaces, can be >> cloned via Git and can also be accessed from Atom feed readers. >> This allows to follow the mailing list without subscribing. The web UI >> might not be everybody's taste, though. It's the same that is used for >> Linux kernel mailing lists (https://lore.kernel.org/git/). >> I had to set this up as it's a requirement for the GitHub "Bridge", but >> maybe it's useful for someone in other ways: >> >> https://master.gitmailbox.com/ffmpegdev/ >> > > > I have just ACTIVATED patch submission via GitHub and submitted the first > patch through this method. > > Pull requests can be created in this repository (for now): > > https://github.com/ffstaging/FFmpeg > > > What's not nice is that the submitted e-mail shows "ffmpegagent" as sender > and patchwork is showing it under that name as well. > > We'll need to see how this can be improved. > I don't like it. Can't it use the author's name for emails? ___ 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".
Re: [FFmpeg-devel] GitHub Integration
> -Original Message- > From: ffmpeg-devel On Behalf Of Soft Works > Sent: Tuesday, December 28, 2021 10:58 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] GitHub Integration > > One component of the GitHub "Bridge" is a mirror of the ffmpeg-devel > mailing list as a Git repository which provides a web interfaces, can be > cloned via Git and can also be accessed from Atom feed readers. > This allows to follow the mailing list without subscribing. The web UI > might not be everybody's taste, though. It's the same that is used for > Linux kernel mailing lists (https://lore.kernel.org/git/). > I had to set this up as it's a requirement for the GitHub "Bridge", but > maybe it's useful for someone in other ways: > > https://master.gitmailbox.com/ffmpegdev/ I have just ACTIVATED patch submission via GitHub and submitted the first patch through this method. Pull requests can be created in this repository (for now): https://github.com/ffstaging/FFmpeg What's not nice is that the submitted e-mail shows "ffmpegagent" as sender and patchwork is showing it under that name as well. We'll need to see how this can be improved. Happy new year! 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".
Re: [FFmpeg-devel] GitHub Integration
Quoting Ronald S. Bultje (2021-12-26 22:37:54) > Hi, > > On Sun, Dec 26, 2021 at 3:21 PM Soft Works wrote: > > > I'm not sure. My interpretation of Lance' and Steven's comments would > > be that they'd prefer to stick to the ML. > > > > No, it's not strictly related to that - they want something that is CLI > accessible. Gitlab has this here: https://glab.readthedocs.io/en/latest/ > and github has this here: https://github.com/cli/cli - the next question is Last I checked, there were two decently developed CLI tools for gitlab and neither supported enough functionality to fully cover the usual workflow. Github's official CLI tools are a lot more advanced, but then github has other problems. And for the record - I am not especially in love with our current ML workflow, but any change that requires me to use a web browser for common tasks is a MASSIVE step back IMO. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] GitHub Integration
> -Original Message- > From: ffmpeg-devel On Behalf Of Niklas Haas > Sent: Tuesday, December 28, 2021 10:22 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] GitHub Integration > > On Tue, 28 Dec 2021 00:59:58 +1000 Zane van Iperen > wrote: > > > > > > On 27/12/21 11:41, lance.lmw...@gmail.com wrote: > > > On Sun, Dec 26, 2021 at 04:37:54PM -0500, Ronald S. Bultje wrote: > > >> Hi, > > >> > > >> On Sun, Dec 26, 2021 at 3:21 PM Soft Works > wrote: > > >> > > >>> I'm not sure. My interpretation of Lance' and Steven's comments would > > >>> be that they'd prefer to stick to the ML. > > >>> > > >> > > >> No, it's not strictly related to that - they want something that is CLI > > >> accessible. Gitlab has this here: https://glab.readthedocs.io/en/latest/ > > >> and github has this here: https://github.com/cli/cli - the next question > is > > >> whether the gitlab/hub hosts are blocked by a firewall (no idea) and/or > > >> whether the instances are self-hosted (github: no, gitlab-videolan: > yes). > > > > > > Yes, self-hosted is more preferable, I recall github has blocked > devleopers > > > in some country by US trade controls. Who knows what's the rules will be > > > changed someday as it's controlled by company. > > > > > > > Something that doesn't require another account would be nice, which is why > > I like mailing lists. > > I don't understand, isn't this an argument in favor of GitHub? Most > mailing lists (including, notably, FFmpeg's) require registration in > order to submit messages, which is one of the reasons I hate them. It's > not just that registration is annoying in general, it's also that > registration to a mailing list is *more* annoying and cumbersome than > creating an account on any post-90s website. > > Conversely on GitHub, everybody already has an account, so the overhead > for first-time contribution is *actually* zero. And on every other > self-hosted GitLab instance I've come across, I could cross-authenticate > with some other account I already have. One component of the GitHub "Bridge" is a mirror of the ffmpeg-devel mailing list as a Git repository which provides a web interfaces, can be cloned via Git and can also be accessed from Atom feed readers. This allows to follow the mailing list without subscribing. The web UI might not be everybody's taste, though. It's the same that is used for Linux kernel mailing lists (https://lore.kernel.org/git/). I had to set this up as it's a requirement for the GitHub "Bridge", but maybe it's useful for someone in other ways: https://master.gitmailbox.com/ffmpegdev/ Regards, 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".
Re: [FFmpeg-devel] GitHub Integration
On Tue, 28 Dec 2021 00:59:58 +1000 Zane van Iperen wrote: > > > On 27/12/21 11:41, lance.lmw...@gmail.com wrote: > > On Sun, Dec 26, 2021 at 04:37:54PM -0500, Ronald S. Bultje wrote: > >> Hi, > >> > >> On Sun, Dec 26, 2021 at 3:21 PM Soft Works wrote: > >> > >>> I'm not sure. My interpretation of Lance' and Steven's comments would > >>> be that they'd prefer to stick to the ML. > >>> > >> > >> No, it's not strictly related to that - they want something that is CLI > >> accessible. Gitlab has this here: https://glab.readthedocs.io/en/latest/ > >> and github has this here: https://github.com/cli/cli - the next question is > >> whether the gitlab/hub hosts are blocked by a firewall (no idea) and/or > >> whether the instances are self-hosted (github: no, gitlab-videolan: yes). > > > > Yes, self-hosted is more preferable, I recall github has blocked devleopers > > in some country by US trade controls. Who knows what's the rules will be > > changed someday as it's controlled by company. > > > > Something that doesn't require another account would be nice, which is why > I like mailing lists. I don't understand, isn't this an argument in favor of GitHub? Most mailing lists (including, notably, FFmpeg's) require registration in order to submit messages, which is one of the reasons I hate them. It's not just that registration is annoying in general, it's also that registration to a mailing list is *more* annoying and cumbersome than creating an account on any post-90s website. Conversely on GitHub, everybody already has an account, so the overhead for first-time contribution is *actually* zero. And on every other self-hosted GitLab instance I've come across, I could cross-authenticate with some other account I already have. ___ 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".
Re: [FFmpeg-devel] GitHub Integration
Not advocating for github (per this thread it's out of scope), but I think using a self-hosted gitlab with an option to auth using github account would help in reducing the "account overhead" at least for those who use github. пн, 27 дек. 2021 г., 17:59 Zane van Iperen : > > > On 27/12/21 11:41, lance.lmw...@gmail.com wrote: > > On Sun, Dec 26, 2021 at 04:37:54PM -0500, Ronald S. Bultje wrote: > >> Hi, > >> > >> On Sun, Dec 26, 2021 at 3:21 PM Soft Works > wrote: > >> > >>> I'm not sure. My interpretation of Lance' and Steven's comments would > >>> be that they'd prefer to stick to the ML. > >>> > >> > >> No, it's not strictly related to that - they want something that is CLI > >> accessible. Gitlab has this here: > https://glab.readthedocs.io/en/latest/ > >> and github has this here: https://github.com/cli/cli - the next > question is > >> whether the gitlab/hub hosts are blocked by a firewall (no idea) and/or > >> whether the instances are self-hosted (github: no, gitlab-videolan: > yes). > > > > Yes, self-hosted is more preferable, I recall github has blocked > devleopers > > in some country by US trade controls. Who knows what's the rules will be > > changed someday as it's controlled by company. > > > > Something that doesn't require another account would be nice, which is why > I like mailing lists. Although in this case a move to GitHub wouldn't > affect me > personally (I use it a lot) - if I didn't, I would seriously reconsider if > the mental > overhead of yet another account (and all the baggage that comes with it - > passwords, MFA, > data breaches, etc.) is worth contributing to the project. > > Ideally, something self-hosted like Gitea or GitLab with a federated > approach (i.e. ForgeFed) > would be fantastic for a case such as this. I'm not sure about GitLab, but > I know Gitea is > working towards this. > > > ___ > 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".
Re: [FFmpeg-devel] GitHub Integration
On 27/12/21 11:41, lance.lmw...@gmail.com wrote: On Sun, Dec 26, 2021 at 04:37:54PM -0500, Ronald S. Bultje wrote: Hi, On Sun, Dec 26, 2021 at 3:21 PM Soft Works wrote: I'm not sure. My interpretation of Lance' and Steven's comments would be that they'd prefer to stick to the ML. No, it's not strictly related to that - they want something that is CLI accessible. Gitlab has this here: https://glab.readthedocs.io/en/latest/ and github has this here: https://github.com/cli/cli - the next question is whether the gitlab/hub hosts are blocked by a firewall (no idea) and/or whether the instances are self-hosted (github: no, gitlab-videolan: yes). Yes, self-hosted is more preferable, I recall github has blocked devleopers in some country by US trade controls. Who knows what's the rules will be changed someday as it's controlled by company. Something that doesn't require another account would be nice, which is why I like mailing lists. Although in this case a move to GitHub wouldn't affect me personally (I use it a lot) - if I didn't, I would seriously reconsider if the mental overhead of yet another account (and all the baggage that comes with it - passwords, MFA, data breaches, etc.) is worth contributing to the project. Ideally, something self-hosted like Gitea or GitLab with a federated approach (i.e. ForgeFed) would be fantastic for a case such as this. I'm not sure about GitLab, but I know Gitea is working towards this. ___ 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".
Re: [FFmpeg-devel] GitHub Integration
On Sun, Dec 26, 2021 at 04:37:54PM -0500, Ronald S. Bultje wrote: > Hi, > > On Sun, Dec 26, 2021 at 3:21 PM Soft Works wrote: > > > I'm not sure. My interpretation of Lance' and Steven's comments would > > be that they'd prefer to stick to the ML. > > > > No, it's not strictly related to that - they want something that is CLI > accessible. Gitlab has this here: https://glab.readthedocs.io/en/latest/ > and github has this here: https://github.com/cli/cli - the next question is > whether the gitlab/hub hosts are blocked by a firewall (no idea) and/or > whether the instances are self-hosted (github: no, gitlab-videolan: yes). Yes, self-hosted is more preferable, I recall github has blocked devleopers in some country by US trade controls. Who knows what's the rules will be changed someday as it's controlled by company. > > Ronald > ___ > 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". -- Thanks, Limin Wang ___ 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".
Re: [FFmpeg-devel] GitHub Integration
> -Original Message- > From: ffmpeg-devel On Behalf Of Ronald S. > Bultje > Sent: Sunday, December 26, 2021 10:38 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] GitHub Integration > > Hi, > > On Sun, Dec 26, 2021 at 3:21 PM Soft Works wrote: > > > I'm not sure. My interpretation of Lance' and Steven's comments would > > be that they'd prefer to stick to the ML. > > > > No, it's not strictly related to that - they want something that is CLI > accessible. Gitlab has this here: https://glab.readthedocs.io/en/latest/ > and github has this here: https://github.com/cli/cli - the next question is > whether the gitlab/hub hosts are blocked by a firewall (no idea) and/or > whether the instances are self-hosted (github: no, gitlab-videolan: yes). Agreed. For the submission part, there are CLI options in both cases. Also true for both cases: the discussion part would change to WWW. But I'm probably the very last one here to advocate staying with the ML. Even though I'd prefer GitHub, I would welcome a move to GitLab as well, and when something like GitGitGadget would have existed for GitLab instead of GitHub, then I would have adopted that instead. Looking back at the discussion in August, where I made these suggestions, a lot of developers had responded, indicating their satisfaction with the ML approach (some even defending it strongly). Just very few indicated support for a move to either GitHub or GitLab. Off-list, I've seen some who were claiming that a majority would exist, favoring a move to GitLab. That would be great, but I'm not seeing it. Where is that majority and why do so few of them speak up, then? After reading the ML for several years, and from what I've learned about the group interaction dynamics, my assessment is, that a migration away from the ML is unlikely to happen in a short-term future. Those who don't want to move are just on standby, waiting for the next attempt to be made in order to turn it down once again, and those who would like to move, are sufficiently satisfied by the thought alone that a move to GitLab would happen "soon". Most likely, by the end of 2022, the situation will just be the same. On the other side, the "GitHub Gateway/Integration" with the ffmpeg-codebot is available right now and able to bridge the gap between ML and more modern and integrated development workflows. It's not meant to replace, avoid or compete with an actual migration, and when a migration would happen e.g. to GitLab, it will be still useful to have a bot on GitHub that either mirrors PRs from GitHub or just auto-closes them with an appropriate message. Somebody said on IRC that the GH integration might only delay a real migration away from the ML. But I'm seeing it somewhat differently: this might rather serve as an indication for which approach will be preferred by the majority, maybe even accelerating a final migration. Kind regards, 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".
Re: [FFmpeg-devel] GitHub Integration
Hi, On Sun, Dec 26, 2021 at 3:21 PM Soft Works wrote: > I'm not sure. My interpretation of Lance' and Steven's comments would > be that they'd prefer to stick to the ML. > No, it's not strictly related to that - they want something that is CLI accessible. Gitlab has this here: https://glab.readthedocs.io/en/latest/ and github has this here: https://github.com/cli/cli - the next question is whether the gitlab/hub hosts are blocked by a firewall (no idea) and/or whether the instances are self-hosted (github: no, gitlab-videolan: yes). Ronald ___ 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".
Re: [FFmpeg-devel] GitHub Integration
> -Original Message- > From: ffmpeg-devel On Behalf Of Lynne > Sent: Sunday, December 26, 2021 5:49 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] GitHub Integration > > 26 Dec 2021, 02:03 by l...@chinaffmpeg.org: > > > > > > >> 在 2021年12月26日，上午8:55，lance.lmw...@gmail.com 写道： > >> > >> On Sat, Dec 25, 2021 at 05:15:19PM +, Soft Works wrote: > >> > >>> > >>> > >>>> -Original Message- > >>>> From: ffmpeg-devel On Behalf Of Lynne > >>>> Sent: Saturday, December 25, 2021 5:50 PM > >>>> To: FFmpeg development discussions and patches > >>>> Subject: Re: [FFmpeg-devel] GitHub Integration > >>>> > >>>> 23 Dec 2021, 00:24 by softwo...@hotmail.com: > >>>> > >>>>> Hi, > >>>>> > >>>>> holidays are approaching and I got a little present for all of you > >>>>> even though it won’t be something for everybody. > >>>>> > >>>>> A while ago I had committed to prepare a test setup for integrating > >>>>> GitHub in a similar way as the Git developers are doing. > >>>>> > >>>>> For those who missed it or don’t remember the outcome: > >>>>> https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html > >>>>> https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html > >>>>> > >>>>> Before someone’s temperature might start rising, I want to repeat > >>>>> some important corner points: > >>>>> > >>>>> - it's not a migration nor the start of a migration > >>>>> - nothing changes, it doesn't affect anybody's way of working > >>>>> it doesn't replace anything > >>>>> - it's an add-on that one could use or not > >>>>> > >>>>> Basic functionality is that it allows to submit patches to the ML > >>>>> through GitHub pull requests. > >>>>> > >>>>> Right now must features are working, but e-mails are not sent to > >>>>> the ML yet, just to one's own e-mail address. > >>>>> > >>>>> > >>>>> I don't want to post the repository location publicly at this time, > >>>>> but for anybody who would be interested in taking a look at this, > >>>>> please send me an e-mail or PM me on IRC. > >>>>> > >>>> > >>>> I'd rather we move away from ML development altogether. > >>>> There's general consensus already, and of course one or > >>>> two who'd rather not. > >>>> > >>> > >>> I'd prefer that as well, but in back in summer there were quite a number > >>> of developers (> 2) indicating that they are fine with the > >>> ML approach, so I'm not really sure about whether and when this > >>> will happen eventually. > >>> > >>> This GitHub-PR-Bridge is not meant to be an alternative or replacement > >>> for an eventual full migration to another platform. > >>> > >>> It's just an interim solution until a migration will eventually happen > >>> (probably like in the 2030ies.. ;-) > >>> > >> > >> My point: > >> 1, In China network environment, when accessing Github, the network will > be > >> blocked or very slow. > >> 2, For gmail is blocked, so I prefer to use cli, remote ssh to a cloud > host, > >> use mutt/vim for ML email, and scp, and git cli tools are professional to > do > >> everything for the patchset send, push etc. Yes, I can use socket5 to > forward, > >> but I like cli instead of web for I prefer to use keyboard instead of > mouse. > >> > > > > +1 > > > > We'd never move to Github, that much's for sure. Videolan already > hosts a Gitlab instance, and I doubt the great firewall would have an > issue with that. I'm not sure. My interpretation of Lance' and Steven's comments would be that they'd prefer to stick to the ML. sw ___ 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".
Re: [FFmpeg-devel] GitHub Integration
26 Dec 2021, 02:03 by l...@chinaffmpeg.org: > > >> 在 2021年12月26日，上午8:55，lance.lmw...@gmail.com 写道： >> >> On Sat, Dec 25, 2021 at 05:15:19PM +, Soft Works wrote: >> >>> >>> >>>> -Original Message- >>>> From: ffmpeg-devel On Behalf Of Lynne >>>> Sent: Saturday, December 25, 2021 5:50 PM >>>> To: FFmpeg development discussions and patches >>>> Subject: Re: [FFmpeg-devel] GitHub Integration >>>> >>>> 23 Dec 2021, 00:24 by softwo...@hotmail.com: >>>> >>>>> Hi, >>>>> >>>>> holidays are approaching and I got a little present for all of you >>>>> even though it won’t be something for everybody. >>>>> >>>>> A while ago I had committed to prepare a test setup for integrating >>>>> GitHub in a similar way as the Git developers are doing. >>>>> >>>>> For those who missed it or don’t remember the outcome: >>>>> https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html >>>>> https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html >>>>> >>>>> Before someone’s temperature might start rising, I want to repeat >>>>> some important corner points: >>>>> >>>>> - it's not a migration nor the start of a migration >>>>> - nothing changes, it doesn't affect anybody's way of working >>>>> it doesn't replace anything >>>>> - it's an add-on that one could use or not >>>>> >>>>> Basic functionality is that it allows to submit patches to the ML >>>>> through GitHub pull requests. >>>>> >>>>> Right now must features are working, but e-mails are not sent to >>>>> the ML yet, just to one's own e-mail address. >>>>> >>>>> >>>>> I don't want to post the repository location publicly at this time, >>>>> but for anybody who would be interested in taking a look at this, >>>>> please send me an e-mail or PM me on IRC. >>>>> >>>> >>>> I'd rather we move away from ML development altogether. >>>> There's general consensus already, and of course one or >>>> two who'd rather not. >>>> >>> >>> I'd prefer that as well, but in back in summer there were quite a number >>> of developers (> 2) indicating that they are fine with the >>> ML approach, so I'm not really sure about whether and when this >>> will happen eventually. >>> >>> This GitHub-PR-Bridge is not meant to be an alternative or replacement >>> for an eventual full migration to another platform. >>> >>> It's just an interim solution until a migration will eventually happen >>> (probably like in the 2030ies.. ;-) >>> >> >> My point: >> 1, In China network environment, when accessing Github, the network will be >> blocked or very slow. >> 2, For gmail is blocked, so I prefer to use cli, remote ssh to a cloud host, >> use mutt/vim for ML email, and scp, and git cli tools are professional to do >> everything for the patchset send, push etc. Yes, I can use socket5 to >> forward, >> but I like cli instead of web for I prefer to use keyboard instead of mouse. >> > > +1 > We'd never move to Github, that much's for sure. Videolan already hosts a Gitlab instance, and I doubt the great firewall would have an issue with that. ___ 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".
Re: [FFmpeg-devel] GitHub Integration
> 在 2021年12月26日，上午8:55，lance.lmw...@gmail.com 写道： > > On Sat, Dec 25, 2021 at 05:15:19PM +, Soft Works wrote: >> >> >>> -Original Message- >>> From: ffmpeg-devel On Behalf Of Lynne >>> Sent: Saturday, December 25, 2021 5:50 PM >>> To: FFmpeg development discussions and patches >>> Subject: Re: [FFmpeg-devel] GitHub Integration >>> >>> 23 Dec 2021, 00:24 by softwo...@hotmail.com: >>> >>>> Hi, >>>> >>>> holidays are approaching and I got a little present for all of you >>>> even though it won’t be something for everybody. >>>> >>>> A while ago I had committed to prepare a test setup for integrating >>>> GitHub in a similar way as the Git developers are doing. >>>> >>>> For those who missed it or don’t remember the outcome: >>>> https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html >>>> https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html >>>> >>>> Before someone’s temperature might start rising, I want to repeat >>>> some important corner points: >>>> >>>> - it's not a migration nor the start of a migration >>>> - nothing changes, it doesn't affect anybody's way of working >>>> it doesn't replace anything >>>> - it's an add-on that one could use or not >>>> >>>> Basic functionality is that it allows to submit patches to the ML >>>> through GitHub pull requests. >>>> >>>> Right now must features are working, but e-mails are not sent to >>>> the ML yet, just to one's own e-mail address. >>>> >>>> >>>> I don't want to post the repository location publicly at this time, >>>> but for anybody who would be interested in taking a look at this, >>>> please send me an e-mail or PM me on IRC. >>>> >>> >>> I'd rather we move away from ML development altogether. >>> There's general consensus already, and of course one or >>> two who'd rather not. >> >> I'd prefer that as well, but in back in summer there were quite a number >> of developers (> 2) indicating that they are fine with the >> ML approach, so I'm not really sure about whether and when this >> will happen eventually. >> >> This GitHub-PR-Bridge is not meant to be an alternative or replacement >> for an eventual full migration to another platform. >> >> It's just an interim solution until a migration will eventually happen >> (probably like in the 2030ies.. ;-) > > My point: > 1, In China network environment, when accessing Github, the network will be > blocked or very slow. > 2, For gmail is blocked, so I prefer to use cli, remote ssh to a cloud host, > use mutt/vim for ML email, and scp, and git cli tools are professional to do > everything for the patchset send, push etc. Yes, I can use socket5 to forward, > but I like cli instead of web for I prefer to use keyboard instead of mouse. +1 > >> >> 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". > > -- > Thanks, > Limin Wang > ___ > 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".
Re: [FFmpeg-devel] GitHub Integration
On Sat, Dec 25, 2021 at 05:15:19PM +, Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of Lynne > > Sent: Saturday, December 25, 2021 5:50 PM > > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] GitHub Integration > > > > 23 Dec 2021, 00:24 by softwo...@hotmail.com: > > > > > Hi, > > > > > > holidays are approaching and I got a little present for all of you > > > even though it won’t be something for everybody. > > > > > > A while ago I had committed to prepare a test setup for integrating > > > GitHub in a similar way as the Git developers are doing. > > > > > > For those who missed it or don’t remember the outcome: > > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html > > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html > > > > > > Before someone’s temperature might start rising, I want to repeat > > > some important corner points: > > > > > > - it's not a migration nor the start of a migration > > > - nothing changes, it doesn't affect anybody's way of working > > > it doesn't replace anything > > > - it's an add-on that one could use or not > > > > > > Basic functionality is that it allows to submit patches to the ML > > > through GitHub pull requests. > > > > > > Right now must features are working, but e-mails are not sent to > > > the ML yet, just to one's own e-mail address. > > > > > > > > > I don't want to post the repository location publicly at this time, > > > but for anybody who would be interested in taking a look at this, > > > please send me an e-mail or PM me on IRC. > > > > > > > I'd rather we move away from ML development altogether. > > There's general consensus already, and of course one or > > two who'd rather not. > > I'd prefer that as well, but in back in summer there were quite a number > of developers (> 2) indicating that they are fine with the > ML approach, so I'm not really sure about whether and when this > will happen eventually. > > This GitHub-PR-Bridge is not meant to be an alternative or replacement > for an eventual full migration to another platform. > > It's just an interim solution until a migration will eventually happen > (probably like in the 2030ies.. ;-) My point: 1, In China network environment, when accessing Github, the network will be blocked or very slow. 2, For gmail is blocked, so I prefer to use cli, remote ssh to a cloud host, use mutt/vim for ML email, and scp, and git cli tools are professional to do everything for the patchset send, push etc. Yes, I can use socket5 to forward, but I like cli instead of web for I prefer to use keyboard instead of mouse. > > 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". -- Thanks, Limin Wang ___ 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".
Re: [FFmpeg-devel] GitHub Integration
> -Original Message- > From: ffmpeg-devel On Behalf Of Lynne > Sent: Saturday, December 25, 2021 5:50 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] GitHub Integration > > 23 Dec 2021, 00:24 by softwo...@hotmail.com: > > > Hi, > > > > holidays are approaching and I got a little present for all of you > > even though it won’t be something for everybody. > > > > A while ago I had committed to prepare a test setup for integrating > > GitHub in a similar way as the Git developers are doing. > > > > For those who missed it or don’t remember the outcome: > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html > > > > Before someone’s temperature might start rising, I want to repeat > > some important corner points: > > > > - it's not a migration nor the start of a migration > > - nothing changes, it doesn't affect anybody's way of working > > it doesn't replace anything > > - it's an add-on that one could use or not > > > > Basic functionality is that it allows to submit patches to the ML > > through GitHub pull requests. > > > > Right now must features are working, but e-mails are not sent to > > the ML yet, just to one's own e-mail address. > > > > > > I don't want to post the repository location publicly at this time, > > but for anybody who would be interested in taking a look at this, > > please send me an e-mail or PM me on IRC. > > > > I'd rather we move away from ML development altogether. > There's general consensus already, and of course one or > two who'd rather not. I'd prefer that as well, but in back in summer there were quite a number of developers (> 2) indicating that they are fine with the ML approach, so I'm not really sure about whether and when this will happen eventually. This GitHub-PR-Bridge is not meant to be an alternative or replacement for an eventual full migration to another platform. It's just an interim solution until a migration will eventually happen (probably like in the 2030ies.. ;-) 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".
Re: [FFmpeg-devel] GitHub Integration
23 Dec 2021, 00:24 by softwo...@hotmail.com: > Hi, > > holidays are approaching and I got a little present for all of you > even though it won’t be something for everybody. > > A while ago I had committed to prepare a test setup for integrating > GitHub in a similar way as the Git developers are doing. > > For those who missed it or don’t remember the outcome: > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html > > Before someone’s temperature might start rising, I want to repeat > some important corner points: > > - it's not a migration nor the start of a migration > - nothing changes, it doesn't affect anybody's way of working > it doesn't replace anything > - it's an add-on that one could use or not > > Basic functionality is that it allows to submit patches to the ML > through GitHub pull requests. > > Right now must features are working, but e-mails are not sent to > the ML yet, just to one's own e-mail address. > > > I don't want to post the repository location publicly at this time, > but for anybody who would be interested in taking a look at this, > please send me an e-mail or PM me on IRC. > I'd rather we move away from ML development altogether. There's general consensus already, and of course one or two who'd rather not. ___ 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".
Re: [FFmpeg-devel] GitHub Integration
> -Original Message- > From: ffmpeg-devel On Behalf Of Michael > Niedermayer > Sent: Saturday, December 25, 2021 12:12 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] GitHub Integration > > On Sat, Dec 25, 2021 at 12:31:56PM +0300, Vasily wrote: > > Hi, > > > > First off, a great idea bridging that gap! But I agree that the topic is > > misleading, maybe rename to smth like "github bridge for PR creation" to be > > really explicit? > > > > > Second one, why first-comers aren't allowed to submit without pre-approval? > > Some pull requests on github where "spam" iam not sure how exactly these > happen > maybe someoen pressing the wrong buttons, or someone not understanding github > pull requests for random branches like for example our release branch onto > master or something like this has been submitted IIRC. On github its a matter > of closing the request, but if that resulted in a post to the ML it could > produce hundreads of mails. So some sort of pre-approval or some other sort > of double check that a submissing is intended is required Yea, exactly. Hadn’t seen your reply, just gave the same answer :-) 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".
Re: [FFmpeg-devel] GitHub Integration
> -Original Message- > From: ffmpeg-devel On Behalf Of Vasily > Sent: Saturday, December 25, 2021 10:32 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] GitHub Integration > > Hi, > > First off, a great idea bridging that gap! But I agree that the topic is > misleading, maybe rename to smth like "github bridge for PR creation" to be > really explicit? Agreed. Once I start another conversation for the next step, I'll try to choose a better subject. > Second one, why first-comers aren't allowed to submit without pre-approval? > (context: I haven't made my contributions to ffmpeg yet, though posted a > single patch which stalled at review because of lack of my time). Ah yes, that's a good question. When we had discussed this back in August, there were concerns that this might cause a certain amount of hoax-, nonsense- or low-quality patches to hit the mailing list. And that's what it's about. The "pre-approval" for first-posters is not meant to be a review. Reviews are done on the mailing list, just like usual. This is intended to a rather low bar and all that an "already allowed" user is expected to do is to take a very quick look at the submitted PR, whether it _appears_ to be a reasonable contribution. > And last point - if comments from github aren't re-posted to the list, > maybe the boy should remove them or edit by removing the message and > telling the commenter to use the ML? Messages from the ML which are shown on GitHub are always including a "Reply-To" link with instruction about how to reply. > Anyway, good idea! Drop me a note, then I'll send you the link where you can try it out. Regards, 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".
Re: [FFmpeg-devel] GitHub Integration
On Sat, Dec 25, 2021 at 12:31:56PM +0300, Vasily wrote: > Hi, > > First off, a great idea bridging that gap! But I agree that the topic is > misleading, maybe rename to smth like "github bridge for PR creation" to be > really explicit? > > Second one, why first-comers aren't allowed to submit without pre-approval? Some pull requests on github where "spam" iam not sure how exactly these happen maybe someoen pressing the wrong buttons, or someone not understanding github pull requests for random branches like for example our release branch onto master or something like this has been submitted IIRC. On github its a matter of closing the request, but if that resulted in a post to the ML it could produce hundreads of mails. So some sort of pre-approval or some other sort of double check that a submissing is intended is required thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] GitHub Integration
Typo correction: "the bot should remove", not "the boy" (oh my mobile tapping...) сб, 25 дек. 2021 г., 12:31 Vasily : > Hi, > > First off, a great idea bridging that gap! But I agree that the topic is > misleading, maybe rename to smth like "github bridge for PR creation" to be > really explicit? > > Second one, why first-comers aren't allowed to submit without > pre-approval? (context: I haven't made my contributions to ffmpeg yet, > though posted a single patch which stalled at review because of lack of my > time). > > And last point - if comments from github aren't re-posted to the list, > maybe the boy should remove them or edit by removing the message and > telling the commenter to use the ML? > > Anyway, good idea! > > Thanks, Vasily > > > пт, 24 дек. 2021 г., 1:30 Soft Works : > >> >> >> > -Original Message- >> > From: Soft Works >> > Sent: Thursday, December 23, 2021 12:25 AM >> > To: FFmpeg development discussions and patches > > >> > Subject: GitHub Integration >> > >> > Hi, >> > >> > holidays are approaching and I got a little present for all of you >> > even though it won’t be something for everybody. >> > >> > A while ago I had committed to prepare a test setup for integrating >> > GitHub in a similar way as the Git developers are doing. >> > >> > For those who missed it or don’t remember the outcome: >> > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html >> > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html >> >> I think I should add a quick summary on this subject for all those >> who haven't followed the discussion in August. >> >> The Git project (https://git-scm.com/) has a similar problem like >> ffmpeg: There are a number of long-time core developers that are >> strictly rejecting to move away from the ML based approach. >> That's how GitGitGadget came to life, intending to bridge that gap. >> >> Adopting that approach for ffmpeg has a number of advantages: >> >> - we can skip the "learning process", i.e. finding out what works >> in practical use and what doesn't >> - what has found acceptance at their project - given the similar >> profile of the developers involved - will likely be acceptable >> for ffmpeg as well (roughly at least) >> - the part that I like most is: even without explicit acceptance - >> this approach doesn't leave much room for objection, because it >> doesn't impose any changes or drawback to the way people are >> working with the ML >> >> >> Here's a rough overview about how it's working: >> >> - User submits a PR to the GitHub repo >> >> - When it's a user's first PR, the ffmpeg-codebot will >> respond with a very comprehensive message (as PR comment), >> explaining the procedures and providing an overview about >> contributing to ffmpeg with links to the individual topics >> on the ffmpeg website regarding contributing. >> >> - The message further explains that first-time users are not >> allowed to submit immediately, and that a user needs to >> find and contact another developer who is allowed to make >> submissions and ask that developer to vouch for him. >> >> - Every developer who has been allowed to submit can vouch >> for a first-time submitter >> It is done by adding a comment containing "/allow" to the >> first-time user's PR >> >> - Upon submitting the PR (no matter whether first-time or existing >> submitter), the code bot will likely have posted some other >> comments, indicating which changes need to be made to the >> patchset before it can be submitted. >> >> - The user addresses those changes and then force-pushes the branch >> to GitHub, the code bot re-runs all checks and when all >> requirements are met (and only then), the user will be >> able to submit. >> This is done by posting a comment to the PR containing "/submit" >> The code bot will automatically create the patch e-mails and >> send them to the ML. >> (it's also possible to post "/preview" to get the same e-mails >> created but only sent to a user's own e-mail account) >> >> - Comments that are made on the ML are mirrored back to the GitHub >> PR as comments. The other way is not yet implemented, so at this >> point, a user will need to respond through the ML (that's >> clearly indicated). >> I hope this will be implemented soon, it's not easy though to >> do it in a nice way without repeating all those quoted lines >> each time >> >> What's really like is the way how you submit new versions of >> a patchset: >> >> - After having applied the changes locally, you just (force-) push >> the branch again, and post another comment with "/submit" >> Everything is done automatically then: the patchset version >> number is increased, new patches are generated and sent to the ML >> >> Kind regards, >> softworkz >> >> >> >> >> >> >> >> >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/list
Re: [FFmpeg-devel] GitHub Integration
Hi, First off, a great idea bridging that gap! But I agree that the topic is misleading, maybe rename to smth like "github bridge for PR creation" to be really explicit? Second one, why first-comers aren't allowed to submit without pre-approval? (context: I haven't made my contributions to ffmpeg yet, though posted a single patch which stalled at review because of lack of my time). And last point - if comments from github aren't re-posted to the list, maybe the boy should remove them or edit by removing the message and telling the commenter to use the ML? Anyway, good idea! Thanks, Vasily пт, 24 дек. 2021 г., 1:30 Soft Works : > > > > -Original Message- > > From: Soft Works > > Sent: Thursday, December 23, 2021 12:25 AM > > To: FFmpeg development discussions and patches > > Subject: GitHub Integration > > > > Hi, > > > > holidays are approaching and I got a little present for all of you > > even though it won’t be something for everybody. > > > > A while ago I had committed to prepare a test setup for integrating > > GitHub in a similar way as the Git developers are doing. > > > > For those who missed it or don’t remember the outcome: > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html > > I think I should add a quick summary on this subject for all those > who haven't followed the discussion in August. > > The Git project (https://git-scm.com/) has a similar problem like > ffmpeg: There are a number of long-time core developers that are > strictly rejecting to move away from the ML based approach. > That's how GitGitGadget came to life, intending to bridge that gap. > > Adopting that approach for ffmpeg has a number of advantages: > > - we can skip the "learning process", i.e. finding out what works > in practical use and what doesn't > - what has found acceptance at their project - given the similar > profile of the developers involved - will likely be acceptable > for ffmpeg as well (roughly at least) > - the part that I like most is: even without explicit acceptance - > this approach doesn't leave much room for objection, because it > doesn't impose any changes or drawback to the way people are > working with the ML > > > Here's a rough overview about how it's working: > > - User submits a PR to the GitHub repo > > - When it's a user's first PR, the ffmpeg-codebot will > respond with a very comprehensive message (as PR comment), > explaining the procedures and providing an overview about > contributing to ffmpeg with links to the individual topics > on the ffmpeg website regarding contributing. > > - The message further explains that first-time users are not > allowed to submit immediately, and that a user needs to > find and contact another developer who is allowed to make > submissions and ask that developer to vouch for him. > > - Every developer who has been allowed to submit can vouch > for a first-time submitter > It is done by adding a comment containing "/allow" to the > first-time user's PR > > - Upon submitting the PR (no matter whether first-time or existing > submitter), the code bot will likely have posted some other > comments, indicating which changes need to be made to the > patchset before it can be submitted. > > - The user addresses those changes and then force-pushes the branch > to GitHub, the code bot re-runs all checks and when all > requirements are met (and only then), the user will be > able to submit. > This is done by posting a comment to the PR containing "/submit" > The code bot will automatically create the patch e-mails and > send them to the ML. > (it's also possible to post "/preview" to get the same e-mails > created but only sent to a user's own e-mail account) > > - Comments that are made on the ML are mirrored back to the GitHub > PR as comments. The other way is not yet implemented, so at this > point, a user will need to respond through the ML (that's > clearly indicated). > I hope this will be implemented soon, it's not easy though to > do it in a nice way without repeating all those quoted lines > each time > > What's really like is the way how you submit new versions of > a patchset: > > - After having applied the changes locally, you just (force-) push > the branch again, and post another comment with "/submit" > Everything is done automatically then: the patchset version > number is increased, new patches are generated and sent to the ML > > Kind regards, > 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/ffm
Re: [FFmpeg-devel] GitHub Integration
> -Original Message- > From: Soft Works > Sent: Thursday, December 23, 2021 12:25 AM > To: FFmpeg development discussions and patches > Subject: GitHub Integration > > Hi, > > holidays are approaching and I got a little present for all of you > even though it won’t be something for everybody. > > A while ago I had committed to prepare a test setup for integrating > GitHub in a similar way as the Git developers are doing. > > For those who missed it or don’t remember the outcome: > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html I think I should add a quick summary on this subject for all those who haven't followed the discussion in August. The Git project (https://git-scm.com/) has a similar problem like ffmpeg: There are a number of long-time core developers that are strictly rejecting to move away from the ML based approach. That's how GitGitGadget came to life, intending to bridge that gap. Adopting that approach for ffmpeg has a number of advantages: - we can skip the "learning process", i.e. finding out what works in practical use and what doesn't - what has found acceptance at their project - given the similar profile of the developers involved - will likely be acceptable for ffmpeg as well (roughly at least) - the part that I like most is: even without explicit acceptance - this approach doesn't leave much room for objection, because it doesn't impose any changes or drawback to the way people are working with the ML Here's a rough overview about how it's working: - User submits a PR to the GitHub repo - When it's a user's first PR, the ffmpeg-codebot will respond with a very comprehensive message (as PR comment), explaining the procedures and providing an overview about contributing to ffmpeg with links to the individual topics on the ffmpeg website regarding contributing. - The message further explains that first-time users are not allowed to submit immediately, and that a user needs to find and contact another developer who is allowed to make submissions and ask that developer to vouch for him. - Every developer who has been allowed to submit can vouch for a first-time submitter It is done by adding a comment containing "/allow" to the first-time user's PR - Upon submitting the PR (no matter whether first-time or existing submitter), the code bot will likely have posted some other comments, indicating which changes need to be made to the patchset before it can be submitted. - The user addresses those changes and then force-pushes the branch to GitHub, the code bot re-runs all checks and when all requirements are met (and only then), the user will be able to submit. This is done by posting a comment to the PR containing "/submit" The code bot will automatically create the patch e-mails and send them to the ML. (it's also possible to post "/preview" to get the same e-mails created but only sent to a user's own e-mail account) - Comments that are made on the ML are mirrored back to the GitHub PR as comments. The other way is not yet implemented, so at this point, a user will need to respond through the ML (that's clearly indicated). I hope this will be implemented soon, it's not easy though to do it in a nice way without repeating all those quoted lines each time What's really like is the way how you submit new versions of a patchset: - After having applied the changes locally, you just (force-) push the branch again, and post another comment with "/submit" Everything is done automatically then: the patchset version number is increased, new patches are generated and sent to the ML Kind regards, 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".
Re: [FFmpeg-devel] GitHub Integration
> -Original Message- > From: ffmpeg-devel On Behalf Of Timo > Rothenpieler > Sent: Thursday, December 23, 2021 3:17 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] GitHub Integration > > On 23.12.2021 14:59, Tomas Härdin wrote: > > This sounds like something that will cause problems in the long run. > > Github will inevitably be brought into the project's workflow. People > > will start submitting tickets on Github rather than our trac. And so > > on. > > issues are disabled on Github. > Otherwise, they'd be used for that constantly already. The test setup is located in a separate repository right now. (anybody just drop me a note and I'll send the link) What's also important to mention is that the pull request conversations are looped through the mailing list. There is no side-stepping or splitting of conversations: nobody on the ML will miss anything important, except all the pre-submission validation. There are various checks performed before a user can even submit, and we can also make it mandatory that compilation does not error and FATE tests are being passed, so patchsets won't even hit the ML otherwise. Kind regards, 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".
Re: [FFmpeg-devel] GitHub Integration
> -Original Message- > From: ffmpeg-devel On Behalf Of Tomas > Härdin > Sent: Thursday, December 23, 2021 3:00 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] GitHub Integration > > ons 2021-12-22 klockan 23:24 + skrev Soft Works: > > Hi, > > > > holidays are approaching and I got a little present for all of you > > even though it won’t be something for everybody. > > > > A while ago I had committed to prepare a test setup for integrating > > GitHub in a similar way as the Git developers are doing. > > > > For those who missed it or don’t remember the outcome: > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html > > > > Before someone’s temperature might start rising, I want to repeat > > some important corner points: > > > > - it's not a migration nor the start of a migration > > - nothing changes, it doesn't affect anybody's way of working > > it doesn't replace anything > > - it's an add-on that one could use or not > > > > Basic functionality is that it allows to submit patches to the ML > > through GitHub pull requests. > > This sounds like something that will cause problems in the long run. > Github will inevitably be brought into the project's workflow. People > will start submitting tickets on Github rather than our trac. And so > on. Issues are disabled and hidden. sw ___ 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".
Re: [FFmpeg-devel] GitHub Integration
On 23.12.2021 14:59, Tomas Härdin wrote: This sounds like something that will cause problems in the long run. Github will inevitably be brought into the project's workflow. People will start submitting tickets on Github rather than our trac. And so on. issues are disabled on Github. Otherwise, they'd be used for that constantly already. smime.p7s Description: S/MIME Cryptographic Signature ___ 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".
Re: [FFmpeg-devel] GitHub Integration
ons 2021-12-22 klockan 23:24 + skrev Soft Works: > Hi, > > holidays are approaching and I got a little present for all of you > even though it won’t be something for everybody. > > A while ago I had committed to prepare a test setup for integrating > GitHub in a similar way as the Git developers are doing. > > For those who missed it or don’t remember the outcome: > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html > > Before someone’s temperature might start rising, I want to repeat > some important corner points: > > - it's not a migration nor the start of a migration > - nothing changes, it doesn't affect anybody's way of working > it doesn't replace anything > - it's an add-on that one could use or not > > Basic functionality is that it allows to submit patches to the ML > through GitHub pull requests. This sounds like something that will cause problems in the long run. Github will inevitably be brought into the project's workflow. People will start submitting tickets on Github rather than our trac. And so on. /Tomas ___ 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".
Re: [FFmpeg-devel] GitHub Integration
> -Original Message- > From: ffmpeg-devel On Behalf Of Paul B > Mahol > Sent: Thursday, December 23, 2021 8:36 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] GitHub Integration > > Topic name is deeply misleading. What would you say? Bridge, Interface, Gateway, Connection, Connector..? I don't know. The interactive component that "talks" to you for getting things ready to submit goes by the name "FFmpeg CodeBot" sw ___ 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".
Re: [FFmpeg-devel] GitHub Integration
Topic name is deeply misleading. ___ 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] GitHub Integration
Hi, holidays are approaching and I got a little present for all of you even though it won’t be something for everybody. A while ago I had committed to prepare a test setup for integrating GitHub in a similar way as the Git developers are doing. For those who missed it or don’t remember the outcome: https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html Before someone’s temperature might start rising, I want to repeat some important corner points: - it's not a migration nor the start of a migration - nothing changes, it doesn't affect anybody's way of working it doesn't replace anything - it's an add-on that one could use or not Basic functionality is that it allows to submit patches to the ML through GitHub pull requests. Right now must features are working, but e-mails are not sent to the ML yet, just to one's own e-mail address. I don't want to post the repository location publicly at this time, but for anybody who would be interested in taking a look at this, please send me an e-mail or PM me on IRC. Kind regards, 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".
Re: [FFmpeg-devel] github
fre 2018-04-27 klockan 00:50 +0200 skrev wm4: > On Thu, 26 Apr 2018 14:41:55 +0200 > Daniel Oberhoff wrote: > > > > On 26. Apr 2018, at 14:40, wm4 wrote: > > > > > > On Thu, 26 Apr 2018 14:12:14 +0200 > > > Hendrik Leppkes mailto:h.lepp...@gmail.com> > > > > wrote: > > > > > > > On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff > > > > wrote: > > > > > > > > > > > Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff > > > > > o...@googlemail.com>: > > > > > > > > > > > > > > > > > > > Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff > > > > > > rh...@googlemail.com>: > > > > > > > > > > > > > > > > > > > > > > Am 26.04.2018 um 13:52 schrieb Nicolas George > > > > > > > sup.org>: > > > > > > > > > > > > > > > > Daniel Oberhoff (2018-04-26): > > > > > > > > > I was wondering if there is any chance to move > > > > > > > > > development to github? > > > > > > > > > I.e. not just mirror, but as primary development > > > > > > > > > repo, with issues and > > > > > > > > > pull requests? Would make collaboration a *lot* > > > > > > > > > easier (think of > > > > > > > > > submitting a pr instead of having to > > > > > > > > > generate/format/split patches). > > > > > > > > > > > > > > > > If development involves working in a web browser a lot, > > > > > > > > count me out. > > > > > > > > Can you point me to the command-line > > > > > > > > > > > > > > https://hub.github.com/hub.1.html > > > > > > > > > > > > But you can’t really do reviews that way, so the criticism > > > > > > stands. > > > > > > > > > > BTW, is there any kind of issue tracking? > > > > > > > > https://trac.ffmpeg.org/ > > > > > > To be fair, I'd prefer the github issue tracker over TRAC any > > > day. > > > Still has the other problems I mentioned. > > > > gitlab? > > > > That would mostly get rid of the centralization argument. But I've > heard bad things from someone who wanted to setup a private instance > of > it. Apparently it has a large number of dependencies, is extremely > hard > to deploy (unless you use their docker container), and it's SLOW. > > In fact even gitlab.com seems to have severe performance problems > occasionally. Another problem with gitlab is its inability to work without js. Things like hamburger menus getting in the way, READMEs not displaying and so on. Just look at https://gitlab.com/explore with js and third party domains disabled /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
On Thu, Apr 26, 2018, at 2:50 PM, wm4 wrote: > > That would mostly get rid of the centralization argument. But I've > heard bad things from someone who wanted to setup a private instance of > it. Apparently it has a large number of dependencies, is extremely hard > to deploy (unless you use their docker container), and it's SLOW. > > In fact even gitlab.com seems to have severe performance problems > occasionally. It would be interesting to hear VideoLAN's experience with their GitLab instance. https://code.videolan.org/ They're still using trac too I believe so I guess it's not fully adequate. There is also Phabricator, but I've never used it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
On Thu, 26 Apr 2018 14:41:55 +0200 Daniel Oberhoff wrote: > > On 26. Apr 2018, at 14:40, wm4 wrote: > > > > On Thu, 26 Apr 2018 14:12:14 +0200 > > Hendrik Leppkes mailto:h.lepp...@gmail.com>> wrote: > > > >> On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff > >> wrote: > >>> > Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff > : > > > > Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff > > : > > > > > >> Am 26.04.2018 um 13:52 schrieb Nicolas George : > >> > >> Daniel Oberhoff (2018-04-26): > >>> I was wondering if there is any chance to move development to github? > >>> I.e. not just mirror, but as primary development repo, with issues and > >>> pull requests? Would make collaboration a *lot* easier (think of > >>> submitting a pr instead of having to generate/format/split patches). > >> > >> If development involves working in a web browser a lot, count me out. > >> Can you point me to the command-line > > > > https://hub.github.com/hub.1.html > > But you can’t really do reviews that way, so the criticism stands. > >>> > >>> BTW, is there any kind of issue tracking? > >> > >> https://trac.ffmpeg.org/ > > > > To be fair, I'd prefer the github issue tracker over TRAC any day. > > Still has the other problems I mentioned. > > gitlab? > That would mostly get rid of the centralization argument. But I've heard bad things from someone who wanted to setup a private instance of it. Apparently it has a large number of dependencies, is extremely hard to deploy (unless you use their docker container), and it's SLOW. In fact even gitlab.com seems to have severe performance problems occasionally. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
tor 2018-04-26 klockan 13:15 +0200 skrev Daniel Oberhoff: > Hello, > > I was wondering if there is any chance to move development to github? > I.e. not just mirror, but as primary development repo, with issues > and pull requests? Would make collaboration a *lot* easier (think of > submitting a pr instead of having to generate/format/split patches). There is no reason to move to a siren server like github when we already have working infrastructure. There's also the issue of not being able to take one's data and go. While the code can be moved, tickets cannot. PR quality is an issue too, as others have noted. GitLab might be nice however, but we'd need a way to import all trac tickets, with ticket numbers and URLs intact. But I don't think we'd gain much from that. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
On Thu, 26 Apr 2018 08:59:03 -0800 Lou Logan wrote: > On Thu, Apr 26, 2018, at 4:40 AM, wm4 wrote: > > > > To be fair, I'd prefer the github issue tracker over TRAC any day. > > At least it isn't Bugzilla. What are some of the problems with trac? Is there > a self-hostable bug tracker you prefer? It's very slow, and the GUI sucks. It has no usable search functions, and trying to get a ticket list is a horror. Also its UI is cluttered bugzilla-style, although not as horribly as bugzilla. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
On Thu, Apr 26, 2018, at 4:40 AM, wm4 wrote: > > To be fair, I'd prefer the github issue tracker over TRAC any day. At least it isn't Bugzilla. What are some of the problems with trac? Is there a self-hostable bug tracker you prefer? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
On Thu, 26 Apr 2018, 14:42 Daniel Oberhoff, wrote: > > > On 26. Apr 2018, at 14:40, wm4 wrote: > > > > On Thu, 26 Apr 2018 14:12:14 +0200 > > Hendrik Leppkes mailto:h.lepp...@gmail.com>> > wrote: > > > >> On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff > >> wrote: > >>> > Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff < > danieloberh...@googlemail.com>: > > > > Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff < > danieloberh...@googlemail.com>: > > > > > >> Am 26.04.2018 um 13:52 schrieb Nicolas George : > >> > >> Daniel Oberhoff (2018-04-26): > >>> I was wondering if there is any chance to move development to > github? > >>> I.e. not just mirror, but as primary development repo, with issues > and > >>> pull requests? Would make collaboration a *lot* easier (think of > >>> submitting a pr instead of having to generate/format/split > patches). > >> > >> If development involves working in a web browser a lot, count me > out. > >> Can you point me to the command-line > > > > https://hub.github.com/hub.1.html > > But you can’t really do reviews that way, so the criticism stands. > >>> > >>> BTW, is there any kind of issue tracking? > >> > >> https://trac.ffmpeg.org/ > > > > To be fair, I'd prefer the github issue tracker over TRAC any day. > > Still has the other problems I mentioned. > > gitlab? > Mkvtoolnix moved to gitlab from GitHub due to some of the concerns raised in this thread. The comments in this blog by Moritz Bunkus are worth reading. https://www.bunkus.org/blog/2017/12/mkvtoolnix-moves-to-gitlab/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
> On 26. Apr 2018, at 14:40, wm4 wrote: > > On Thu, 26 Apr 2018 14:12:14 +0200 > Hendrik Leppkes mailto:h.lepp...@gmail.com>> wrote: > >> On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff >> wrote: >>> Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff : > Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff > : > > >> Am 26.04.2018 um 13:52 schrieb Nicolas George : >> >> Daniel Oberhoff (2018-04-26): >>> I was wondering if there is any chance to move development to github? >>> I.e. not just mirror, but as primary development repo, with issues and >>> pull requests? Would make collaboration a *lot* easier (think of >>> submitting a pr instead of having to generate/format/split patches). >> >> If development involves working in a web browser a lot, count me out. >> Can you point me to the command-line > > https://hub.github.com/hub.1.html But you can’t really do reviews that way, so the criticism stands. >>> >>> BTW, is there any kind of issue tracking? >> >> https://trac.ffmpeg.org/ > > To be fair, I'd prefer the github issue tracker over TRAC any day. > Still has the other problems I mentioned. gitlab? signature.asc Description: Message signed with OpenPGP ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
On Thu, 26 Apr 2018 14:12:14 +0200 Hendrik Leppkes wrote: > On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff > wrote: > > > >> Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff > >> : > >> > >> > >>> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff > >>> : > >>> > >>> > Am 26.04.2018 um 13:52 schrieb Nicolas George : > > Daniel Oberhoff (2018-04-26): > > I was wondering if there is any chance to move development to github? > > I.e. not just mirror, but as primary development repo, with issues and > > pull requests? Would make collaboration a *lot* easier (think of > > submitting a pr instead of having to generate/format/split patches). > > If development involves working in a web browser a lot, count me out. > Can you point me to the command-line > >>> > >>> https://hub.github.com/hub.1.html > >> > >> But you can’t really do reviews that way, so the criticism stands. > > > > BTW, is there any kind of issue tracking? > > https://trac.ffmpeg.org/ To be fair, I'd prefer the github issue tracker over TRAC any day. Still has the other problems I mentioned. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
>> >> BTW, is there any kind of issue tracking? > > https://trac.ffmpeg.org/ oh, 1784 issues... signature.asc Description: Message signed with OpenPGP ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
On 2018-04-26 13:15, Daniel Oberhoff wrote: > I was wondering if there is any chance to move development to github? > I.e. not just mirror, but as primary development repo, with issues and > pull requests? Would make collaboration a *lot* easier (think of > submitting a pr instead of having to generate/format/split patches). Github is proprietary software. It encourages non-linear history which we already suffer from due to merges from Libav. It encourages bad commits and really bad commit messages. It requires a web browser and a web browser with javascript. If I wasn't clear, I would be against it. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff wrote: > >> Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff >> : >> >> >>> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff >>> : >>> >>> Am 26.04.2018 um 13:52 schrieb Nicolas George : Daniel Oberhoff (2018-04-26): > I was wondering if there is any chance to move development to github? > I.e. not just mirror, but as primary development repo, with issues and > pull requests? Would make collaboration a *lot* easier (think of > submitting a pr instead of having to generate/format/split patches). If development involves working in a web browser a lot, count me out. Can you point me to the command-line >>> >>> https://hub.github.com/hub.1.html >> >> But you can’t really do reviews that way, so the criticism stands. > > BTW, is there any kind of issue tracking? https://trac.ffmpeg.org/ - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
> Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff > : > > >> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff >> : >> >> >>> Am 26.04.2018 um 13:52 schrieb Nicolas George : >>> >>> Daniel Oberhoff (2018-04-26): I was wondering if there is any chance to move development to github? I.e. not just mirror, but as primary development repo, with issues and pull requests? Would make collaboration a *lot* easier (think of submitting a pr instead of having to generate/format/split patches). >>> >>> If development involves working in a web browser a lot, count me out. >>> Can you point me to the command-line >> >> https://hub.github.com/hub.1.html > > But you can’t really do reviews that way, so the criticism stands. BTW, is there any kind of issue tracking? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff > : > > >> Am 26.04.2018 um 13:52 schrieb Nicolas George : >> >> Daniel Oberhoff (2018-04-26): >>> I was wondering if there is any chance to move development to github? >>> I.e. not just mirror, but as primary development repo, with issues and >>> pull requests? Would make collaboration a *lot* easier (think of >>> submitting a pr instead of having to generate/format/split patches). >> >> If development involves working in a web browser a lot, count me out. >> Can you point me to the command-line > > https://hub.github.com/hub.1.html But you can’t really do reviews that way, so the criticism stands. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
Daniel Oberhoff (2018-04-26): > https://hub.github.com/hub.1.html Thanks. So, how do I read a comment in an issue without a browser? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
> Am 26.04.2018 um 13:52 schrieb Nicolas George : > > Daniel Oberhoff (2018-04-26): >> I was wondering if there is any chance to move development to github? >> I.e. not just mirror, but as primary development repo, with issues and >> pull requests? Would make collaboration a *lot* easier (think of >> submitting a pr instead of having to generate/format/split patches). > > If development involves working in a web browser a lot, count me out. > Can you point me to the command-line https://hub.github.com/hub.1.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
Daniel Oberhoff (2018-04-26): > I was wondering if there is any chance to move development to github? > I.e. not just mirror, but as primary development repo, with issues and > pull requests? Would make collaboration a *lot* easier (think of > submitting a pr instead of having to generate/format/split patches). If development involves working in a web browser a lot, count me out. Can you point me to the command-line interface to GitHub? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
On Thu, 26 Apr 2018 13:15:52 +0200 Daniel Oberhoff wrote: > Hello, > > I was wondering if there is any chance to move development to github? I.e. > not just mirror, but as primary development repo, with issues and pull > requests? Would make collaboration a *lot* easier (think of submitting a pr > instead of having to generate/format/split patches). Using git send-email is actually simpler than sending a github PR. Also github will delete or hide review comments once you force-push the PR branch (after you've fixed things that were pointed out). It would force everyone to use a complex and slow web interface. There's no easily searchable archive of past reviews, like the mailing list archive. There is also this aspect that github is an US company and a single point of failure. If there's a problem we couldn't just move the server somewhere else. Github would also be in control who's allowed to register and make posts, which seems rather strange to me. Another small aspect is that we've seen really awful low quality contributions on our github repository, even though we explicitly state that we don't do PRs. There have been 130 pull requests ever since we made a dummy PR that we ignore pull requests. Why open the flood gates? So I have doubts that it would work for us. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] github
> On 26 Apr 2018, at 12:15, Daniel Oberhoff > wrote: > > Hello, > > I was wondering if there is any chance to move development to github? I.e. > not just mirror, but as primary development repo, with issues and pull > requests? Would make collaboration a *lot* easier (think of submitting a pr > instead of having to generate/format/split patches). While I wouldn't be against it, I think most other developers would be very strongly against it. And to that end, I would say there is no or an extremely small chance that we would move to github Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] github
Hello, I was wondering if there is any chance to move development to github? I.e. not just mirror, but as primary development repo, with issues and pull requests? Would make collaboration a *lot* easier (think of submitting a pr instead of having to generate/format/split patches). Best Daniel signature.asc Description: Message signed with OpenPGP ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
