[igt-dev] [PATCH i-g-t] doc: End transition period.

[Petri Latvala]

On Mon, Feb 11, 2019 at 11:18:39AM -0800, Rodrigo Vivi wrote:
> On Tue, Feb 05, 2019 at 02:52:48PM -0800, Antonio Argenziano wrote:
> > 
> > 
> > On 05/02/19 14:18, Rodrigo Vivi wrote:
> > > igt-dev is pretty established after a 1-year transition.
> > > 
> > > Let's end the transition and avoid confusion.
> > > 
> > > Cc: Easwar Hariharan <easwar.hariharan at intel.com>
> > > Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> > > Cc: Petri Latvala <petri.latvala at intel.com>
> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
> > > ---
> > >   CONTRIBUTING.md | 18 ------------------
> > >   autogen.sh      |  3 ---
> > >   meson.sh        |  2 --
> > >   3 files changed, 23 deletions(-)
> > > 
> > > diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
> > > index 27c8e796..c2169375 100644
> > > --- a/CONTRIBUTING.md
> > > +++ b/CONTRIBUTING.md
> > > @@ -10,24 +10,6 @@ A short list of contribution guidelines:
> > >         Development mailing list for IGT GPU Tools <igt-dev at lists.freedesktop.org>
> > > -  For a transition period patches are accepted on both the igt-dev mailing list
> > > -  and the former intel-gfx mailing list (with the appropriate patch
> > > -  subjectprefix, see below).
> > > -
> > > -  During the transition period, feel free to send patches to both lists if you
> > > -  have a need to do so, as they will get deduplicated so they only appear and
> > > -  are tested in one Patchwork instance.
> > > -
> > > -      Intel GFX discussion <intel-gfx at lists.freedesktop.org>
> > > -
> > > -  Please use --subject-prefix="PATCH i-g-t" so IGT patches are easily
> > > -  identified in the massive amount mails on intel-gfx. To ensure this is always
> > > -  done, meson.sh (and autogen.sh) will run:
> > > -
> > > -      git config format.subjectprefix "PATCH i-g-t"
> > 
> > IIRC, the agreement was that patches will still be sent to intel-gfx if they
> > affect the driver. So, keeping the prefix would still be useful.
> 
> I was thinking on a v2, but I got confused myself. What would be an igt patch
> that affects the driver vs on that doesn't affect?
> 
> I thought that igt-dev had 2 goals:
>   - detach igt fro intel and increase other contributions
>   - minimize the flow on intel-gfx


This looks correct to me.


> This is an honest attempt to understand the goals than we can write the more
> appropriated text. With the current transition text I understand that we
> wanted to avoid igt patches on intel-gfx, but if we write in a way that
> all intel related changes go to both mailing lists we might loose that objective.


And the confusion also looks correct to me. As they say, you don't
really understand $thing until you have to explain it to someone, and
writing this mail took a while...


An IGT patch that affects the driver: New tests for a new feature. Or
just new tests for more coverage on an existing feature. Fixes to a
test based on behaviour on hardware (e.g. "fuzbah format doesn't work
on gen4+, here's how I thought we could fix that"). Maybe in a
nutshell: Exercising an interface in a way that both camps (testing +
driver) have a good reason to have a say in the matter.

An IGT patch that doesn't affect the driver: Editorial changes to
patches, build system changes, bugfixes to tests in general.

Heavily generalized, IGT is a test suite not for testing the hardware,
or testing the kernel driver. It's for testing the _interface_ to the
black box that is the kernel driver. Poking the interface is easy,
just load up the docs and call away. Getting good coverage requires
knowing what goes on inside that black box, and that's what intel-gfx
is for. intel-gfx is the place that can say "you also need to test
that same thing with the cursor plane upside down on Tuesdays because
that can work differently on $platform".


-- 
Petri Latvala