Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Challenges in Upstream vs. Embargoed Development in Intel Graphics.

[Leon Romanovsky <leon@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3441 bytes --]

On Tue, Sep 04, 2018 at 09:49:13PM -0700, Rodrigo Vivi wrote:
> On Tue, Sep 4, 2018 at 9:22 PM Leon Romanovsky <leon@kernel.org> wrote:
> >
> > On Tue, Sep 04, 2018 at 12:54:16PM -0700, Rodrigo Vivi wrote:
> > > Hi there,
> > >
> > > I've submitted a proposal for plumber's referred track. There, I want to
> > > talk
> > > about tools and challenges we have on embargo development vs upstream one
> > > and
> > > how to get focus on upstream first and upstream always mentality.
> > >
> > > The name of plumbers proposal talk is:
> > > "Unveiling Intel Graphics Internal Development"
> > >
> > > I'm not sure if the talk will get accepted, but anyway I'd like to have the
> > > chance to talk to other maintainers to exchange views on different ways of
> > > maintaining this kind of embargo development including challenges, tools,
> > > processes, and rules.
> > >
> > > So I'm interested in hallway tracks of Maintainer / Kernel Summit, or maybe
> > > a
> > > bof session if there's interest.
> > >
> > > Please let me know if there's interested or if further information and/or
> > > clarification is needed.
> >
> > What is "embargo development"? Are you referring to US government
> > restrictions or to anything else?
>
> No. nothing to do with government.
> Embargoed by company's temporary restrictions.
>
> Sorry for not being clear here.
>
> >
> > Also can you please explain why should we know about internal Intel
> > development flow?
>
> First of all I don't believe that we are the only one that need to
> keep this kind
> of flow and i915 has a very active development and we are strongly
> committed with
> upstream development. Our golden rules for internal development is
> upstream first, upstream always.

Good, indeed you are not alone in this attitude.

> So, maybe sharing some knowledge and lessons we learned on the past years
> might be useful to someone else that might still struggle with closed source
> style of development.

Honestly, I hardly can see how this topic fits "kernel summit" format,
but maybe I'm wrong here.

>
> Also we have some challenges on keeping everything updated and
> ready for upstreaming at any moment. Maybe someone else has better tools
> and better procedures than us, but we are just not aware because we
> never talked.

As the one who was involved in transforming Mellanox from closed-source
company to be upstream-driven company, I can assure you that all changes
are contained inside the company. They include change of responsibilities,
organization restructure, legal, HR and many more. Those changes take
a loooooot of time with enormous internal pushback.

>
> Ultimately there are some essential questions that I'd like to open to community
> and ask for feedback and ideas. Some issues and gaps that cannot be solved, or
> even come to a consensus on, internally.
>
> But my hope is that we can keep that on the constructive space.
>

First you need to raise your questions in this ML, but from the little I
saw in this thread, you are struggling with business justification to
reduce "embargo".

Thanks

> Thanks,
> Rodrigo.
>
> >
> > Thanks
> >
> > >
> > > Thanks in advance,
> > > Rodrigo.
> >
> > > _______________________________________________
> > > Ksummit-discuss mailing list
> > > Ksummit-discuss@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> >
>
>
> --
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]