Re: [FFmpeg-devel] Query from Reuters on XZ, open source, and Microsoft
On 11 Apr 2024, at 5:59, Vittorio Giovara wrote: > On Wed, Apr 10, 2024 at 9:19 PM Michael Niedermayer > wrote: > >> […] >> >> To bring some of the new blood into the project the project needs to >> first understand why they dont. And asking thouse who manage with >> difficulty >> to join could be a biased oppinion. >> > > In my experience this boils down to three points > 1. there is a legit barrier of entry in a large codebase such as ffmpeg, > but over time newcomers can learn about it > 2. the review process can be though and it's easy to miss a ping and > patches get lost, very defeating for a new developer This has honestly been one of the most discouraging things when contributing here. The ML workflow just contributes to make this even worse for me, as it makes it really hard to keep track of things. (Of course everyone is different and I get why some people like the ML-patches workflow, but having experienced both at VLC, I can say for myself I vastly prefer Gitlab-like solutions) > 3. there is net negative help from trolls who spread toxic poison, which is > confusing and uninteresting for the new blood > > 2 out of 3 can be solved technically, while the last one needs a cultural > shift - overall I think we're doing a good job at slowly changing pace and > having a bit of a better structure to solve situations when they arise, but > there is still a lot of work to do Another factor is IMO the general tone here on the ML, let’s just say it is not the most welcoming environment. It doesn’t help that sometimes technical discussion and „politics“ are mixed together so you have no way to escape it when you don’t feel like being dragged down by the state of this community some days… > -- > Vittorio > ___ > 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] Query from Reuters on XZ, open source, and Microsoft
On Thu, Apr 11, 2024 at 5:59 AM Vittorio Giovara wrote: > On Wed, Apr 10, 2024 at 9:19 PM Michael Niedermayer < > mich...@niedermayer.cc> > wrote: > > > Hi > > > > On Tue, Apr 09, 2024 at 03:57:02PM -0500, Romain Beauxis wrote: > > > [Apologies for continuing the conversation, Rémi] > > > > > > Le mar. 9 avr. 2024 à 14:05, Tomas Härdin a écrit : > > > > > > > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis: > > [...] > > > > > > > Also as someone who had to maintain a Gitlab instance at uni for a > > > > couple of years, I agree with Rémi's points > > > > > > > > > > My initial contribution was motivated by the argument presented in the > > > original talk that bringing new blood is critical to the survival of > the > > > project. > > > > > > If so, then I do believe that there must be a compromise to be made > > between > > > being easier to join for new developers and changing the existing > > workflow. > > > I'm also aware that changing the existing workflow has been discussed > > > before. > > > > > > I don't think that media is not cool anymore, as argued in the talk. I > > see > > > a _lot_ of interested developers in my other projects and all over the > > open > > > source landscape. That's why I believe that it's also important to > > consider > > > other reasons than the talk's argument. > > > > To bring some of the new blood into the project the project needs to > > first understand why they dont. And asking thouse who manage with > > difficulty > > to join could be a biased oppinion. > > > > In my experience this boils down to three points > 1. there is a legit barrier of entry in a large codebase such as ffmpeg, > but over time newcomers can learn about it > Yes, external and internal API is complicated mess in all libs, Most libs code is out of date with current State of Art found in other projects. Also contributors came and go, you can not force them to stay and maintain code mess. > 2. the review process can be though and it's easy to miss a ping and > patches get lost, very defeating for a new developer > Specially when single patch get lost in twenty trivial refactoring patches that spam the list. There should be at least separate list for refactoring patches, and keep this list only for important stuff like new features and bug fixes, if no switch to Github/Gitlab is wanted. > 3. there is net negative help from trolls who spread toxic poison, which is > confusing and uninteresting for the new blood > That is internal community reaction to 1. and 2. points. Think it about like auto-immune reaction to state of human body. > > 2 out of 3 can be solved technically, while the last one needs a cultural > shift - overall I think we're doing a good job at slowly changing pace and > having a bit of a better structure to solve situations when they arise, but > there is still a lot of work to do > Cultural shift - Cancel culture. The only point I agree about above is very last part of very last sentence. > -- > Vittorio > ___ > 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] Query from Reuters on XZ, open source, and Microsoft
On Wed, Apr 10, 2024 at 9:19 PM Michael Niedermayer wrote: > Hi > > On Tue, Apr 09, 2024 at 03:57:02PM -0500, Romain Beauxis wrote: > > [Apologies for continuing the conversation, Rémi] > > > > Le mar. 9 avr. 2024 à 14:05, Tomas Härdin a écrit : > > > > > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis: > [...] > > > > > Also as someone who had to maintain a Gitlab instance at uni for a > > > couple of years, I agree with Rémi's points > > > > > > > My initial contribution was motivated by the argument presented in the > > original talk that bringing new blood is critical to the survival of the > > project. > > > > If so, then I do believe that there must be a compromise to be made > between > > being easier to join for new developers and changing the existing > workflow. > > I'm also aware that changing the existing workflow has been discussed > > before. > > > > I don't think that media is not cool anymore, as argued in the talk. I > see > > a _lot_ of interested developers in my other projects and all over the > open > > source landscape. That's why I believe that it's also important to > consider > > other reasons than the talk's argument. > > To bring some of the new blood into the project the project needs to > first understand why they dont. And asking thouse who manage with > difficulty > to join could be a biased oppinion. > In my experience this boils down to three points 1. there is a legit barrier of entry in a large codebase such as ffmpeg, but over time newcomers can learn about it 2. the review process can be though and it's easy to miss a ping and patches get lost, very defeating for a new developer 3. there is net negative help from trolls who spread toxic poison, which is confusing and uninteresting for the new blood 2 out of 3 can be solved technically, while the last one needs a cultural shift - overall I think we're doing a good job at slowly changing pace and having a bit of a better structure to solve situations when they arise, but there is still a lot of work to do -- Vittorio ___ 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] Query from Reuters on XZ, open source, and Microsoft
Hi On Tue, Apr 09, 2024 at 03:57:02PM -0500, Romain Beauxis wrote: > [Apologies for continuing the conversation, Rémi] > > Le mar. 9 avr. 2024 à 14:05, Tomas Härdin a écrit : > > > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis: [...] > > > Also as someone who had to maintain a Gitlab instance at uni for a > > couple of years, I agree with Rémi's points > > > > My initial contribution was motivated by the argument presented in the > original talk that bringing new blood is critical to the survival of the > project. > > If so, then I do believe that there must be a compromise to be made between > being easier to join for new developers and changing the existing workflow. > I'm also aware that changing the existing workflow has been discussed > before. > > I don't think that media is not cool anymore, as argued in the talk. I see > a _lot_ of interested developers in my other projects and all over the open > source landscape. That's why I believe that it's also important to consider > other reasons than the talk's argument. To bring some of the new blood into the project the project needs to first understand why they dont. And asking thouse who manage with difficulty to join could be a biased oppinion. How many potential new developers do we reach, how many of them want to join? how many try to join, and what are the true reasosn for thouse who do not want to join or try and fail? Do we even try to attract new developers ? I think on a scale from 1 ro 10 we are maybe at a 2 when it comes to new developers, theres alot we could do, theres a alot we should know, a lot we could try. The effect on existing developers also must be considered Also even within the current developers there is friction. Solving this friction would increase the number of active developers. And if its not solved then i think maybe we are missing the problem because gitlab even if it adds more people will also increase these frictions even more. Because there are problems between people and not just a email vs gitlab one. What i belive would help is a way for people to develop modules (codecs, demuxers, muxers, ...) externally. That can be a plugin system, it can be something else That way each group can use the development and patch submission systems they prefer. I think the problem we have is less one of aging developers who want new people to come in and the tools being a problem. But instead the old developers having increasingly rigid oppinions that both old and new developers do not agree with. The solution here is to put some space between developers so everyone can work on what they like using whichever enviroment they like. While still somehow maintaining common communication Consider this also in abstract terms In an enviroment where everyone can block and object to everything (at least temporary) the number of potential disagreemnets will grow quardatically with the number of people. This is not scalable Now people certainly can work on their own fork but then users cannot use it or combine these. Plugins would be one fix for this A Decoder is a module that takes a 1-D list of bits and outputs 2-D array of pixels or several 1-D list of audio samples. That interface is not so complex that it needs to be kept inside a monolithic repository thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange 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] Query from Reuters on XZ, open source, and Microsoft
On 2024-04-10 02:57 pm, Stefano Sabatini wrote: On date Tuesday 2024-04-09 10:36:05 +0200, Nicolas George wrote: [...] I am pointing that for the burden, I am not offering to do the same for free for the people who are so short-sighted they feel entitled to block software-defined radio, break real-time display devices, prevent me from adding the strings API necessary for proper built-in documentation and information exfiltration from devices, etc., and apparently can. The "people" is at the end the TC/CC (Technical/Community Committee), and we agreed to commit to what these organisms decide to resolve conflicts for controversial features. Only if they respond. My matter is pending with the TC for close to 2 months now. Regards, Gyan ___ 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] Query from Reuters on XZ, open source, and Microsoft
Hi Paul, On Tue, Apr 9, 2024 at 7:47 PM Paul B Mahol wrote: > Kieran's criticism is unfounded one. As I, originally 'volunteered' in that > now 'famous' ticket about Certain Big Corpo bug report and kindly replied > in friendly manner to bug reporter and give reporter free support, me still > see no issues in that mine action. > I don't think anyone thinks that your action was bad. Quite the opposite, you were generous in donating your free time to help a company in need. They owe you thanks & more. 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] Query from Reuters on XZ, open source, and Microsoft
tis 2024-04-09 klockan 15:57 -0500 skrev Romain Beauxis: > [Apologies for continuing the conversation, Rémi] > > Le mar. 9 avr. 2024 à 14:05, Tomas Härdin a écrit : > > > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis: > > > On Wed, Apr 3, 2024, 11:39 Kieran Kunhya via ffmpeg-devel < > > > ffmpeg-devel@ffmpeg.org> wrote: > > > > > > > Hi Raphael, > > > > > > > > I was the author of the tweet and I gave a short talk about > > > > this > > > > topic at > > > > Demuxed at a video conference last year: > > > > https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s > > > > > > > > That said this is a community project and it would be best to > > > > continue the > > > > discussion on this mailing list unless agreed otherwise. > > > > > > > > > > Thank you for sharing your talk. It's indeed unfortunate that > > > large > > > companies are not more generous with the projects they depend on > > > _heavily_ > > > > > > I would like to offer a constructive feedback really not intended > > > as > > > trolling. I believe that supporting a more modern development > > > workflow such > > > as the GitHub PR or gitlab MR would go very long way in helping > > > onboarding > > > new developers. > > > > Considering which company owns GitHub and which company was the > > target > > of Kieran's criticism, this seems ill-adviced > > > > Would you mind explaining what you mean exactly? I want to respond > but I'm > not sure if I fully understand your point here. Microsoft owns Github. I think it would be foolish to make ourselves beholden to Microsoft, for reasons that I hope should be obvious. > > Also as someone who had to maintain a Gitlab instance at uni for a > > couple of years, I agree with Rémi's points > > > > My initial contribution was motivated by the argument presented in > the > original talk that bringing new blood is critical to the survival of > the > project. > > If so, then I do believe that there must be a compromise to be made > between > being easier to join for new developers and changing the existing > workflow. > I'm also aware that changing the existing workflow has been discussed > before. FFmpeg is far from the only project using an email driven workflow. Linux comes to mind. I don't buy arguments from network effects. Subscribing to a mailing list isn't hard. /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] Query from Reuters on XZ, open source, and Microsoft
On date Tuesday 2024-04-09 10:36:05 +0200, Nicolas George wrote: [...] > I am pointing that for the burden, I am not offering to do the same for > free for the people who are so short-sighted they feel entitled to block > software-defined radio, break real-time display devices, prevent me from > adding the strings API necessary for proper built-in documentation and > information exfiltration from devices, etc., and apparently can. The "people" is at the end the TC/CC (Technical/Community Committee), and we agreed to commit to what these organisms decide to resolve conflicts for controversial features. I have interest in the strings API (for which I have several use cases, from ffprobe to output serialization for filters) so it would be good to know the status of that, and I couldn't not find the technical reason of that rejection assuming that was given - there should be some written record of that somewhere. But anyway such technical decisions should be not set in stone and it should be possible to review them at any time. ___ 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] Query from Reuters on XZ, open source, and Microsoft
Le mar. 9 avr. 2024 à 18:46, Paul B Mahol a écrit : > On Tue, Apr 9, 2024 at 10:57 PM Romain Beauxis > wrote: > > > [Apologies for continuing the conversation, Rémi] > > > > Le mar. 9 avr. 2024 à 14:05, Tomas Härdin a écrit : > > > > > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis: > > > > On Wed, Apr 3, 2024, 11:39 Kieran Kunhya via ffmpeg-devel < > > > > ffmpeg-devel@ffmpeg.org> wrote: > > > > > > > > > Hi Raphael, > > > > > > > > > > I was the author of the tweet and I gave a short talk about this > > > > > topic at > > > > > Demuxed at a video conference last year: > > > > > https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s > > > > > > > > > > That said this is a community project and it would be best to > > > > > continue the > > > > > discussion on this mailing list unless agreed otherwise. > > > > > > > > > > > > > Thank you for sharing your talk. It's indeed unfortunate that large > > > > companies are not more generous with the projects they depend on > > > > _heavily_ > > > > > > > > I would like to offer a constructive feedback really not intended as > > > > trolling. I believe that supporting a more modern development > > > > workflow such > > > > as the GitHub PR or gitlab MR would go very long way in helping > > > > onboarding > > > > new developers. > > > > > > Considering which company owns GitHub and which company was the target > > > of Kieran's criticism, this seems ill-adviced > > > > > > > Would you mind explaining what you mean exactly? I want to respond but > I'm > > not sure if I fully understand your point here. > > > > > Kieran's criticism is trolling, as Kieran and rest of FFmpeg devs use > regularly and passionately Various Big Corpo products all the time. > > Kieran's criticism is unfounded one. As I, originally 'volunteered' in that > now 'famous' ticket about Certain Big Corpo bug report and kindly replied > in friendly manner to bug reporter and give reporter free support, me still > see no issues in that mine action. > > I strictly do make difference between collective and single specific > person. > Thanks for the clarification, that's a level of nuance I did not grasp. > > > > Also as someone who had to maintain a Gitlab instance at uni for a > > > couple of years, I agree with Rémi's points > > > > > > > My initial contribution was motivated by the argument presented in the > > original talk that bringing new blood is critical to the survival of the > > project. > > > > Projects go and die, and new ones rise up, all the time. > > > > > > If so, then I do believe that there must be a compromise to be made > between > > being easier to join for new developers and changing the existing > workflow. > > I'm also aware that changing the existing workflow has been discussed > > before. > > > > I don't think that media is not cool anymore, as argued in the talk. I > see > > a _lot_ of interested developers in my other projects and all over the > open > > source landscape. That's why I believe that it's also important to > consider > > other reasons than the talk's argument. > > > > Being someone actually trying to contribute, with years of developers > > experience and involvement in other communities, I was thinking that I > may > > be able to bring in more new context to the topic. > > > > If there's interest in continuing the discussion, could you or Rémi be > > willing to explain what kind of burden gitlab would add? > > > > Infrastructure maintenance, no volunteers for gitlab repo admin. > Extra steps to setup account and X-factor authentication. > > You have a little bit of a bias issue here I believe. :-) If you restrict the contributors only to people who can do git send-email and irc then, of course, you won't find many volunteers to maintain a gitlab repo. And, of course, the majority of the people voicing their opinion will be in favor of what they're already familiar with. There's always a learning curve to adopting new tools. Matter of fact, I'm old enough to remember myself complaining about git when it was taking over SVN.. > > > > Also, Rémi said this would make it harder to join the project, in which > way > > exactly? > > > > Otherwise, I'm happy to let this die and return to trying to get my patch > > committed.. > > > > Thanks, > > -- Romain > > ___ > > 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". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To
Re: [FFmpeg-devel] Query from Reuters on XZ, open source, and Microsoft
On Tue, Apr 9, 2024 at 10:57 PM Romain Beauxis wrote: > [Apologies for continuing the conversation, Rémi] > > Le mar. 9 avr. 2024 à 14:05, Tomas Härdin a écrit : > > > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis: > > > On Wed, Apr 3, 2024, 11:39 Kieran Kunhya via ffmpeg-devel < > > > ffmpeg-devel@ffmpeg.org> wrote: > > > > > > > Hi Raphael, > > > > > > > > I was the author of the tweet and I gave a short talk about this > > > > topic at > > > > Demuxed at a video conference last year: > > > > https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s > > > > > > > > That said this is a community project and it would be best to > > > > continue the > > > > discussion on this mailing list unless agreed otherwise. > > > > > > > > > > Thank you for sharing your talk. It's indeed unfortunate that large > > > companies are not more generous with the projects they depend on > > > _heavily_ > > > > > > I would like to offer a constructive feedback really not intended as > > > trolling. I believe that supporting a more modern development > > > workflow such > > > as the GitHub PR or gitlab MR would go very long way in helping > > > onboarding > > > new developers. > > > > Considering which company owns GitHub and which company was the target > > of Kieran's criticism, this seems ill-adviced > > > > Would you mind explaining what you mean exactly? I want to respond but I'm > not sure if I fully understand your point here. > > Kieran's criticism is trolling, as Kieran and rest of FFmpeg devs use regularly and passionately Various Big Corpo products all the time. Kieran's criticism is unfounded one. As I, originally 'volunteered' in that now 'famous' ticket about Certain Big Corpo bug report and kindly replied in friendly manner to bug reporter and give reporter free support, me still see no issues in that mine action. I strictly do make difference between collective and single specific person. > > > Also as someone who had to maintain a Gitlab instance at uni for a > > couple of years, I agree with Rémi's points > > > > My initial contribution was motivated by the argument presented in the > original talk that bringing new blood is critical to the survival of the > project. > Projects go and die, and new ones rise up, all the time. > > If so, then I do believe that there must be a compromise to be made between > being easier to join for new developers and changing the existing workflow. > I'm also aware that changing the existing workflow has been discussed > before. > > I don't think that media is not cool anymore, as argued in the talk. I see > a _lot_ of interested developers in my other projects and all over the open > source landscape. That's why I believe that it's also important to consider > other reasons than the talk's argument. > > Being someone actually trying to contribute, with years of developers > experience and involvement in other communities, I was thinking that I may > be able to bring in more new context to the topic. > > If there's interest in continuing the discussion, could you or Rémi be > willing to explain what kind of burden gitlab would add? > Infrastructure maintenance, no volunteers for gitlab repo admin. Extra steps to setup account and X-factor authentication. > > Also, Rémi said this would make it harder to join the project, in which way > exactly? > > Otherwise, I'm happy to let this die and return to trying to get my patch > committed.. > > Thanks, > -- Romain > ___ > 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] Query from Reuters on XZ, open source, and Microsoft
[Apologies for continuing the conversation, Rémi] Le mar. 9 avr. 2024 à 14:05, Tomas Härdin a écrit : > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis: > > On Wed, Apr 3, 2024, 11:39 Kieran Kunhya via ffmpeg-devel < > > ffmpeg-devel@ffmpeg.org> wrote: > > > > > Hi Raphael, > > > > > > I was the author of the tweet and I gave a short talk about this > > > topic at > > > Demuxed at a video conference last year: > > > https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s > > > > > > That said this is a community project and it would be best to > > > continue the > > > discussion on this mailing list unless agreed otherwise. > > > > > > > Thank you for sharing your talk. It's indeed unfortunate that large > > companies are not more generous with the projects they depend on > > _heavily_ > > > > I would like to offer a constructive feedback really not intended as > > trolling. I believe that supporting a more modern development > > workflow such > > as the GitHub PR or gitlab MR would go very long way in helping > > onboarding > > new developers. > > Considering which company owns GitHub and which company was the target > of Kieran's criticism, this seems ill-adviced > Would you mind explaining what you mean exactly? I want to respond but I'm not sure if I fully understand your point here. > Also as someone who had to maintain a Gitlab instance at uni for a > couple of years, I agree with Rémi's points > My initial contribution was motivated by the argument presented in the original talk that bringing new blood is critical to the survival of the project. If so, then I do believe that there must be a compromise to be made between being easier to join for new developers and changing the existing workflow. I'm also aware that changing the existing workflow has been discussed before. I don't think that media is not cool anymore, as argued in the talk. I see a _lot_ of interested developers in my other projects and all over the open source landscape. That's why I believe that it's also important to consider other reasons than the talk's argument. Being someone actually trying to contribute, with years of developers experience and involvement in other communities, I was thinking that I may be able to bring in more new context to the topic. If there's interest in continuing the discussion, could you or Rémi be willing to explain what kind of burden gitlab would add? Also, Rémi said this would make it harder to join the project, in which way exactly? Otherwise, I'm happy to let this die and return to trying to get my patch committed.. Thanks, -- Romain ___ 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] Query from Reuters on XZ, open source, and Microsoft
mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis: > On Wed, Apr 3, 2024, 11:39 Kieran Kunhya via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: > > > Hi Raphael, > > > > I was the author of the tweet and I gave a short talk about this > > topic at > > Demuxed at a video conference last year: > > https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s > > > > That said this is a community project and it would be best to > > continue the > > discussion on this mailing list unless agreed otherwise. > > > > Thank you for sharing your talk. It's indeed unfortunate that large > companies are not more generous with the projects they depend on > _heavily_ > > I would like to offer a constructive feedback really not intended as > trolling. I believe that supporting a more modern development > workflow such > as the GitHub PR or gitlab MR would go very long way in helping > onboarding > new developers. Considering which company owns GitHub and which company was the target of Kieran's criticism, this seems ill-adviced Also as someone who had to maintain a Gitlab instance at uni for a couple of years, I agree with Rémi's points /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] Query from Reuters on XZ, open source, and Microsoft
Rémi Denis-Courmont (12024-04-09): > Switching to an own Gitlab instance would simplify code review (that's > why I'm in favour) but it will add more burden on system admins, and > make joining the project harder. Over the last fifteen months, I have updated GitLab sixteen times for security issues (actually thirty two: sixteen for the mathematicians, sixteen for the computer scientists). I am pointing that for the burden, I am not offering to do the same for free for the people who are so short-sighted they feel entitled to block software-defined radio, break real-time display devices, prevent me from adding the strings API necessary for proper built-in documentation and information exfiltration from devices, etc., and apparently can. -- Nicolas George ___ 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] Query from Reuters on XZ, open source, and Microsoft
Hi, Le 9 avril 2024 01:13:31 GMT+07:00, Romain Beauxis a écrit : >I would like to offer a constructive feedback really not intended as >trolling. I believe that supporting a more modern development workflow such >as the GitHub PR or gitlab MR would go very long way in helping onboarding >new developers. Switching to Github would certainly make it easier for new contributors to join. But it is most definitely not acceptable for political reasons for FFmpeg to switch over to a proprietary and US-based forge. Also most MRs would probably be craptastic kludges, which would only add to the review burden. Switching to an own Gitlab instance would simplify code review (that's why I'm in favour) but it will add more burden on system admins, and make joining the project harder. This may be counter-intuitive. But just look at the sad situation for projects hosted on code.videolan.org: people are back to submitting patches by mail or give up entirely due to how hard it is to create an account. Lastly, I don't see how any of this helps motivate funding from big corps. Let's not miw things up here, please. ___ 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] Query from Reuters on XZ, open source, and Microsoft
On Mon, Apr 8, 2024 at 2:14 PM Romain Beauxis wrote: > I would like to offer a constructive feedback really not intended as > trolling. I believe that supporting a more modern development workflow such > as the GitHub PR or gitlab MR would go very long way in helping onboarding > new developers. > Plus one(thousdand). While I don't think using MR or mailing list for patches will immediately convince big tech corps to sponsor ffmpeg, it would definitely help the developer community and make sure we don't lose patchsets. The other open source community that I am involved with, the OCaml > compiler, moved to GitHub maybe 5/6 years ago and this has really done > wonders bringing in new contributors. And, you know, this is a niche > compiler that is also not getting much attention from AI/Machine Learning > people. > Other open source projects are probably less plagued by patents. -- Vittorio ___ 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] Query from Reuters on XZ, open source, and Microsoft
On Wed, Apr 3, 2024, 11:39 Kieran Kunhya via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > Hi Raphael, > > I was the author of the tweet and I gave a short talk about this topic at > Demuxed at a video conference last year: > https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s > > That said this is a community project and it would be best to continue the > discussion on this mailing list unless agreed otherwise. > Thank you for sharing your talk. It's indeed unfortunate that large companies are not more generous with the projects they depend on _heavily_ I would like to offer a constructive feedback really not intended as trolling. I believe that supporting a more modern development workflow such as the GitHub PR or gitlab MR would go very long way in helping onboarding new developers. I have been trying to contribute to the project for perhaps 18 months and, while I think I'm getting better at it, I still find it incredibly complex and hard to ramp up to. The other open source community that I am involved with, the OCaml compiler, moved to GitHub maybe 5/6 years ago and this has really done wonders bringing in new contributors. And, you know, this is a niche compiler that is also not getting much attention from AI/Machine Learning people. > Regards, > Kieran Kunhya > > On Wed, 3 Apr 2024, 16:52 Satter, Raphael (Reuters) via ffmpeg-devel, < > ffmpeg-devel@ffmpeg.org> wrote: > > > Dear FFMPEG community, > > > > This is Raphael Satter, a journalist with Reuters. I saw your thread on X > > about your experience with Microsoft in the context of the XZ story and > > would love to follow up with a few questions. > > > > Is there a good person to talk to? I’m reachable using the details below > > or on Signal/WhatsApp at +1 202 430 9389. > > > > Raphael > > > > raphael.sat...@tr.com > > raphaelsatter.com > > reuters.com/authors/raphael-satter > > > > Thomson Reuters > > 1333 H Street NW > > Washington, DC 20005 > > > > ☎️ +1 202 843-6302 > > > > ___ > > 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". > ___ 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] Query from Reuters on XZ, open source, and Microsoft
Hi Raphael, I was the author of the tweet and I gave a short talk about this topic at Demuxed at a video conference last year: https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s That said this is a community project and it would be best to continue the discussion on this mailing list unless agreed otherwise. Regards, Kieran Kunhya On Wed, 3 Apr 2024, 16:52 Satter, Raphael (Reuters) via ffmpeg-devel, < ffmpeg-devel@ffmpeg.org> wrote: > Dear FFMPEG community, > > This is Raphael Satter, a journalist with Reuters. I saw your thread on X > about your experience with Microsoft in the context of the XZ story and > would love to follow up with a few questions. > > Is there a good person to talk to? I’m reachable using the details below > or on Signal/WhatsApp at +1 202 430 9389. > > Raphael > > raphael.sat...@tr.com > raphaelsatter.com > reuters.com/authors/raphael-satter > > Thomson Reuters > 1333 H Street NW > Washington, DC 20005 > > ☎️ +1 202 843-6302 > > ___ > 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".
[FFmpeg-devel] Query from Reuters on XZ, open source, and Microsoft
Dear FFMPEG community, This is Raphael Satter, a journalist with Reuters. I saw your thread on X about your experience with Microsoft in the context of the XZ story and would love to follow up with a few questions. Is there a good person to talk to? I’m reachable using the details below or on Signal/WhatsApp at +1 202 430 9389. Raphael raphael.sat...@tr.com raphaelsatter.com reuters.com/authors/raphael-satter Thomson Reuters 1333 H Street NW Washington, DC 20005 ☎️ +1 202 843-6302 ___ 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".
