On Fri, 12 Jul 2024 20:11:56 +0200 Mauro Carvalho Chehab wrote: > Not sure what this somewhat obscure message wants to accomplish. > > It is quite common to have developers and maintainers discussing > outside public forums and internally at the companies they're working > for. There are lots of reasonable exceptions besides security. On my > years of experience, the reasons I've seen more often are: > > 1. language and/or cultural barriers; > 2. teaching and mentoring new developers to start contributing upstream; > 3. need to have internal discussions in the light of some IP protected > material. > > (1) and (2) are very common for non-native English speakers > and for newbies, and we do want to have more contributions from > them. (3) is unavoidable, as discussions related to protected > IP can't be disclosed due to legal reasons. Those are valid points but I don't know how to weave them in without losing clarity. The goal is also to call out such behavior to _contributors_, so that they know they can reach out to more senior maintainers if it happens to them. We don't know when discussion is taken private (by definition). Otherwise contributors get mistreated by some corpo-maintainer and they turn away from Linux :( > Also, if you take it to the letter, have discussions on LPC, > summits BoFs, other events handled by the open source community > and wall conversations are "closed forums/private conversations". > I've seen a lot of good results produced on such private > conversations that solved relevant conflicts and got > materialized as great contributions. > > There's nothing wrong with that, provided that the outcoming of > such internal discussions are reflected publicly as patches, > summit minutes, LWN articles, etc. Would it help if we speak of "open forums" instead of mailing list? I think LPC including "hallway track" fall squarely under "conducted in a manner typical for the larger subsystem." Here's slightly edited version: Open development ---------------- Discussions about user reported issues, and development of new code should be conducted in a manner typical for the larger subsystem. It is common for development within a single company to be conducted behind closed doors. However, development and discussions initiated by community members must not be redirected from public to closed forums or to private email conversations. Reasonable exceptions to this guidance include discussions about security related issues. > The only issues I see with such talks is that the work when > co-authored should be properly marked as such and that > reviewews/acks taken behind doors don't have the same meaning > as an upstream review, as they may be due to some internal > formalities. > > IMO, the best would instead to give a positive message. E. g. > something like: > > Maintainers must encourage discussions and reviews to happen > at public mailing lists, avoiding whenever possible to have > internal discussions. That's not the message, tho. If someone emails a company privately that's fine. If company has internal processes for its development - also fine (as explicitly called out). I'm trying to set the baseline, not describe the ideal world. I am specifically calling out that if someone submits a patch, or reports a regression the correct response is to review it on the list. Like a normal person. Not reply privately that "it's on the company roadmap, just wait" :| Or reply with a patch company has "forgotten to upstream".. Maybe it's a cultural thing, but to me this is where the relentless positivity is counter-productive. I don't want to encourage people to be angles. I want them not to do the shitty thing.
