Em Sat, 13 Jul 2024 09:28:31 -0500 Carlos Bilbao <carlos.bilbao.osdev@xxxxxxxxx> escreveu: > On 7/12/24 09:49, Jakub Kicinski wrote: > > > Multiple vendors seem to prefer taking discussions off list, and > > ask contributors to work with them privately rather than just send > > patches to the list. I'd imagine this is because it's hard to fit in > > time for random developers popping up with features to review into > > packed schedule. From what I've seen "work in private" usually means > > someone on the company side will be assigned to handle the interaction, > > possibly months later. In worst case, the person scheduled to help > > the contributor takes over and writes the code themselves. > > This is not how the community is supposed to work. > > > So this is completely unenforceable, but as Mauro mentioned, it's an > opportunity to talk about this. > For starters, let's be clear about what the kernel community is actually > losing from closed-door discussions. Makes sense to me, but IMO it should also be describing what companies are losing with closed-door discussions: money and time to market. The usual excuse for innersource development practices is that this speeds up product development. In practice, this is often a false premise. Investing on closed door discussions and then send patch series only when internal development is done has two major drawbacks from company PoV: - Other companies with faster/better upstream companies may end having solutions merged upstream quicker, reducing or eliminating company market competitive advantages. Also, it means that the internal development will need to restart from the beginning, to follow the kAPI interfaces that were proposed/added by other vendors; - Even if the company is the first to upstream, maintainers may not agree with the developed solution, requiring substantial changes, and delaying product delivery. > E.g., if a company wants to fix their > driver, and an employee suggests approach A in an internal discussion, but > someone else prefers approach B, which is then shared publicly on the > mailing lists--is the real issue that the community did not get a chance to > learn about approach A? To discuss it, weigh the pros and cons, and share > opinions? If so, we should note that for published patches preceded by an > internal debate, it's encouraged to include some context in the cover > letters about why different approaches were _not_taken. > > > > Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx> > > --- > > CC: workflows@xxxxxxxxxxxxxxx > > CC: linux-doc@xxxxxxxxxxxxxxx > > --- > > .../maintainer/feature-and-driver-maintainers.rst | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/Documentation/maintainer/feature-and-driver-maintainers.rst b/Documentation/maintainer/feature-and-driver-maintainers.rst > > index f04cc183e1de..ac7798280201 100644 > > --- a/Documentation/maintainer/feature-and-driver-maintainers.rst > > +++ b/Documentation/maintainer/feature-and-driver-maintainers.rst > > @@ -83,6 +83,17 @@ bugs as well, if the report is of reasonable quality or indicates a > > problem that might be severe -- especially if they have *Supported* > > status of the codebase in the MAINTAINERS file. > > > > +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, 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. > > + > > Selecting the maintainer > > ======================== > > > > > Thanks, > > Carlos > Thanks, Mauro
