- move from stable/next/devel to 11.2, 12.0, 13.0 specific ports
- add a bleeding edge wip port
- wip port does not build as base is missing the lkpi changes under review
- add to MOVED
- add UPDATING entry
- rP487117: LinuxKPI-based DRM ports: move to new ports nomenclature.
poudriere tested on 11.2, 12.0, HEAD - except for wip which misses lkpi changes to base
Unit Tests Skipped
Apologies for being nitpicky, see inline comments.
I'm also not 100% sure if it's OK to have '.' in the middle of a ports name. I couldn't see anything about it in the porters handbook, but please double check.
Might be phabricator, but this looks like a newline in the wrong place.
If we're basing fbsd11.2 on drm-next and fbsd12.0 on 4.16 (what's now drm-devel) this should probably change.
I think we should base this on drm-next-kmod (4.11) instead.
I think this should be based on drm-devel-kmod
I thought we would keep drm-devel-kmod for current? Then once 13 is branched, we can copy drm-devel at that time and create fbsd13.0.
I created the necessary git branches to point these ports to. It would be good if we could let 11.2 use 4.11 so we can scrap 4.9 all together (and thus remove some legacy code from lkpi).
Now we have these branches:
drm-v4.11-fbsd11.2 for drm-fbsd11.2-kmod
drm-v4.16-fbsd12.0 for drm-fbsd12.0-kmod
Adding a freebsd version suffix to a git branch indicates that the branch is locked to a specific freebsd release.
For current, they stay the same (drm-vX.YY)
I'm not sure we should update -wip until it can build against head. We're still waiting for patches for 4.18 to be committed.
Concerning the versioning: this was intentional. I want to have one move commit that just moves the current status to the new nomenclature followed by individual commits to bring these ports to whatever versions we want them at. That'd allow us, in worst case, to individually revert changes if there are problems.
Concerning the ports names - will check, I didn't see anything in the handbook on first glance and portlint didn't complain either.
Good catch, thanks. This probably happened somewhere along the pipeline.
With the introduction of wip, it gets mighty confusing if there is a devel and wip, I think. Maybe drm-fbsdhead-kmod? It's a mouthful...