Em Fri, 12 Jul 2024 09:42:07 -0600 Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> escreveu: > On 7/12/24 09:25, Mark Brown wrote: > > On Fri, Jul 12, 2024 at 07:49:03AM -0700, Jakub Kicinski wrote: > > > >> +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. True. So what? > >> However, maintainers must not redirect discussions > >> +and development related to the upstream code from the upstream mailing lists > >> +to closed forums or private conversations. Reasonable exceptions to this > >> +guidance include discussions about security related issues. 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. 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. 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. Regards, Mauro
