> On Feb 20, 2019, at 06:01, Mike Looijmans <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'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
