Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1603919 > unrolled thread

Re: outreachy/moving a driver out of staging

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: outreachy/moving a driver out of staging Michael Zoran <mzoran@crowfest.net> - 2017-03-19 08:40 +0100
    Re: outreachy/moving a driver out of staging Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-19 10:20 +0100
      Re: outreachy/moving a driver out of staging Michael Zoran <mzoran@crowfest.net> - 2017-03-19 12:00 +0100

#1603919 — Re: outreachy/moving a driver out of staging

On Thu, 2017-03-09 at 22:20 +0100, Greg KH wrote:
> On Thu, Mar 09, 2017 at 01:56:49PM -0700, Stephen Warren wrote:
> > On 03/09/2017 01:51 PM, Scott Branden wrote:
> > > Hi Julia,
> > > 
> > > On 17-03-09 12:36 PM, Julia Lawall wrote:
> > > > Hello,
> > > > 
> > > > I discussed the issue of outreachy patches for bcm with Greg,
> > > > and we are
> > > > not convinced that not having the patches CCd to you is such a
> > > > good idea.
> > > > While we don't want to spam you with noise, some of the
> > > > applicants are
> > > > starting to make more significant changes that it could be
> > > > useful for you
> > > > to be aware of.
> > > > 
> > > > Could we try a compromise where you are not CCd on whitespace
> > > > patches,
> > > > but
> > > > you are CCd on patches that actually modify the code?
> > > 
> > > All I'm asking is you work through your outreachy patches
> > > internal first
> > > to get rid of the most basic mistakes and email traffic it is
> > > geerating.
> > >  Once that learning process is through then they can be sent out
> > > like
> > > any other patches to the kernel mailing lists and maintainers.
> > 
> > +1 from me too; I find these patches rather high volume and had to
> > add a
> > filter to keep them out of my primary inbox.
> 
> Hah!  That's the joy of being a maintainer of a driver in
> staging.  Even
> if you filter out outreachy, you are going to get a lot of "basic
> mistakes" and other type patches cc:ed to you.
> 
> I strongly suggest, that if you all don't like this type of stuff,
> either:
> 	- work to get the code out of staging as soon as possible (i.e.
> 	  send me coding style fixes for everything right now, and then
> 	  fix up the rest of the stuff.)
> 	- take yourself off the maintainer list for this code.
> 
> It's your choice, outreachy right now is a lot of patches, but again,
> it's not going to keep you from getting the "basic" stuff sent to you
> in ways that is totally wrong.
> 
> thanks,
> 
> greg k-h
> 

Hi Greg,

I just noticed this e-mail.  What exactly is the requirement to get a
driver or subsystem out of staging?

I can image a day when vc04_services or VideoCore gets moved out of
staging at some point. What exactly would it take to make something
like that happen?

[toc] | [next] | [standalone]

#1603925

On Sun, Mar 19, 2017 at 12:37:47AM -0700, Michael Zoran wrote:
> I just noticed this e-mail.  What exactly is the requirement to get a
> driver or subsystem out of staging?

This is why each driver in staging is supposed to have a TODO file
listing each point that needs to be addressed, and when each point
is addressed, the TODO file should be updated.  The TODO file tells
people what the remaining faults are with the driver.

I see that there's a todo file here:

drivers/staging/vc04_services/interface/vchi/TODO

and the very first thing I looked at was:

  - Figure out an alternative to the dmac_map_area() hack.

$ grep -r dmac_map_area drivers/staging/vc04_services/interface/vchi
drivers/staging/vc04_services/interface/vchi/TODO:  - Figure out an alternative
to the dmac_map_area() hack.

So that one looks like it's resolved, so the TODO file is out of date.
The first step, therefore, is to get the TODO files updated with the
work that has been done, so it's possible to know what work remains.

I notice also that drivers/staging/vc04_services/interface/vchiq_arm
does not have a TODO file, so that needs reviewing and a TODO file
generated.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1603947

On Sun, 2017-03-19 at 09:15 +0000, Russell King - ARM Linux wrote:
> On Sun, Mar 19, 2017 at 12:37:47AM -0700, Michael Zoran wrote:
> > I just noticed this e-mail.  What exactly is the requirement to get
> > a
> > driver or subsystem out of staging?
> 
> This is why each driver in staging is supposed to have a TODO file
> listing each point that needs to be addressed, and when each point
> is addressed, the TODO file should be updated.  The TODO file tells
> people what the remaining faults are with the driver.
> 
> I see that there's a todo file here:
> 
> drivers/staging/vc04_services/interface/vchi/TODO
> 
> and the very first thing I looked at was:
> 
>   - Figure out an alternative to the dmac_map_area() hack.
> 
> $ grep -r dmac_map_area drivers/staging/vc04_services/interface/vchi
> drivers/staging/vc04_services/interface/vchi/TODO:  - Figure out an
> alternative
> to the dmac_map_area() hack.
> 
> So that one looks like it's resolved, so the TODO file is out of
> date.
> The first step, therefore, is to get the TODO files updated with the
> work that has been done, so it's possible to know what work remains.
> 
> I notice also that drivers/staging/vc04_services/interface/vchiq_arm
> does not have a TODO file, so that needs reviewing and a TODO file
> generated.
> 

I've actually been submitting changes to the TODO files as I've been
going.  Just these days I'm not sure which tree things are being
applied to anymore.

So I'm assuming once all the TODO items are addressed, and everything
is checkpatch.pl clean it can be moved out of staging?  I would assume
an existing subsystem would need to agree to accept it into their topic
branch correct?

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web