* Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> wrote: > Ingo Molnar wrote: > > * Joe Perches <joe@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
