Em Sat, 13 Jul 2024 17:19:56 +0300
Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> escreveu:
> On Sat, Jul 13, 2024 at 10:13:28AM +0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 12 Jul 2024 17:05:58 -0700 Jakub Kicinski escreveu:
> > > On Fri, 12 Jul 2024 11:43:14 -0700 Dan Williams wrote:
> > > > This reads as a vague ambiguous quasi-threat with no actionable way to
> > > > enforce it. In contrast, successful maintainers already have a sense of
> > > > the benefits of pushing discussions to the list as much as possible.
> > > >
> > > > For new and growing maintainers, which I assume are the audience for
> > > > this guidance, that are unaware of the pitfalls of taking conversations
> > > > off-list, they likely need help understanding the *benefits* of open
> > > > development.
> > >
> > > I don't think so. If your boss comes to you and says "Dan, from now on
> > > try not to reply to customers on the list, open a ticket first and only
> > > reply once tickets is resolved". Is it more useful to you to be able to
> > > extol the benefits of open source process; or to tell them "this is not
> > > allowed, here's a link to a quasi-threat"?
> >
> > No matter what you write, between your text and their boss's directive,
> > I bet the latter will be a lot more effective.
>
> I don't agree with this. I have found clear written rules valuable
> personally when discussing with management. Being able to point to
> upstream policies and tell "this is not allowed" helped change internal
> processes. It will obviously not have a 100% success rate, but it's not
> useless.
That's basically what I said: such things happen top/down and not at
developer/maintainer level. Sure having it documented somewhere, on
some document that management would actually read can be useful on
discussions, specially when companies hire a third party company to
help with their upstream process.
The point is: a developer-focused document - or even a submission
document process won't affect how companies do their inner source
development: companies that have internally heavy development teams
will basically keep running their own internal development cycle,
being concerned about upstream only when their product managers
authorize them to publicly disclosure patches.
If the goal is to create a management awareness about how to better
cope with upstream, then my suggestion is to write a new document
from scratch [1] focusing specifically on that, containing a list of
best practices with focus on orienting management inside companies
about how to deal with developers and maintainers working on
upstream.
[1] there is a document there already that seems to be focused at
management style, but it doesn't cover any best practices
with regards to innersource/upstream:
Documentation/process/management-style.rst
> > > > So if this goes in as is, so be it, but it feels like a missed
> > > > opportunity to extoll the virtues of open development. The benefits are
> > > > in the same vector as the "release early, release often" guidance where
> > > > the urge to polish a solution in private is a common trait of newcomers.
> > > > Lets document some tribal knowledge of how one moves past that first
> > > > instinct.
> > >
> > > Hm, the disconnect may be that you think this happens with maintainers
> > > without upstream experience. So we can train them up to be better.
> >
> > No, that's the case where you can still "fix" maintainer's behaviors.
> >
> > > In most cases it happens to folks with experience who are good
> > > maintainers. They just get 2 orders of magnitudes more patches from
> > > inside the company that outside. Then a contribution comes from outside,
> > > the maintainer is overworked, and tries to shoehorn the patch into the
> > > existing, internal-only process.
> >
> > It seems unavoidable that internal patches have higher priorities even
> > if the maintainer is not overloaded.
> >
> > Even on a perfect world, the degree of confidence on internal patches is
> > usually orders of magnitude higher, as internal devs have access to internal
> > product documentation, future line of products that will re-use the same
> > driver and, on larger projects, will also be already tested by internal
> > CI-based regression tests.
> >
> > The external patches won't have that, so they need to be reviewed by
> > an internal developer, checked against internal docs and then submitted to
> > the company's internal CI regression test infra to achieve the same degree
> > of confidence.
>
> We don't seem to live in the same (perfect or imperfect) world. In my
> experience, contributions from external kernel developers are often
> better than patches originating from within a company. External
> contributors are more used to follow proper upstream review processes.
It is not about being better/worse. It is about fitting inside the
innersource processes related to quality ensurance (QA).
Vendors that see their Linux driver as part of their product delivery have
such processes and won't be willing to accept patches that don't pass on
their processes.
So, all patches (internal or external ones) need to be submitted to
their QA processes, effectively meaning that someone inside such
companies should be responsible for reviewing the patch.
Heh, you can see this even on distributions like Debian, Ubuntu,
Fedora, openSUSE - and even on open source userspace projects:
if you submit a bug report or a patch, someone will handle
the ticket, reviewing your patch and/or writing their own patches
to solve the issues.
Inside companies (in special big ones), it usually means that a
manager or a triage team will pick the bug report/issue and then
delegate it to an internal developer, who will be internally
owning the upstream patch set, doing tests, reviews and running
it on the company's CI tools.
Smaller companies, companies that are starting now with their
upstream process and companies where Linux is not their main focus
usually delegate it to third party companies, who will be handling
it on their behalf or have small open source teams. Those are the
ones where changing processes are easier.
Bigger companies have more complex development processes. Among those,
there are the ones where Linux is part of their products. They
are usually responsible for a vast amount of Kernel patches[1].
Changing their process is hard and takes a lot of time/efforts.
[1] Looking at https://lwn.net/Articles/972605/, it can be seen
that: 7.4% is unknown, 6.8% is none and 2.0% consulting, meaning
that more than 80% is credited to "direct" contribution.
Granted, part of those were actually be done by third parties
(or with their help). Still, just the top 17 companies listed there
are responsible for more than 50% of the upstream changes. I bet
that almost all of those (if not all) have their own internal
innersource processes, and patches are only accepted once the
company developers/maintainers handled external patches and have
them passed though their QA systems.
Thanks,
Mauro
