On 7 March 2018 at 09:37, John Baldwin <j...@freebsd.org> wrote:
> On Tuesday, March 06, 2018 06:46:37 PM Eitan Adler wrote:
>> On 6 March 2018 at 08:26, John Baldwin <j...@freebsd.org> wrote:
>> > On Monday, March 05, 2018 07:13:59 PM Eitan Adler wrote:
>> >> On 5 March 2018 at 10:08, John Baldwin <j...@freebsd.org> 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
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to