Re: [PATCH] docs: maintainer: discourage taking conversations off-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jakub Kicinski wrote:
[..]
> 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.
> 

To be honest I am lost trying to understand who the audience is and what
the actionable takeaway is from the guidance. It sounds like you are
trying to educate drive-by submitters to push back against requests to
take issues off the list. I think that's a reasonable education
campaign, but doesn't that kind of "submitter bill-of-rights" note
belong in Documentation/admin-guide/reporting-{issues,regressions}.rst
as explicit "how to work your issue upstream" guidance?




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux