On 14 Oct, Ingo Molnar wrote: > * Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> wrote: >> How well do "git am", "quilt import" and friends cope with ever >> changing directories? [Perhaps the -p option does the trick. And git-am could be done on a temporary branch from before the move of the files.] > 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. Even if author and committer both work with git, they often use e-mail to transfer patches. > If it's not in tree then it will adopt to whatever layout there is once > it gets into Greg's tree. Many "good" drivers will start as "ugly" or "bad" ones. >> 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 Does this information matter much? What's more interesting is whether development activity will _lead_ to a driver being moved from bad or ugly to good. -- Stefan Richter -=====-==--= =-=- -===- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
