Hi JFD and all, Thanks for the feedback.
We introduced rebase tree in linux-xlnx to make it easier for holding or migrating patches (custom or development patches). If there are issues that are found, please do let us know asap via mailing list. We will try to address/replicate the issue and see if we can post RFC patches earlier to fix those issues. Honestly, I do like pull-request, but github PR still lacks certain features to be in sync with YP requirements ( for ex: Maintainer signed-off etc). I am definitely open to having github issues to fix the bugs (for meta layers). We will make good effort towards maintaining a master-next to show-case upcoming work. Thanks, Manju From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Jean-Francois Dagenais Sent: Wednesday, February 20, 2019 6:02 AM To: Mike Looijmans <mike.looijm...@topic.nl>; meta-xil...@lists.yoctoproject.org Cc: Luca Ceresoli <l...@lucaceresoli.net>; Simon Labarre <labar...@sonatest.com> Subject: Re: [meta-xilinx] libmali and wayland 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! I could no longer afford to spend time on this and I ended up copy/renaming the xilinx_dma.c file and we are using an un mergeable fork. Basically, the Xilinx workflow means it has completely missed the point of open-source and the benefits that come with it. This story has knocked me pretty hard and I can echo all the pains that the others on this thread have raised. I understand that there may be legal issues here. But perhaps there are ways to mitigate their constraints. For example, since it's git, xilinx could setup different branches or even whole repos with README.md specifying the terms of usage of the repo. For example, a whole github space called xilinx-community? The community repos could be used as open spaces where bleeding edge is worked on and discussed collaboratively until deemed sufficiently mature to be merged (or applied) back to the official releases repo. Some people, such as we at Sonatest, would live on the master most of the development cycle, contributing back periodically. 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. Also adds some benefix for Xilinx, as it prevents that Xilinx's implementation gets completely thrown out just because some other manufacturer beat them to the punch. Well in this case, Sonatest got it efforts thrown out. We here are lucky, my employer shares my views on open-source and community but it does have a limit, and I suspect this type of experience might chill others which may have been hesitant in the first place to invest workforce resources into giving back to other parties. 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. Thanks Xilinx! Cheers! /jfd
-- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx