Re: [PATCH] Documentation: add platform support policy

>> > +Compatible on `master` and point releases
>> > +-----------------------------------------
>> > +
>> > +To guarantee that `master` and all point releases work for your platform the
>> > +first time:
>>
>> OK, as most of the changes go to `master` before getting merged down
>> to `maint` to become part of the next maintenance release, actively
>> protecting `master` from bugs is worthwhile.  What about changes
>> that do not come via the `master` branch?  Should they also join the
>> security list and have an early access to the cabal material?
>
> Good question, I actually am not sure of the answer. Does that make it
> too easy for anybody to claim they maintain some random platform and
> therefore they'd like to see all the RCE howtos weeks before they are
> fixed? I guess that we already have distro packagers in security
> list/cabal, so it may not be worse exposure than that.

>> All of the above are actually applicable to any active contributors
>> on any platforms.
>> ...
>
> Hits close to home ;)
>
> Does this mean that this part of the document should go somewhere else
> and we should just use a pointer here? Is there a guide handy for "how
> to soft-fork Git"?

> Maybe something like this is better?
>
> "Work closely with the developer fixing the issue; the turnaround to
> check that a proposed fix works for your platform should be fast
> enough that it doesn't hinder the developer working on that fix. If
> the turnaround is too slow, fixing the issue may miss the next release
> or the developer may lose interest in working on the fix at all."

>> > +* If you rely on Git avoiding a specific pattern that doesn't work well with
>> > +your platform (like a certain malloc pattern), if possible, add a coccicheck
>> > +rule to ensure that pattern is not used.
>>
>> Sorry, but I do not quite follow you here.
>>
>> In general, it is a bad idea to promise that we are willing to tie
>> our hands with coccicheck to satisfy needs by exotic platforms,
>> without first having a chance to see and evaluate such needs.
>>
>> "if possible, add" -> "sometimes it may turn out to be a good idea
>> to add", perhaps?
>
> Maybe it is better to ask them to discuss it with us on-list, and that
> the result of that discussion may be that they should add some such
> test? Or, do we want to firmly say, no coccicheck restrictions based
> on platform, give us a CI runner or bust? I don't feel super strongly
> either way - writing this section I was trying to come up with any way
> to get on-demand ~instant (<1hr) feedback to any contributor, and this
> seemed like one someone could do. That doesn't mean we have to let
> them, if we don't like this way.