Re: [PATCH] Documentation: add platform support policy

>
> Emily Shaffer <nasamuffin@google.com> writes:
>
> >> > +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.
>
> Stopping at saying "You may want to ask to join the security list"
> and then leave the vetting process out of the guidelines for the
> contributor (i.e. out of this document) may strike a good balance.
>
> We will obviously be careful about whom to add to the security list,
> but that does not change where people hear about the list and apply
> to join.

> >> 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"?
>
> Once we have a contributor guidelines this is a good material to
> migrate there, but that would probably wait after the dust from this
> document settles.

>
> > 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."
>
> I think that is a good approach to take.  "We will not promise to
> wait for you if you are slow, and that is not limited to those who
> are working on minority/niche platforms" is a good point to make.
>
> >> > +* 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.
>
> Yes.  If you want to add additional constraints on how the codebase
> does things, discuss it on list first and work with us to come up
> with a way to without forcing too many unnecessary constraints on
> other platforms.  It may result in keeping the generic codebase
> pristine and free from #ifdef and having platform specific code
> somewhere in compat/ but such details do not have to be spelled
> out---they will be different case-by-case and we will hopefully
> devise new and improved ways to deal with them.