public inbox for dri-devel@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Liviu Dudau <Liviu.Dudau@arm.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: RFC: drm-misc for small drivers?
Date: Fri, 27 Jan 2017 09:44:18 +0000	[thread overview]
Message-ID: <20170127094417.GD3140@e110455-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAKMK7uFu5OP9edzQZCZ=eAgOAxjohPvQe-HH4Lh2TSpakos5Mw@mail.gmail.com>

On Fri, Jan 27, 2017 at 07:55:22AM +0100, Daniel Vetter wrote:
> On Thu, Jan 26, 2017 at 9:48 PM, Liviu Dudau <liviu@dudau.co.uk> wrote:
> >> I'm not certain number of people is a good metric, TBH. There are cases
> >> where a lot of people are working on a driver, but the patches are not being
> >> merged to the maintainer tree. In these cases, it makes sense to migrate the
> >> driver to -misc and have the community merge the patches.
> >
> > Sorry, I should've been more explicit: I was referring to the number of
> > contributors with public commit rights, not all the engineers involved. In
> > Mali DP's case we do most of the development in the open, so all the engineers
> > are free to merge the patches into the current public git tree after internal
> > review that tries to catch the evident issues.
> 
> Not sure, but this sounds like you do internal review and then just
> push to the public tree. That's not good, since it makes cross-driver
> collab harder, and it makes it much harder for external people to
> contribute to your driver in general. Upstream is about cross
> vendor/user/osv/whomever collaboration in the open, if you really do
> review internall I strongly urge you to do all patch submission&review
> on dri-devel. That's how all the other drivers work (well
> amd/i915/nouveau have their own separate mailing lists because we'd
> drown dri-devel), and it's the expectation. It would definitely be the
> expectation if arm display is managed in drm-misc :-)

Yes, we do some lite internal review for some very simple reasons: people are still
getting used to submitting patches to mainline so they make easily fixable mistakes
that we can weed out with the internal review; the second reason (and that applies
only when we add new functionality to the driver) is to scan for possible patent
violations. I'm pretty sure that something similar exists in most companies.

Note that this does not exclude the public mailing lists. We have received contributions
via dri-devel ML (look at the last pull request, it features one external contributor)
and there is no replacement internally for dri-devel. The malidp@foss.arm.com mailing
list exists only to allow for a quick response time from any of the contributors in
case some of us are travelling or on holiday which you don't get with direct email
addresses.

I've made that clear in private conversations and I wil re-iterate it here: Mali DP team
is mainline first and cross-driver focused. However, we are not operating as a separate
entity from the rest of ARM, so we have to obey some internal processes.

Best regards,
Liviu

> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-01-27  9:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-26 17:08 RFC: drm-misc for small drivers? Daniel Vetter
2017-01-26 17:42 ` Liviu Dudau
2017-01-26 19:12   ` Sean Paul
2017-01-26 20:48     ` Liviu Dudau
2017-01-27  6:55       ` Daniel Vetter
2017-01-27  9:44         ` Liviu Dudau [this message]
2017-01-26 19:57   ` Daniel Vetter
2017-01-26 20:54     ` Liviu Dudau
2017-01-30  9:30     ` Gerd Hoffmann
2017-01-30  9:49       ` Daniel Vetter
2017-01-30  9:53         ` Tomi Sarvela
2017-01-26 19:11 ` Sean Paul
2017-01-27  6:32   ` Daniel Vetter
2017-01-27 16:30     ` Sean Paul
2017-01-26 19:48 ` Eric Anholt
2017-01-27  6:52   ` Daniel Vetter
2017-01-27 16:50     ` Alex Deucher
2017-01-30  8:24       ` Daniel Vetter
2017-01-30 10:15 ` Boris Brezillon
2017-01-31  7:48   ` Daniel Vetter

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=20170127094417.GD3140@e110455-lin.cambridge.arm.com \
    --to=liviu.dudau@arm.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox