On 7 March 2018 at 09:37, John Baldwin <[email protected]> wrote: > On Tuesday, March 06, 2018 06:46:37 PM Eitan Adler wrote: >> On 6 March 2018 at 08:26, John Baldwin <[email protected]> wrote: >> > On Monday, March 05, 2018 07:13:59 PM Eitan Adler wrote: >> >> On 5 March 2018 at 10:08, John Baldwin <[email protected]> wrote: >> >> > On Monday, March 05, 2018 07:54:58 AM Eitan Adler wrote: >> >> >> Author: eadler >> >> >> Date: Mon Mar 5 07:54:57 2018 >> >> >> New Revision: 330451 >> >> >> URL: https://svnweb.freebsd.org/changeset/base/330451 >> >> >> >> >> >> Log: >> >> >> MFC r306837: >> >> >> >> >> >> [net80211] extend the ieee80211_rx_stats struct to include more >> >> >> information. >> >> > >> >> > Have you thought about the KBI implications of this change and some of >> >> > the >> >> > other changes you've merged? >> >> >> >> I do have a copy of the modules from 11.1 and have loaded them at >> >> various points in time after merging. That said, I am not perfect. >> >> Unfortunately, my -STABLE box did not have fully functioning drivers >> >> before these changes so its difficult to test anything beyond "loads >> >> and does not panic.". I havn't done so today yet, but that will happen >> >> soon. >> >> >> >> Ensuring these things work through code inspection is certainly >> >> possible and I've skipped over several changes as a result. >> > >> > Loading a module doesn't alone doesn't actually test for breakage. >> >> I'm aware. In this case I should likely just revert this change since >> its a pretty blatant break. > > I suspect many of these changes for iwm, etc. are all intertwined so I'm not > sure if you can leave out individual ones.
Possibly. I do have iwm working on my laptop though. I also know of one open PR assigned to me w.r.t. a model I don't own. I'll be addressing it some time this week. >> > Batching >> > up changes into a single diff is also helpful since if an API changes back >> > and forth in HEAD multiple times, collapsing them means that for stable you >> > may only need a single compat shim rather than several. >> >> Understood. My intention in doing them one-by-one was to make it >> easier to bisect if something goes wrong. > > For stable I think we also want to balance this with: > > 1) Not putting stable in a known-broken state. If there are followup fixes > either for compile or runtime performances, those followup fixes should > always be included in the commit that merges the original change. To the extent possible I tried to do this. > 2) Preserving ABI. The desire to avoid putting stable into known-broken > state means that MFCs should include the ABI shims along with the original > change. This part I missed very clearly. I'll be sure to be more careful in the future. -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "[email protected]"
