Kernel janitors website?

Kernel janitors website?

[Michal Sojka]

Hello,

we are running a university course [1] (in Czech) about working with
open source communities. We try to help students with finding tasks and
projects to work on. Do you have a web site listing the possible tasks
for students?

It used to be http://janitor.kernelnewbies.org/ but it seems to be dead.
Other pages http://kernelnewbies.org/KernelJanitors/Todo,
https://code.google.com/p/kernel-janitors/wiki/TODO seem to be outdated.

Thanks,
-Michal

[1] https://rtime.felk.cvut.cz/osp/

Re: Kernel janitors website?

[Dan Carpenter]

On Thu, Feb 14, 2013 at 07:09:44PM +0100, Michal Sojka wrote:
> Hello,
> 
> we are running a university course [1] (in Czech) about working with
> open source communities. We try to help students with finding tasks and
> projects to work on. Do you have a web site listing the possible tasks
> for students?
> 
> It used to be http://janitor.kernelnewbies.org/ but it seems to be dead.
> Other pages http://kernelnewbies.org/KernelJanitors/Todo,
> https://code.google.com/p/kernel-janitors/wiki/TODO seem to be outdated.

Most of these still apply.

There is always stuff to fix in staging.  The thing about staging
though is that fixing style issues are fairly boring for students.
Also kernel style guidelines are very involved and we tend to be
stricter about pure style fixes than we are about bug fixes.

What I sometimes do is review short fixes and find similar bugs.

git checkout v3.3

git log --oneline v3.3-rc3..v3.3 | while read hash ; do
	if ! git show $hash | diffstat -l | grep -q "\.c$" ; then
		continue
	fi
	lines=$(git show $hash | diffstat | tail -n 1 | cut -d ' ' -f 5)
	echo $lines $hash
done | sort -n | cut -d ' ' -f 2 | tee hashes

for i in $(cat hashes) ; do
	git show $i
done | less

A lot of kernel janitor patches these days are static analysis
fixes.  I'm using Smatch.  A bunch of people are doing things with
Coccinelle.  I think Peter is using clang.  I think there are many
clang warnings left though.

I think as well, that you would find more warnings on non-x86
arches.

You could try asking for ideas on lkml.  We're always interested in
ideas as well.  Describe how long you'd want a typical project to
take.

regards,
dan carpenter

Re: Kernel janitors website?

[Julia Lawall]

On Fri, 15 Feb 2013, Dan Carpenter wrote:

> On Thu, Feb 14, 2013 at 07:09:44PM +0100, Michal Sojka wrote:
> > Hello,
> > 
> > we are running a university course [1] (in Czech) about working with
> > open source communities. We try to help students with finding tasks and
> > projects to work on. Do you have a web site listing the possible tasks
> > for students?
> > 
> > It used to be http://janitor.kernelnewbies.org/ but it seems to be dead.
> > Other pages http://kernelnewbies.org/KernelJanitors/Todo,
> > https://code.google.com/p/kernel-janitors/wiki/TODO seem to be outdated.
> 
> Most of these still apply.
> 
> There is always stuff to fix in staging.  The thing about staging
> though is that fixing style issues are fairly boring for students.
> Also kernel style guidelines are very involved and we tend to be
> stricter about pure style fixes than we are about bug fixes.

Actually, I had thought that staging would be good for students,  They 
could do simple things, and not run into the problem of annoying a 
maintainer who is overwhelmed with real problems with trivial things.

The problem with staging though is that it is not so clear what files 
people are actually interested in.  Because it would be very discouraging 
for students to send patches and have them all ignored.  I had suggested 
to just use git to see which files had received the most commits recently, 
but perhaps there is a better strategy.

julia

> What I sometimes do is review short fixes and find similar bugs.
> 
> git checkout v3.3
> 
> git log --oneline v3.3-rc3..v3.3 | while read hash ; do
> 	if ! git show $hash | diffstat -l | grep -q "\.c$" ; then
> 		continue
> 	fi
> 	lines=$(git show $hash | diffstat | tail -n 1 | cut -d ' ' -f 5)
> 	echo $lines $hash
> done | sort -n | cut -d ' ' -f 2 | tee hashes
> 
> for i in $(cat hashes) ; do
> 	git show $i
> done | less
> 
> A lot of kernel janitor patches these days are static analysis
> fixes.  I'm using Smatch.  A bunch of people are doing things with
> Coccinelle.  I think Peter is using clang.  I think there are many
> clang warnings left though.
> 
> I think as well, that you would find more warnings on non-x86
> arches.
> 
> You could try asking for ideas on lkml.  We're always interested in
> ideas as well.  Describe how long you'd want a typical project to
> take.
> 
> regards,
> dan carpenter
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Kernel janitors website?

[Dan Carpenter]

On Fri, Feb 15, 2013 at 09:50:08AM +0100, Julia Lawall wrote:
> On Fri, 15 Feb 2013, Dan Carpenter wrote:
> 
> > On Thu, Feb 14, 2013 at 07:09:44PM +0100, Michal Sojka wrote:
> > > Hello,
> > > 
> > > we are running a university course [1] (in Czech) about working with
> > > open source communities. We try to help students with finding tasks and
> > > projects to work on. Do you have a web site listing the possible tasks
> > > for students?
> > > 
> > > It used to be http://janitor.kernelnewbies.org/ but it seems to be dead.
> > > Other pages http://kernelnewbies.org/KernelJanitors/Todo,
> > > https://code.google.com/p/kernel-janitors/wiki/TODO seem to be outdated.
> > 
> > Most of these still apply.
> > 
> > There is always stuff to fix in staging.  The thing about staging
> > though is that fixing style issues are fairly boring for students.
> > Also kernel style guidelines are very involved and we tend to be
> > stricter about pure style fixes than we are about bug fixes.
> 
> Actually, I had thought that staging would be good for students,  They 
> could do simple things, and not run into the problem of annoying a 
> maintainer who is overwhelmed with real problems with trivial things.
> 

I guess my thing on staging is that students shouldn't just try to
fix a checkpatch.pl warning.  checkpatch shows bad code, and the
goal would be to make the code nicer which is slightly different
from just silencing the warning.

Another thing would be if students could pair up and review each
other's patches before sending it.  Does it apply, does it compile,
does it make the code nicer?  That's we check as well.

Also staging has so many bugs which are more interesting to fix than
checkpatch warnings.

You're right that staging is probably a good place to start.  We
are responsive.  We take trivial patches.  We're newbie friendly.

If you don't receive a response it means that we are probably going
to apply the patch.  I normally review staging patches within a day
or two.  Right now the merge window for staging is closed until
3.9-rc1 is released so Greg will let patches sit in his inbox until
then.  But I think I reject more about staging patches than Greg
does so if I don't complain, it probably will go in.

> The problem with staging though is that it is not so clear what files 
> people are actually interested in.  Because it would be very discouraging 
> for students to send patches and have them all ignored.  I had suggested 
> to just use git to see which files had received the most commits recently, 
> but perhaps there is a better strategy.

Everything in staging/ is supposed to be being developed with the
goal of getting out.  The exception would the android code.

regards,
dan carpenter

Re: Kernel janitors website?

[Julia Lawall]

> Everything in staging/ is supposed to be being developed with the
> goal of getting out.  The exception would the android code.

OK, at one point, some code was put there that was on the way out, unless 
someone complained, rather than on the way in.  I think it was around the 
time of the final elimination of the big kernel lock.  But perhaps it was 
an isolated incident.  If all of the code in staging is actually of 
interest, maybe I should pay more attention to it in the future :)

julia

Re: Kernel janitors website?

[Michal Sojka]

On Fri, Feb 15 2013, Dan Carpenter wrote:
> On Thu, Feb 14, 2013 at 07:09:44PM +0100, Michal Sojka wrote:
>> Hello,
>> 
>> we are running a university course [1] (in Czech) about working with
>> open source communities. We try to help students with finding tasks and
>> projects to work on. Do you have a web site listing the possible tasks
>> for students?
>> 
>> It used to be http://janitor.kernelnewbies.org/ but it seems to be dead.
>> Other pages http://kernelnewbies.org/KernelJanitors/Todo,
>> https://code.google.com/p/kernel-janitors/wiki/TODO seem to be outdated.
>
> Most of these still apply.
>
> There is always stuff to fix in staging.  The thing about staging
> though is that fixing style issues are fairly boring for students.
> Also kernel style guidelines are very involved and we tend to be
> stricter about pure style fixes than we are about bug fixes.
>

[...]

> You could try asking for ideas on lkml.  We're always interested in
> ideas as well.  Describe how long you'd want a typical project to
> take.

Thanks Dan. The type and length of the project depends on the
capabilities of the students and this varies widely. The time frame for
the project is two months. In general we are happy for every small patch
the students are able to push upstream.

I think your answer is sufficient at this point. If a student is
interested, he can follow your suggestions himself.

Best regards,
-Michal

Re: Kernel janitors website?

[Dan Carpenter]

On Fri, Feb 15, 2013 at 10:24:09AM +0100, Julia Lawall wrote:
> > Everything in staging/ is supposed to be being developed with the
> > goal of getting out.  The exception would the android code.
> 
> OK, at one point, some code was put there that was on the way out, unless 
> someone complained, rather than on the way in.  I think it was around the 
> time of the final elimination of the big kernel lock.  But perhaps it was 
> an isolated incident.  If all of the code in staging is actually of 
> interest, maybe I should pay more attention to it in the future :)

Oh, yes.  Telephony, serial/ and tty/ were that way.  They have been
deleted now.

I think the only driver on its way out now is the one under net/.

regards,
dan carpenter

Re: Kernel janitors website?

[Dan Carpenter]

On Fri, Feb 15, 2013 at 10:39:55AM +0000, Anuz Pratap Singh Tomar wrote:
> On Fri, Feb 15, 2013 at 10:14 AM, Dan Carpenter <dan.carpenter@oracle.com>wrote:
> 
> > On Fri, Feb 15, 2013 at 10:24:09AM +0100, Julia Lawall wrote:
> > > > Everything in staging/ is supposed to be being developed with the
> > > > goal of getting out.  The exception would the android code.
> > >
> > > OK, at one point, some code was put there that was on the way out, unless
> > > someone complained, rather than on the way in.  I think it was around the
> > > time of the final elimination of the big kernel lock.  But perhaps it was
> > > an isolated incident.  If all of the code in staging is actually of
> > > interest, maybe I should pay more attention to it in the future :)
> >
> > Oh, yes.  Telephony, serial/ and tty/ were that way.  They have been
> > deleted now.
> >
> > I think the only driver on its way out now is the one under net/.
> >
> > Is there a way to find out what all bugs exists for staging? I did search
> on bugzilla.kernel.org for keyword "staging" but the bug list seemed to be
> bit outdated or bugs fixed etc. Any other place to look for staging bugs?

Run smatch against drivers/staging/csr:

for i in $(find drivers/staging/csr -name \*.c) ; do
	~/path/to/smatch/smatch_scripts/kchecker --spammy $i
done

No error handling for kmalloc()
Locking bugs in uf_check_inactivity()
drivers/staging/csr/unifi_sme.c:884 unifi_cfg_get_info()
	warn: check that 'cfg_ap_config.shortSlotTimeEnabled'
	doesn't leak information
drivers/staging/csr/netdev.c:1989 indicate_rx_skb() warn: variable
	dereferenced before check 'dev' (see line 1979)
drivers/staging/csr/unifi_pdu_processing.c:2707
	uf_handle_uspframes_delivery() warn: was && intended here
	instead of ||?
drivers/staging/csr/csr_wifi_hip_card_sdio.c:2411
	unifi_identify_hw() error: we previously assumed
	'card->helper' could be null (see line 2404)

regards,
dan carpenter

Re: Kernel janitors website?

[walter harms]

Am 14.02.2013 19:09, schrieb Michal Sojka:
> Hello,
> 
> we are running a university course [1] (in Czech) about working with
> open source communities. We try to help students with finding tasks and
> projects to work on. Do you have a web site listing the possible tasks
> for students?
> 
> It used to be http://janitor.kernelnewbies.org/ but it seems to be dead.
> Other pages http://kernelnewbies.org/KernelJanitors/Todo,
> https://code.google.com/p/kernel-janitors/wiki/TODO seem to be outdated.
> 
> Thanks,
> -Michal
> 
> [1] https://rtime.felk.cvut.cz/osp/
> --

hi,
it depends what skill you want. The linux kernel is a very large project
and it may be a bit hard to find a suitable small project. There are lots
of other project like xorg, busybox, glibc (and friends) that are interesting.
You can go to savannah or other hosters and look by your self for projects.
(read: bugs in linux kernel tend to be squashed very fast. It is  a very moving target)
re,
 wh

Re: Kernel janitors website?

[Michal Sojka]

On Fri, Feb 15 2013, walter harms wrote:
> hi,
> it depends what skill you want. The linux kernel is a very large project
> and it may be a bit hard to find a suitable small project. 

Sure, I know that. We want to make it easier for students to find a
project. Therefore we provide them with a list of well known projects
and their TODO lists: https://rtime.felk.cvut.cz/osp/cviceni/projekty/
(in Czech).

Thanks,
-Michal