Deprecate a number of less used 10 and 10/100 Ethernet devices.

[brooks]

Summary

NOTE: this review is preceeding in parallel with the core vote on FCP-0101.

The current deprecated list is: ae, bm, cs, de, dme, ed, ep, ex, fe,
pcn, sf, sn, tl, tx, txp, vx, wb, xe

The list as refined as part of FCP-0101. Per the FCP, devices may be
removed from the deprecation list if enough users are found or they are
converted to iflib.

FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md

[rgrimes]

Does it make any sense at all to #define a macro gone_by_fcp101?

sys/dev/wb/if_wb.c

699

These need a post approved resting home in an address ending in freebsd.org. We do not need to start externalizing data from our repository outside.

[brooks]

In D17654#377166, @rgrimes wrote:

Does it make any sense at all to #define a macro gone_by_fcp101?

That's not a terrible idea, but I don't see the value in re-editing all these files to use one.

sys/dev/wb/if_wb.c

699

I do think an fcp.freebsd.org that does redirects to https://github.com/freebsd/fcp/blob/master/ would do it. There is no value in hosting this git repo or adding a manual publishing step.

[brooks]

My last comments where too aggressive. Blame a replying early in the morning and feeling rushed by your request to have this in for Thursday's build.

I don't have time or ability to build an fcp.freebsd.org and it's not clear there's an easy way to make a simple URL redirector work. I think it wouldn't be hard to build something the published accepted FCPs automatically.

[imp]

I'll point out that https://github.com/freebsd is under FreeBSD Project control, for the most part. It's a risk, but this code likely has a limited enough time horizon to accept that limitation until someone can create a fcp.freebsd.org redirector.

Eg, it's not important enough to gate this commit for that.

[rgrimes]

One of the reasons for me asking to "macrotise" this is that we can commit it today with a poor URL in it, and very easily correct that URL some time soon(ish),
Brooks if you or Imp write the macro I'll do the leg work of converting the current diff to use that macro and remove all my objections from the current state of affairs.

[rgrimes]

In D17654#377395, @imp wrote:

I'll point out that https://github.com/freebsd is under FreeBSD Project control, for the most part. It's a risk, but this code likely has a limited enough time horizon to accept that limitation until someone can create a fcp.freebsd.org redirector.

Eg, it's not important enough to gate this commit for that.

The projects current and official one source of truth is svn, and forcing anyone to have to use git for anything to do with the project is fundementally wrong at this point in time. I probably would of landed, what is it, a pull request?, to make changes to both the FCP process definition documents, and FCP-101 had it been done in svn.

[imp]

In D17654#377405, @rgrimes wrote:

In D17654#377395, @imp wrote:

I'll point out that https://github.com/freebsd is under FreeBSD Project control, for the most part. It's a risk, but this code likely has a limited enough time horizon to accept that limitation until someone can create a fcp.freebsd.org redirector.

Eg, it's not important enough to gate this commit for that.

The projects current and official one source of truth is svn, and forcing anyone to have to use git for anything to do with the project is fundementally wrong at this point in time. I probably would of landed, what is it, a pull request?, to make changes to both the FCP process definition documents, and FCP-101 had it been done in svn.

I disagree.

First, the FCP process requires git, as defined. Core defined this and approved it. The time to litigate it is over. there's been no demonstrated problems with using this work flow. Quarterly reports are now in git. The project allows these uses of alternative tools to give people the room to innovate without being constrained to dogmatic policies that may have run their course.

Second, the project has *NEVER* said that SVN is the *ONLY* source of truth. We encouraged perforce for a long time. We have had github mirror for a long time. Saying SVN only goes against the grain of what the project has done historically, against the grain of what the larger open source community is doing and is needlessly restrictive.

Which is why I think that this URL is fine. It's an officially blessed use of git by core, and we control the URL where it is to a large degree.

[brooks]

@allanjude suggested we might do something like papers.freebsd.org where we run the git repo though go-hugo to produce a formatted web page. That might be worth doing, but is definitely out of scope for the time being.

[brooks]

• Add a gone_by_fcp101_dev() macro to make it easier to change the

[rgrimes]

In D17654#377468, @brooks wrote:

@allanjude suggested we might do something like papers.freebsd.org where we run the git repo though go-hugo to produce a formatted web page. That might be worth doing, but is definitely out of scope for the time being.

I agree and support this position and effort.

[brooks]

Initially committed in rS339703