All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Challenges in Upstream vs. Embargoed Development in Intel Graphics.
Date: Wed, 5 Sep 2018 09:48:40 +0200	[thread overview]
Message-ID: <20180905074840.GB29052@kroah.com> (raw)
In-Reply-To: <CABVU7+u+F1CXAW48_XfhLy59BOTxAS-qa_pG4Xjkki=f4Rr9Kg@mail.gmail.com>

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.

Why do we care about something like this?  It sounds like it is an Intel
issue in that they want to delay pushing stuff upstream.  Why does
upstream care about this?

> > 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.

Great!  So if this rule runs into opposition to people within your
company, doesn't that sound like a meeting with those company members is
the best solution?

> 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.

Ah, so you want to talk about how to change your process to work better
with companies that don't like doing upstream-first work?  That sounds
like a nice talk, but you need to make that a bit more clear here :)

> Also we have some challenges on keeping everything updated and ready
> for upstreaming at any moment.

"any moment"?  Don't you know this ahead of time?  If not, that sounds
like a company problem...

thanks,

greg k-h

  parent reply	other threads:[~2018-09-05  7:48 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-04 19:54 [Ksummit-discuss] [MAINTAINERS SUMMIT] Challenges in Upstream vs. Embargoed Development in Intel Graphics Rodrigo Vivi
2018-09-05  4:22 ` Leon Romanovsky
2018-09-05  4:49   ` Rodrigo Vivi
2018-09-05  7:38     ` Leon Romanovsky
2018-09-05  7:48     ` Greg KH [this message]
2018-09-05  8:17       ` Daniel Vetter
2018-09-05  8:31         ` Greg KH
2018-09-05  9:00           ` Daniel Vetter
2018-09-05  9:34             ` Leon Romanovsky
2018-09-05 22:45               ` Rodrigo Vivi
2018-09-06 13:56                 ` Leon Romanovsky
2018-09-05 11:21             ` Mark Brown
2018-09-06  9:54             ` Linus Walleij
2018-09-06 10:15               ` Jani Nikula
2018-09-06 10:27                 ` Mark Brown
2018-09-06 10:25               ` Arnd Bergmann
2018-09-06 10:43                 ` Linus Walleij
2018-09-06 10:51                   ` Mark Brown
2018-09-06 12:49                   ` Sean Paul
2018-09-06 16:00                     ` Jon Masters
2018-09-06 20:41                     ` Rodrigo Vivi
2018-09-06 20:35               ` Rodrigo Vivi
2018-09-05 11:13         ` Mark Brown
2018-09-05  7:48     ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2018-09-04 17:42 Rodrigo Vivi
2018-09-06 20:09 ` Rodrigo Vivi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180905074840.GB29052@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=rodrigo.vivi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.