IMO having list of supported operationg systems is pointless, verifying against that particular list just makes everybody life harder. We waste more power and we pollute atmosphere more :)
Instead i think we should have list of dependencies with minimal and preferred version. i.e. Mandatory: gcc: minimal 7.0 preferred 9.0 cmake: minimal 3.10, preferred 3.13 Optional: libbpf: …. We are mixing today 2 different things: packaging for specific distro and making sure that code can work with specific build/runtime dependencies. Result of that is that we have debian-9 verify job which does not use debian-9 provided compiler and cmake so it brings zero value. — Damjan > On 18.11.2020., at 17:22, Paul Vinciguerra <pvi...@vinciconsulting.com> wrote: > > Expanding the audience of https://gerrit.fd.io/r/c/vpp/+/28721 > > > Patch Set 2: > > > > Am I correct if I summarize your point as: > > 1) we should document the distribution we officially support (this was the > > goal of the wiki page you setup) > > 2) as long as we do not break this list we should be allowed to use new > > tools etc. (which might be breaking other, unsupported distribution) > > > > If so, I agree with you but I think I disagree about the list of supported > > distribution :) > > Right now we run CI on: > > - Ubuntu 18.04 and 20.04 > > - Debian 9 and 10 > > - CentOS 7 and 8 > > I'd say this is what we currently support :) (but again: it is my own > > personal view here, and obviously I am a bit biased on the deb9 subject ;) > > ). > > There was discussion during last community call about dropping CentOS 7 > > support and I think the consensus was to keep it for now, but we might drop > > it for 21.01 (or something along that line). > > > > Probably the best should be to have that discussion directly on the ml and > > during the community calls instead of in this ticket. > > Everything on the wiki is wrong! It was right at some point in time, but > that time has passed. If it is right, it is a coincidence. The info was put > there to try to form a consensus, but no one agreed. > > If we can get a consensus, it should be memorialized in a README type doc in > the repo and the wiki can be removed or pointed to the repo. > > I don't know the history with deb9 for you, or who needs/wants it. I have > nothing against it. We should know how long we are to maintain it for, yes? > Is there a reason we can't support it by building a current python in the > makefile instead? > > I'd characterize #2 somewhat differently. People should be > allowed/encouraged to introduce new tools, but they need to be tested. Last > year, The folks at Netgate started pushing changes for Centos 8. I wasn't > approving them, not because I wanted to hold anyone up, but because they > didn't work for me on a fresh Centos 8 container. I was told that as long as > they didn't fail the CI, I could/should approve them. They shouldn't be > blocked from having the feature, but it has to still be tested/work. > > Paul > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18087): https://lists.fd.io/g/vpp-dev/message/18087 Mute This Topic: https://lists.fd.io/mt/78344343/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
