Gathering this data would be useful to make a decision. I myself have invested lots of time porting to other platforms such as PI, JETSON, Arm or Android. If the community is interested in maintaining a platform there should be action. For a long time I haven't seen much effort there. Ideally I like to see several platforms windows for portability reasons. But I question there's bandwidth for that.
On Wednesday, August 28, 2019, Aaron Markham <aaron.s.mark...@gmail.com> wrote: > I have an open issue about gathering data per platform install so there can > be an informed discussion on prioritization or even cutting platforms. > Until then... I wouldn't cut one. > > I would like to hear the pros and cons for dropping some native platform > support in favor of containers. But... For windows I believe Nvidia still > hasn't provided a way to access the GPU from docker on most windows OSs. If > that's true, that would imply we shouldn't drop windows assuming that > windows users will be able to run things in docker. That being said, why > support every range of possibilty of blas or mkl or opencv? Why not come up > with a set of strict dependencies for windows to simplify the build, CI, > and binary distribution? > > > On Wed, Aug 28, 2019, 09:30 Pedro Larroy <pedro.larroy.li...@gmail.com> > wrote: > >> Hi >> >> I would like to propose a discussion to slim down CI by dropping some jobs >> which are of questionable value, other which have received little community >> support: >> >> - Drop centos: we can't support every distro, if anything we should clearly >> specify which versions of base libraries are needed and test for the latest >> stable release of Ubuntu. I don't see much value in testing different >> distribution flavours. Not sure what was the rationale for adding CentOS in >> the past but this might no longer apply. >> >> - Drop windows: windows has received little attention from the community >> and mostly has served as a gatekeeping from CI. >> >> Dropping windows would allow to migrate to a more advanced CI framework >> such as Drone or a fully container based one given that Jenkins has quite a >> bit of baggage and for the most part we are testing on containers. >> >> Pedro. >> >
