Emily Shaffer <nasamuffin@xxxxxxxxxx> 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.
