On Wed, Jul 10, 2024 at 1:13 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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. Thanks, done. > >> 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. Ok. For now I'll leave it as-is. > > > 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. Ok. I've got a rephrasing for the next reroll; still thinking I can get that sent by tomorrow latest. Thanks! - Emily
