Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Daniel Vetter <daniel.vetter@ffwll.ch>]

On Wed, Jul 27, 2016 at 5:04 AM, Vinod Koul <vinod.koul@intel.com> wrote:
> On Tue, Jul 26, 2016 at 09:45:35AM -0700, Olof Johansson wrote:
>> On Wed, Jul 20, 2016 at 5:11 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> > But I think the more interesting bits are why I decided to try this
>> > out, what I hoped would happen, what I feared might happen. And with 1
>> > year of experience, what actually happens and what I think is needed
>> > to make this work and an actual benefit over more traditional
>> > maintainer models. And of course I'd like to compare notes with other
>> > group maintainers.
>>
>> Very interested in participating here, for obvious reasons -- learning
>> from others how we can do things even better as well as sharing how
>> things are working for us, 5 years into the endeavor.
>
> Am interested in this discussion as well for very obvious reasons
>
>> One thing we're low on for arm-soc is tooling, I know the x86 guys
>> have quite a bit more than we do in this area, so ideas on what we can
>> do to make our own lives easier is valuable.
>
> Okay one of the gripes I have is that it is a bit hard to compile arm
> drivers. I regularly compile all drivers in subsystem I maintain and arm
> ones are not always straightforward. Figuring our which config to use
> for compile testing involves a bit of time, which I would like to avoid.
>
> Having said that stuff like multi_xx_defconfig has improved a bit and
> seem to be in right direction (not an expert at arm arch's) but doesn't
> seem to cover all. Right now I am manually maintaining 4 different arm
> configs to compile test all the drivers in dmaengine subsystem which
> isn't a very big subsystem. For other arch's it is one config per
> subsystem.
>
> So if you have suggestions to improve my flow, I would like to hear
> that, maybe I am doing something not right here...

Since we're rolling out the drm/i915 group maintainership to the
drm-misc tree now as another experiment we've had to solve this for
the drm subsystem somehow:
- We track one arm multiplatform and one x86 config in the
rerere-cache branch we use:

https://cgit.freedesktop.org/drm-intel/tree/?h=rerere-cache

- Developers integrate that into into their compile-test environment
to make sure nothing breaks before pushing. Atm the compile-test stuff
isn't implemented in shared tooling.

- DRM doesn't have any drivers any more which can't be covered with
these too. For new drivers we require multiplatform support, at least
for compile testing. But I guess that's not a solution for everyone :(

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch