Em Fri, 12 Jul 2024 09:42:07 -0600
Shuah Khan <[email protected]> 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