Re: Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-rc3)

Ingo Molnar
2009-10-14T18:37:55Z

* Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> Ingo Molnar wrote:
> > * Joe Perches <joe@perches.com> wrote:
> >
> >> On Tue, 2009-10-13 at 21:45 -0700, Greg KH wrote:
> >> > How about when it was scheduled to be removed, we put it in staging and
> >> > I'll add it to my announcements about the staging tree every release?
> >> > Unless you can think of a better way?
> >>
> >> staging/to_be_removed_unless_fixed_by/v.x.y ?
> >
> > Yes, that's a real worry. Some time ago i suggested:
> >
> > drivers/staging/good/
> > drivers/staging/bad/
> > drivers/staging/ugly/
>
> How well do "git am", "quilt import" and friends cope with ever
> changing directories?

Once a driver is in a tree it's in Git and git mv is easy. People
working with Linux better familiarize themselves with Git workflow - the
sooner the better.

If it's not in tree then it will adopt to whatever layout there is once
it gets into Greg's tree. I dont see the problem.

> How about using drivers/staging/this_driver/TODO and (or) its Kconfig
> help text to leave a note about the plans for this driver?

Well, the answer is obvious i think. Tell me, at a glance, if you see a
patch on lkml, which one is for a staging driver to be obsoleted, and
which one is the one going upstream real soon? The patches say:

+++ a/drivers/staging/foo/x.c

+++ a/drivers/staging/bar/y.c

Then tell me the same at a glance if you see patches for:

+++ a/drivers/staging/wip/x.c

+++ a/drivers/staging/bad/y.c

> The worry that these will be ignored like
> Documentation/feature-removal-schedule.txt is being ignored may apply
> to the path name based solution too, I'm afraid.

It wont be 'ignored', as it's in every patch, it's in every commit, it's
in every substantial communication about that driver.

The problem with feature-removal-schedule.txt is that it's too much out
of sight and not part of the regular patch workflow. Same goes for any
TODO file. Experience has shown that the actual _path_ were drivers end
up does matter quite a bit, to general visibility and to mindset.

That's one of the reasons why we have _half a thousand_ directories in
drivers/ to begin with. The directory namespace is very powerful, and we
use it to convey all sorts of information about the logical category a
driver is in.

Using it in drivers/staging/ instead of the current flat hierarchy would
thus be pretty natural.

Ingo