outreachy

outreachy

[Julia Lawall]

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?

thanks,
julia

outreachy

[Julia Lawall]

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?

thanks,
julia

Re: outreachy

[Scott Branden]

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.
>
> thanks,
> julia
>

Thanks,
Scott

outreachy

[Scott Branden]

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.
>
> thanks,
> julia
>

Thanks,
Scott

Re: outreachy

[Stephen Warren]

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. I don't know what process 
is in place, but I would suggest:

1) Senders send everything to the outreachy list, where they are 
reviewed for basic issues, like learning to use git send-email, learning 
checkpatch, etc. In this case, only send the patch to the outreachy 
mailing list and nowhere else.

2) Once a patch has passed review there, then send the patch to the 
regular kernel mailing list just like any other patch; follow the output 
of get_maintainers.pl.

We have something like (1) inside NVIDIA for new contributors and 
pre-upstreaming IP review. It helps all the newcomers, but without 
requiring anyone involved in (2) to change behaviour.

The process I suggest is very much inline with the typically suggested 
"asking questions" process: (1) read docs yourself (2) ask local 
contacts for help, (3) start asking wider audiences for help.

outreachy

[Stephen Warren]

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. I don't know what process 
is in place, but I would suggest:

1) Senders send everything to the outreachy list, where they are 
reviewed for basic issues, like learning to use git send-email, learning 
checkpatch, etc. In this case, only send the patch to the outreachy 
mailing list and nowhere else.

2) Once a patch has passed review there, then send the patch to the 
regular kernel mailing list just like any other patch; follow the output 
of get_maintainers.pl.

We have something like (1) inside NVIDIA for new contributors and 
pre-upstreaming IP review. It helps all the newcomers, but without 
requiring anyone involved in (2) to change behaviour.

The process I suggest is very much inline with the typically suggested 
"asking questions" process: (1) read docs yourself (2) ask local 
contacts for help, (3) start asking wider audiences for help.

Re: outreachy

[Greg KH]

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

outreachy

[Greg KH]

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

Re: outreachy

[Florian Fainelli]

On 03/09/2017 01:20 PM, 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.

Keep in mind that most people on this CC list are getting these patches
because of the bcm283* regular expression, and maybe that's what needs
fixing here in the first place.

Incidentally, Stephen did send a patch to get him removed from the
MAINTAINERS entry for Raspberry Pi stuff, so I guess, problem solved for
him. We still have a ton of people from Broadcom who are going to
receive these emails, with mild interest in staging patches.

> 
> 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.

That is absolutely true, but the thing is that we really got a big spike
of patch submissions lately, and that was totally not accepted. I am not
asking for a "heads-up" email telling people that they are going to
receive more traffic than usual (because that would be too much over
head), but if there was an internal review first on the outreachy
mailing-list and second a proper submission which is going to pass your
acceptance criteria, we would be de facto reducing the amount of emails
that we received.

The outreachy list obviously has people like you and Julia who are
willing to help and provide feedback, so I really don't see what's the
problem in setting up a two tier review here, it does not change
anything for you, but it does change a lot for us.
-- 
Florian

outreachy

[Florian Fainelli]

On 03/09/2017 01:20 PM, 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.

Keep in mind that most people on this CC list are getting these patches
because of the bcm283* regular expression, and maybe that's what needs
fixing here in the first place.

Incidentally, Stephen did send a patch to get him removed from the
MAINTAINERS entry for Raspberry Pi stuff, so I guess, problem solved for
him. We still have a ton of people from Broadcom who are going to
receive these emails, with mild interest in staging patches.

> 
> 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.

That is absolutely true, but the thing is that we really got a big spike
of patch submissions lately, and that was totally not accepted. I am not
asking for a "heads-up" email telling people that they are going to
receive more traffic than usual (because that would be too much over
head), but if there was an internal review first on the outreachy
mailing-list and second a proper submission which is going to pass your
acceptance criteria, we would be de facto reducing the amount of emails
that we received.

The outreachy list obviously has people like you and Julia who are
willing to help and provide feedback, so I really don't see what's the
problem in setting up a two tier review here, it does not change
anything for you, but it does change a lot for us.
-- 
Florian

Re: outreachy

[Greg KH]

On Thu, Mar 09, 2017 at 02:15:21PM -0800, Florian Fainelli wrote:
> On 03/09/2017 01:20 PM, 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.
> 
> Keep in mind that most people on this CC list are getting these patches
> because of the bcm283* regular expression, and maybe that's what needs
> fixing here in the first place.

Yes, I suggest the someone fixes that if they do not wish to get these
types of emails.  Having a regex like that in MAINTAINERS is very crazy,
from another thread I don't think it's really doing what you all want it
to do (meaning it's hitting a lot more files than expected.)

> > 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.
> 
> That is absolutely true, but the thing is that we really got a big spike
> of patch submissions lately, and that was totally not accepted. I am not
> asking for a "heads-up" email telling people that they are going to
> receive more traffic than usual (because that would be too much over
> head), but if there was an internal review first on the outreachy
> mailing-list and second a proper submission which is going to pass your
> acceptance criteria, we would be de facto reducing the amount of emails
> that we received.
> 
> The outreachy list obviously has people like you and Julia who are
> willing to help and provide feedback, so I really don't see what's the
> problem in setting up a two tier review here, it does not change
> anything for you, but it does change a lot for us.

Again, even if outreachy isn't happening, you are still going to be
getting these types of patches from all of the "normal" people that send
staging cleanup patches.  So it's not going to buy you all that much of
a reprieve.

So please send in a MAINTAINERS patch if you don't wish to get these
kinds of patches.  Or, again, just spend a day and send me cleanup
patches to keep anyone else from needing to send in basic checkpatch
fixes for this code.

thanks,

greg k-h

outreachy

[Greg KH]

On Thu, Mar 09, 2017 at 02:15:21PM -0800, Florian Fainelli wrote:
> On 03/09/2017 01:20 PM, 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.
> 
> Keep in mind that most people on this CC list are getting these patches
> because of the bcm283* regular expression, and maybe that's what needs
> fixing here in the first place.

Yes, I suggest the someone fixes that if they do not wish to get these
types of emails.  Having a regex like that in MAINTAINERS is very crazy,
from another thread I don't think it's really doing what you all want it
to do (meaning it's hitting a lot more files than expected.)

> > 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.
> 
> That is absolutely true, but the thing is that we really got a big spike
> of patch submissions lately, and that was totally not accepted. I am not
> asking for a "heads-up" email telling people that they are going to
> receive more traffic than usual (because that would be too much over
> head), but if there was an internal review first on the outreachy
> mailing-list and second a proper submission which is going to pass your
> acceptance criteria, we would be de facto reducing the amount of emails
> that we received.
> 
> The outreachy list obviously has people like you and Julia who are
> willing to help and provide feedback, so I really don't see what's the
> problem in setting up a two tier review here, it does not change
> anything for you, but it does change a lot for us.

Again, even if outreachy isn't happening, you are still going to be
getting these types of patches from all of the "normal" people that send
staging cleanup patches.  So it's not going to buy you all that much of
a reprieve.

So please send in a MAINTAINERS patch if you don't wish to get these
kinds of patches.  Or, again, just spend a day and send me cleanup
patches to keep anyone else from needing to send in basic checkpatch
fixes for this code.

thanks,

greg k-h

Re: outreachy

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

Hi!

> 
> 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.

Could we get these trivial patches off the lkml? Yes, lkml already has
a lot of traffic, but no, this is not useful :-(.
									
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

outreachy

[Pavel Machek]

Hi!

> 
> 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.

Could we get these trivial patches off the lkml? Yes, lkml already has
a lot of traffic, but no, this is not useful :-(.
									
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170317/249c043f/attachment-0001.sig>

Re: outreachy

[Julia Lawall]

On Fri, 17 Mar 2017, Pavel Machek wrote:

> Hi!
>
> >
> > 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.
>
> Could we get these trivial patches off the lkml? Yes, lkml already has
> a lot of traffic, but no, this is not useful :-(.

The outreachy instructions say to use the -nol argument to
get_maintainers, which would prevent them from being sent to any mailing
list.  However others thought that all patches should be sent to mailing
lists, and so I haven't enforced anything for people who have omitted
-nol.  However I have tried to remove bcm maintainers from CC lists on
replies and reminded people not to send you patches,

julia


>
> 									Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

outreachy

[Julia Lawall]

On Fri, 17 Mar 2017, Pavel Machek wrote:

> Hi!
>
> >
> > 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.
>
> Could we get these trivial patches off the lkml? Yes, lkml already has
> a lot of traffic, but no, this is not useful :-(.

The outreachy instructions say to use the -nol argument to
get_maintainers, which would prevent them from being sent to any mailing
list.  However others thought that all patches should be sent to mailing
lists, and so I haven't enforced anything for people who have omitted
-nol.  However I have tried to remove bcm maintainers from CC lists on
replies and reminded people not to send you patches,

julia


>
> 									Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

Re: outreachy

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]

Hi!

> > > 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.
> >
> > Could we get these trivial patches off the lkml? Yes, lkml already has
> > a lot of traffic, but no, this is not useful :-(.
> 
> The outreachy instructions say to use the -nol argument to
> get_maintainers, which would prevent them from being sent to any mailing
> list.  However others thought that all patches should be sent to mailing
> lists, and so I haven't enforced anything for people who have omitted
> -nol.  However I have tried to remove bcm maintainers from CC lists on
> replies and reminded people not to send you patches,

Wonderful :-(.

Can we at least make  those people put the word "outreachy" in the
subject so the emails are easier to delete?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

outreachy

[Pavel Machek]

Hi!

> > > 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.
> >
> > Could we get these trivial patches off the lkml? Yes, lkml already has
> > a lot of traffic, but no, this is not useful :-(.
> 
> The outreachy instructions say to use the -nol argument to
> get_maintainers, which would prevent them from being sent to any mailing
> list.  However others thought that all patches should be sent to mailing
> lists, and so I haven't enforced anything for people who have omitted
> -nol.  However I have tried to remove bcm maintainers from CC lists on
> replies and reminded people not to send you patches,

Wonderful :-(.

Can we at least make  those people put the word "outreachy" in the
subject so the emails are easier to delete?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170320/ef0cfae7/attachment.sig>

Re: outreachy

[Greg KH]

On Mon, Mar 20, 2017 at 11:20:32AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > 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.
> > >
> > > Could we get these trivial patches off the lkml? Yes, lkml already has
> > > a lot of traffic, but no, this is not useful :-(.
> > 
> > The outreachy instructions say to use the -nol argument to
> > get_maintainers, which would prevent them from being sent to any mailing
> > list.  However others thought that all patches should be sent to mailing
> > lists, and so I haven't enforced anything for people who have omitted
> > -nol.  However I have tried to remove bcm maintainers from CC lists on
> > replies and reminded people not to send you patches,
> 
> Wonderful :-(.
> 
> Can we at least make  those people put the word "outreachy" in the
> subject so the emails are easier to delete?

It's easy for you to filter away as-is if you want to to by just looking
at the cc: list for outreachy right now, don't make a new step for
people to jump through because you don't want to be bothered.  You only
have 10 more days of it if you want to just ignore any patch until
then...

greg k-h

outreachy

[Greg KH]

On Mon, Mar 20, 2017 at 11:20:32AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > 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.
> > >
> > > Could we get these trivial patches off the lkml? Yes, lkml already has
> > > a lot of traffic, but no, this is not useful :-(.
> > 
> > The outreachy instructions say to use the -nol argument to
> > get_maintainers, which would prevent them from being sent to any mailing
> > list.  However others thought that all patches should be sent to mailing
> > lists, and so I haven't enforced anything for people who have omitted
> > -nol.  However I have tried to remove bcm maintainers from CC lists on
> > replies and reminded people not to send you patches,
> 
> Wonderful :-(.
> 
> Can we at least make  those people put the word "outreachy" in the
> subject so the emails are easier to delete?

It's easy for you to filter away as-is if you want to to by just looking
at the cc: list for outreachy right now, don't make a new step for
people to jump through because you don't want to be bothered.  You only
have 10 more days of it if you want to just ignore any patch until
then...

greg k-h

Re: outreachy

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]

On Mon 2017-03-20 11:30:08, Greg KH wrote:
> On Mon, Mar 20, 2017 at 11:20:32AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > > 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.
> > > >
> > > > Could we get these trivial patches off the lkml? Yes, lkml already has
> > > > a lot of traffic, but no, this is not useful :-(.
> > > 
> > > The outreachy instructions say to use the -nol argument to
> > > get_maintainers, which would prevent them from being sent to any mailing
> > > list.  However others thought that all patches should be sent to mailing
> > > lists, and so I haven't enforced anything for people who have omitted
> > > -nol.  However I have tried to remove bcm maintainers from CC lists on
> > > replies and reminded people not to send you patches,
> > 
> > Wonderful :-(.
> > 
> > Can we at least make  those people put the word "outreachy" in the
> > subject so the emails are easier to delete?
> 
> It's easy for you to filter away as-is if you want to to by just looking
> at the cc: list for outreachy right now, don't make a new step for
> people to jump through because you don't want to be bothered.  You only
> have 10 more days of it if you want to just ignore any patch until
> then...

10 more days... I can survive 10 more days. I was afraid we would be
stuck with it "forever".
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

outreachy

[Pavel Machek]

On Mon 2017-03-20 11:30:08, Greg KH wrote:
> On Mon, Mar 20, 2017 at 11:20:32AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > > 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.
> > > >
> > > > Could we get these trivial patches off the lkml? Yes, lkml already has
> > > > a lot of traffic, but no, this is not useful :-(.
> > > 
> > > The outreachy instructions say to use the -nol argument to
> > > get_maintainers, which would prevent them from being sent to any mailing
> > > list.  However others thought that all patches should be sent to mailing
> > > lists, and so I haven't enforced anything for people who have omitted
> > > -nol.  However I have tried to remove bcm maintainers from CC lists on
> > > replies and reminded people not to send you patches,
> > 
> > Wonderful :-(.
> > 
> > Can we at least make  those people put the word "outreachy" in the
> > subject so the emails are easier to delete?
> 
> It's easy for you to filter away as-is if you want to to by just looking
> at the cc: list for outreachy right now, don't make a new step for
> people to jump through because you don't want to be bothered.  You only
> have 10 more days of it if you want to just ignore any patch until
> then...

10 more days... I can survive 10 more days. I was afraid we would be
stuck with it "forever".
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170320/651d0dcc/attachment.sig>

Re: outreachy/moving a driver out of staging

[Michael Zoran]

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?

outreachy/moving a driver out of staging

[Michael Zoran]

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?

Re: outreachy/moving a driver out of staging

[Russell King - ARM Linux]

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.

outreachy/moving a driver out of staging

[Russell King - ARM Linux]

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.

Re: outreachy/moving a driver out of staging

[Michael Zoran]

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?

outreachy/moving a driver out of staging

[Michael Zoran]

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?

Outreachy

[Menna Mahmoud]

Hi Mentors,


I am Menna, Outreachy applicant and I work on my clean-up patches.

Is it Okay to work on this error reported by checkpatch script?


drivers/staging/iio/frequency/ad9832.c
--------------------------------------
ERROR: Use 4 digit octal (0777) not decimal permissions
#256: FILE: drivers/staging/iio/frequency/ad9832.c:256:
+static IIO_DEV_ATTR_FREQ(0, 1, 0200, NULL, ad9832_write, AD9832_FREQ1HM);
ERROR: Use 4 digit octal (0777) not decimal permissions
#257: FILE: drivers/staging/iio/frequency/ad9832.c:257:
+static IIO_DEV_ATTR_FREQSYMBOL(0, 0200, NULL, ad9832_write, 
AD9832_FREQ_SYM);
ERROR: Use 4 digit octal (0777) not decimal permissions
#260: FILE: drivers/staging/iio/frequency/ad9832.c:260:
+static IIO_DEV_ATTR_PHASE(0, 0, 0200, NULL, ad9832_write, AD9832_PHASE0H);
ERROR: Use 4 digit octal (0777) not decimal permissions
#261: FILE: drivers/staging/iio/frequency/ad9832.c:261:
+static IIO_DEV_ATTR_PHASE(0, 1, 0200, NULL, ad9832_write, AD9832_PHASE1H);
ERROR: Use 4 digit octal (0777) not decimal permissions
#262: FILE: drivers/staging/iio/frequency/ad9832.c:262:
+static IIO_DEV_ATTR_PHASE(0, 2, 0200, NULL, ad9832_write, AD9832_PHASE2H);
ERROR: Use 4 digit octal (0777) not decimal permissions
#263: FILE: drivers/staging/iio/frequency/ad9832.c:263:
+static IIO_DEV_ATTR_PHASE(0, 3, 0200, NULL, ad9832_write, AD9832_PHASE3H);
ERROR: Use 4 digit octal (0777) not decimal permissions
#264: FILE: drivers/staging/iio/frequency/ad9832.c:264:
+static IIO_DEV_ATTR_PHASESYMBOL(0, 0200, NULL,
+                ad9832_write, AD9832_PHASE_SYM);
ERROR: Use 4 digit octal (0777) not decimal permissions
#268: FILE: drivers/staging/iio/frequency/ad9832.c:268:
+static IIO_DEV_ATTR_PINCONTROL_EN(0, 0200, NULL,
+                ad9832_write, AD9832_PINCTRL_EN);
ERROR: Use 4 digit octal (0777) not decimal permissions
#270: FILE: drivers/staging/iio/frequency/ad9832.c:270:
+static IIO_DEV_ATTR_OUT_ENABLE(0, 0200, NULL,
+                ad9832_write, AD9832_OUTPUT_EN);
total: 9 errors, 0 warnings, 0 checks, 462 lines checked



Thanks in advance,

Menna

Re: Outreachy

[Dan Carpenter]

On Wed, Mar 15, 2023 at 03:17:28PM +0200, Menna Mahmoud wrote:
> Hi Mentors,
> 
> 
> I am Menna, Outreachy applicant and I work on my clean-up patches.
> 
> Is it Okay to work on this error reported by checkpatch script?
> 
> 
> drivers/staging/iio/frequency/ad9832.c
> --------------------------------------
> ERROR: Use 4 digit octal (0777) not decimal permissions
> #256: FILE: drivers/staging/iio/frequency/ad9832.c:256:
> +static IIO_DEV_ATTR_FREQ(0, 1, 0200, NULL, ad9832_write, AD9832_FREQ1HM);

What???  Is it complaining about the 0200?  That is octal.  Why is
checkpatch complaining about this?  Am I wrong?  Maybe I am misreading.

I could investigate, but I am leaving that task to you.  It may be that
checkpatch has a problem and you can fix that instead.

regards,
dan carpenter

Re: Outreachy

[Randy Dunlap]

On 3/15/23 07:03, Dan Carpenter wrote:
> On Wed, Mar 15, 2023 at 03:17:28PM +0200, Menna Mahmoud wrote:
>> Hi Mentors,
>>
>>
>> I am Menna, Outreachy applicant and I work on my clean-up patches.
>>
>> Is it Okay to work on this error reported by checkpatch script?
>>
>>
>> drivers/staging/iio/frequency/ad9832.c
>> --------------------------------------
>> ERROR: Use 4 digit octal (0777) not decimal permissions
>> #256: FILE: drivers/staging/iio/frequency/ad9832.c:256:
>> +static IIO_DEV_ATTR_FREQ(0, 1, 0200, NULL, ad9832_write, AD9832_FREQ1HM);
> 
> What???  Is it complaining about the 0200?  That is octal.  Why is
> checkpatch complaining about this?  Am I wrong?  Maybe I am misreading.
> 
> I could investigate, but I am leaving that task to you.  It may be that
> checkpatch has a problem and you can fix that instead.
> 

Yes, checkpatch seems to be confused here.

-- 
~Randy

Re: Outreachy

[Lars-Peter Clausen]

On 3/15/23 12:24, Randy Dunlap wrote:
>
> On 3/15/23 07:03, Dan Carpenter wrote:
>> On Wed, Mar 15, 2023 at 03:17:28PM +0200, Menna Mahmoud wrote:
>>> Hi Mentors,
>>>
>>>
>>> I am Menna, Outreachy applicant and I work on my clean-up patches.
>>>
>>> Is it Okay to work on this error reported by checkpatch script?
>>>
>>>
>>> drivers/staging/iio/frequency/ad9832.c
>>> --------------------------------------
>>> ERROR: Use 4 digit octal (0777) not decimal permissions
>>> #256: FILE: drivers/staging/iio/frequency/ad9832.c:256:
>>> +static IIO_DEV_ATTR_FREQ(0, 1, 0200, NULL, ad9832_write, AD9832_FREQ1HM);
>> What???  Is it complaining about the 0200?  That is octal.  Why is
>> checkpatch complaining about this?  Am I wrong?  Maybe I am misreading.
>>
>> I could investigate, but I am leaving that task to you.  It may be that
>> checkpatch has a problem and you can fix that instead.
>>
> Yes, checkpatch seems to be confused here.
It seems to make an assumption that everything starting with 
IIO_DEV_ATTR_ has the mode field at the same position. Which is not the 
case.

https://github.com/torvalds/linux/blob/master/scripts/checkpatch.pl#L798

Still a good target to get this fixed as part of a outreachy task.

Re: Outreachy

[Menna Mahmoud]

On ١٥‏/٣‏/٢٠٢٣ ٢٢:٠٩, Lars-Peter Clausen wrote:
> On 3/15/23 12:24, Randy Dunlap wrote:
>>
>> On 3/15/23 07:03, Dan Carpenter wrote:
>>> On Wed, Mar 15, 2023 at 03:17:28PM +0200, Menna Mahmoud wrote:
>>>> Hi Mentors,
>>>>
>>>>
>>>> I am Menna, Outreachy applicant and I work on my clean-up patches.
>>>>
>>>> Is it Okay to work on this error reported by checkpatch script?
>>>>
>>>>
>>>> drivers/staging/iio/frequency/ad9832.c
>>>> --------------------------------------
>>>> ERROR: Use 4 digit octal (0777) not decimal permissions
>>>> #256: FILE: drivers/staging/iio/frequency/ad9832.c:256:
>>>> +static IIO_DEV_ATTR_FREQ(0, 1, 0200, NULL, ad9832_write, 
>>>> AD9832_FREQ1HM);
>>> What???  Is it complaining about the 0200?  That is octal. Why is
>>> checkpatch complaining about this?  Am I wrong?  Maybe I am misreading.
>>>
>>> I could investigate, but I am leaving that task to you.  It may be that
>>> checkpatch has a problem and you can fix that instead.
>>>
>> Yes, checkpatch seems to be confused here.
> It seems to make an assumption that everything starting with 
> IIO_DEV_ATTR_ has the mode field at the same position. Which is not 
> the case.
>
> https://github.com/torvalds/linux/blob/master/scripts/checkpatch.pl#L798
>
> Still a good target to get this fixed as part of a outreachy task.


I see, Thanks Randy and Lars-Peter for your help I will try check this.

Outreachy

[Menna Mahmoud]

Hi there am Menna an Outreachy applicant,right now am working on my first patch. happy to be part of this community.

Thanks,

Menna

Re: Outreachy

[Alison Schofield]

On Tue, Mar 07, 2023 at 02:25:29PM +0200, Menna Mahmoud wrote:
> Hi there am Menna an Outreachy applicant,right now am working on my first patch. happy to be part of this community.
> 
> Thanks,
> 
> Menna
> 
>
Hi Menna,

Welcome to the Linux Kernel Community!

Alison

Outreachy

[Zodwa Phakathi]

Good day,

I hope this email finds you well. My name is Zodwa Phakathi from South
Africa. I am one of the Outreachy applicants. I would like to
participate in the following project. The project name is  Accelerate
rename detection and the "range-diff" command in Git. I would like to
know if you guys have any suggestions on which microproject I can
currently work on. The microproject I would like  to work on is
Modernize a test script, Is it still available to work on it.


kind regards,
Zodwa.

Re: Outreachy

[Emily Shaffer]

On Sun, Oct 06, 2019 at 01:32:54AM +0530, Rajni Jha wrote:
> Hello!
Welcome! Thank you for introducing yourself and please don't hesitate to
ask any questions you may have.

> 
> I am an outreachy applicant and I am looking forward to working with git
> for my outreachy internship.

Hope this will help you get started. The community discussed the list of
microprojects for applicants to try in this mailing list thread:
https://public-inbox.org/git/20190916184208.GB17913@google.com/
I don't think you need to wade through the replies on that thread to
determine whether the microproject you are interested in is available,
although you're certainly welcome to. You can also ask me if you see a
microproject you are interested in and I will be happy to help
summarize it and point you in the right direction :)

It is also probably a good idea for you to search that mailing list
archive for "[Outreachy]" so you can see what Outreachy interns have
done in the past and try to emulate how they submitted finished
microprojects. I also recommend that you read through
https://git-scm.com/docs/MyFirstContribution.html#ready-to-share to
learn how to share your code with us when you have finished.

 - Emily

Re: Outreachy

[Johannes Schindelin]

Hi Emily,

On Mon, 7 Oct 2019, Emily Shaffer wrote:

> The community discussed the list of microprojects for applicants to
> try in this mailing list thread:
> https://public-inbox.org/git/20190916184208.GB17913@google.com/

An email thread is immutable, so maybe you want to transfer at least
some of the projects to https://github.com/gitgitgadget/git/issues or to
https://crbug.com/git?

(I find the former easier to use, in particular because it makes
labeling more obvious, "good first issue" being the one to look for, but
I do understand that different people have different preferences.)

Ciao,
Johannes

outreachy

[Julia Lawall]

Hello,

We are around the halfway mark of the application period.

So that I can get an overview of the current interests of the applicants,
could you send me a list of your current first and second project choices?
It's OK to change your mind later, but I would like to know what everyone
is thinking about now.

Please do this even if you don't yet have many accepted patches.

thanks,
julia

Re: outreachy

[Rehas Sachdeva]

[-- Attachment #1.1: Type: text/plain, Size: 596 bytes --]

Hi Julia,

My first two choices are:

1. radix tree __alloc_fd.
2. Coccinelle.

Thanks
Rehas

On Saturday, October 1, 2016 at 2:10:12 AM UTC+5:30, Julia Lawall wrote:
>
> Hello, 
>
> We are around the halfway mark of the application period. 
>
> So that I can get an overview of the current interests of the applicants, 
> could you send me a list of your current first and second project choices? 
> It's OK to change your mind later, but I would like to know what everyone 
> is thinking about now. 
>
> Please do this even if you don't yet have many accepted patches. 
>
> thanks, 
> julia 
>

[-- Attachment #1.2: Type: text/html, Size: 879 bytes --]

Re: outreachy

[keila novo]

[-- Attachment #1.1: Type: text/plain, Size: 624 bytes --]



El viernes, 30 de septiembre de 2016, 22:40:12 (UTC+2), Julia Lawall 
escribió:
>
> Hello, 
>
> We are around the halfway mark of the application period. 
>
> So that I can get an overview of the current interests of the applicants, 
> could you send me a list of your current first and second project choices? 
> It's OK to change your mind later, but I would like to know what everyone 
> is thinking about now. 
>
> Please do this even if you don't yet have many accepted patches. 
>
> thanks, 
> julia 
>


 Hi Julia,

My first two choices are:
1. Coccinelle
2.IIO driver.

Thanks,
Keila

[-- Attachment #1.2: Type: text/html, Size: 905 bytes --]

Re: outreachy

[Bhumika Goyal]

[-- Attachment #1.1: Type: text/plain, Size: 594 bytes --]

Hey Julia,
My top two choices are:
1. Coccinelle
2. radix tree __alloc_fd

Thanks,
Bhumika

On Saturday, October 1, 2016 at 2:10:12 AM UTC+5:30, Julia Lawall wrote:
>
> Hello, 
>
> We are around the halfway mark of the application period. 
>
> So that I can get an overview of the current interests of the applicants, 
> could you send me a list of your current first and second project choices? 
> It's OK to change your mind later, but I would like to know what everyone 
> is thinking about now. 
>
> Please do this even if you don't yet have many accepted patches. 
>
> thanks, 
> julia 
>

[-- Attachment #1.2: Type: text/html, Size: 792 bytes --]

Re: outreachy

[Namrata A Shettar]

[-- Attachment #1.1: Type: text/plain, Size: 205 bytes --]


Hi,
    My first two choices  are :
 
    1) nftables ( Mentor : Pablo Neira Ayuso )

    2) Coccinelle ( Mentor : Julia Lawall )

    I haven't completely ruled out the other projects!

Thanks!

namrata

[-- Attachment #1.2: Type: text/html, Size: 283 bytes --]

Re: outreachy

[Georgiana Chelu]

[-- Attachment #1.1: Type: text/plain, Size: 540 bytes --]

Hello,

My choice is IIO driver.

Georgiana
 
On Friday, 30 September 2016 23:40:12 UTC+3, Julia Lawall wrote:
>
> Hello, 
>
> We are around the halfway mark of the application period. 
>
> So that I can get an overview of the current interests of the applicants, 
> could you send me a list of your current first and second project choices? 
> It's OK to change your mind later, but I would like to know what everyone 
> is thinking about now. 
>
> Please do this even if you don't yet have many accepted patches. 
>
> thanks, 
> julia 
>

[-- Attachment #1.2: Type: text/html, Size: 747 bytes --]

Re: Outreachy

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 3049 bytes --]

Hi Renata

adding Jesus and xen-devel

> On 18 Mar 2016, at 03:37, renata gegaj <gegajrenata@gmail.com> wrote:
> 
> Hello Lars,
> 
> I am Renata Gegaj a student from Kosovo.  I study computer science and engineering. This is my first time participating in the Outreachy program, it is also the first time I contribute to an open source project. I have some basics skills in Java, SQL and HTML5 and I am interested in the Xen Code Review Dashboard. 
> Is there a spot where I could contribute?
> 
> Thank you in advance.
> 
> Kindly,
> Renata.


Before thinking about contributing, you should first set up a work environment and play with it. This should be doable in a few hours. So how about, you perform the following steps and then get back to us for a little task.

@Jesus: The application deadline is on Tue next week. Maybe we can outline a task today. It would have to be around the code in https://github.com/dicortazar/xen-code-review-analysis/tree/master <https://github.com/dicortazar/xen-code-review-analysis/tree/master>

To get started, you will need kibana and elasticsearch - packages for these should be in any distro and can be installed via apt-get or yum mailing lists and git. The test data sets are at http://projects.bitergia.com/xen-project-dashboard/browser/data/db/ <http://projects.bitergia.com/xen-project-dashboard/browser/data/db/>, but you can also apply the scripts (but these need access to mailboxes to be downloaded to be run - I can get you access to a month or two months worth of mailboxes).

There is lots of info on getting Kibana and Elastic search going and you may want to check out
- https://www.elastic.co/guide/en/elasticsearch/reference/current/_installation.html
- https://www.elastic.co/guide/en/kibana/current/setup.html
Then
- Connect all to the test data sets
- Explore and get familiar with the tools
- Come back with some questions
The hosted prototype versions of the dashboards are at http://kibana-xen.bitergia.com <http://kibana-xen.bitergia.com/>. When you install Elasticsearch and Kibana, the pre-defined search queries and view panels won't be there by default. But you will be able to explore the raw data from the SQL test data sets. Note that they were created with MetricsGrimoire tools and the tools in https://github.com/dicortazar/xen-code-review-analysis/tree/master <https://github.com/dicortazar/xen-code-review-analysis/tree/master>. 

As one of the goals is to use Perceval to do this, you may also want to
- Get and build Perceval from https://github.com/grimoirelab/perceval
- Explore the test data set SQL structure with an appropriate tool
- Read through the Perceval man pages and do some experimentation and come back with some questions

We can then work through the questions and chose appropriate next steps: but from that point onwards we probably need Jesus input. However, time is getting tight with the application deadline being on the 22nd.

Regards
Lars
P.S.: Jesus normally hangs out on #metrics-grimoire nick jgbarah

[-- Attachment #1.2: Type: text/html, Size: 5062 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel