lkml.org 
[lkml]   [2009]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-rc3)

    * 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


    \
     
     \ /
      Last update: 2009-10-14 20:49    [from the cache]
    ©2003-2011 Jasper Spaans