On Wed, Feb 20, 2019 at 9:22 AM Luca Ceresoli <l...@lucaceresoli.net> wrote: > > Hi Jean-Francois, > > On 20/02/19 15:01, Jean-Francois Dagenais wrote: > > > > > >> On Feb 20, 2019, at 06:01, Mike Looijmans <mike.looijm...@topic.nl > >> <mailto:mike.looijm...@topic.nl>> wrote: > >> > >> +1 for that! > >> > >> (and not just on meta-xilinx, but on kernel, u-boot, and other > >> repositories as > >> well) > >> > >> These "big blob" changes are impossible to manage. > > > > Indeed. Here's a concrete example: > > > > I had to integrate the audio on our board. Our design called for the > > xilinx_dma driver to come into play. When I started using the cyclic > > mode with the audio I found it was (and still is I believe) completely > > broken/non-functional. I spent a week and a half working on > > xilinx_dma.c. I meticulously fixed the different issues I saw, cleaned > > up a whole bunch of stuff and carefully created a nice series of commits > > so that it could be discussed and applied. > > > > I was carrying this in our repo awaiting a closely upcoming release. To > > my dismay, xilinx_dma.c had a complete overhaul appear in github's > > linux-xlnx upon the release and to add insult to injury, the commits > > which were finally deposited on the repo pre-dated my work! > > Oh dear. I also have fixes for cyclic DMA on the 2017.x (4.9) series. > Now I guess I will be unable to apply them on the 2018.x (4.14) series, > just as you have. :-( > > > And please, PLEASE, if Xilinx wants more help and freebies, let's use > > the issues and pull request mechanisms instead of the clunky patches! Or > > gitlab.com <http://gitlab.com>'s merge requests (We're gitlab here). > > Patch management is completely un-natural and discourages MANY > > developers to get involved. Basically, all these companies combing > > through Xilinx's code are a gold mine of contributions and bug fixes. > > One would think that Xilinx would make it SUPER easy for them to report > > and even fix things. No real changes can go in without Xilinx admins > > going through a full review and adjustment process anyway... so what's > > the obstacle? It's available and free (right?), if not on github then on > > gitlab. > > I'm fine with patches, I'll be OK with any system that works. What's > important is that development happens in a public place.
Agreed with this sentiment .. It is important to be flexible on the actual workflow. Since there are many arguments for (and against) patch bombs, as well as for and against needing to monitor a queue of pull requests on web interfaces (which is why I always struggled to figure out what was going on in OpenStack) :D Cheers, Bruce > > > Anyway, I fully appreciate that Xilinx has come a long way with > > open-source and seeing all the love and care Manju, Michal, Kwon, and > > many other Xilinx employees are putting into this I am confident that > > things will continue to improve. > > I totally agree. There have been many improvements, there are many more > to go, they should happen more quickly. > > -- > Luca > -- > _______________________________________________ > meta-xilinx mailing list > meta-xilinx@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-xilinx -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
