All of lore.kernel.org
 help / color / mirror / Atom feed
* A change of approach
@ 2007-07-31 22:05 Matthew Wilcox
  2007-08-04  6:30 ` Darren Jenkins
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Matthew Wilcox @ 2007-07-31 22:05 UTC (permalink / raw)
  To: kernel-janitors


It's not that 60+ patches to use kzalloc aren't welcome.  Well,
actually, yes, it is.  They should have been one patch per subsystem --
eg all of drivers/scsi in one patch.  All of net/ in one patch.  etc.

A better approach for the janitors to take would be to claim *a driver*,
and do everything on the todo list to it (as a series of patches,
obviously).  And fix up things that aren't on the todo list too, when
you notice them.

You'll get a lot more experience this way than you will doing
more-or-less mechanical substitutions.

-- 
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: A change of approach
  2007-07-31 22:05 A change of approach Matthew Wilcox
@ 2007-08-04  6:30 ` Darren Jenkins
  2007-08-06 17:20 ` Andi Drebes
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Darren Jenkins @ 2007-08-04  6:30 UTC (permalink / raw)
  To: kernel-janitors

G'day Matthew,

On 8/1/07, Matthew Wilcox <matthew@wil.cx> wrote:
> A better approach for the janitors to take would be to claim *a driver*,
> and do everything on the todo list to it (as a series of patches,
> obviously).  And fix up things that aren't on the todo list too, when
> you notice them.


I was just wondering about finding an unmaintained driver. Should we
just look for
stuff marked as Orphan in the MAINTAINERS file or is there
another/better list/way
to find an un-maintained driver that we shuld be made aware of?


> You'll get a lot more experience this way than you will doing
> more-or-less mechanical substitutions.

It definatly sounds more fun too.


Darren J

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: A change of approach
  2007-07-31 22:05 A change of approach Matthew Wilcox
  2007-08-04  6:30 ` Darren Jenkins
@ 2007-08-06 17:20 ` Andi Drebes
  2007-08-06 22:59 ` Matthew Wilcox
  2007-08-07  7:05 ` Thomas Petazzoni
  3 siblings, 0 replies; 5+ messages in thread
From: Andi Drebes @ 2007-08-06 17:20 UTC (permalink / raw)
  To: kernel-janitors

Hi Darren,

> > A better approach for the janitors to take would be to claim *a driver*,
> > and do everything on the todo list to it (as a series of patches,
> > obviously).  And fix up things that aren't on the todo list too, when
> > you notice them.
> 
> I was just wondering about finding an unmaintained driver. Should we
> just look for
> stuff marked as Orphan in the MAINTAINERS file or is there
> another/better list/way
> to find an un-maintained driver that we shuld be made aware of?

I don't think that the driver definitely has to be unmaintained in order to be 
chosen by a kernel janitor. If you pick a driver that is currently 
maintained, you could do the janitorial work and send a series of patches to 
the maintainer and to the list. I think a maintainer would appreciate this 
because somebody does the "dirty work".

	Andi

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: A change of approach
  2007-07-31 22:05 A change of approach Matthew Wilcox
  2007-08-04  6:30 ` Darren Jenkins
  2007-08-06 17:20 ` Andi Drebes
@ 2007-08-06 22:59 ` Matthew Wilcox
  2007-08-07  7:05 ` Thomas Petazzoni
  3 siblings, 0 replies; 5+ messages in thread
From: Matthew Wilcox @ 2007-08-06 22:59 UTC (permalink / raw)
  To: kernel-janitors

On Mon, Aug 06, 2007 at 07:20:00PM +0200, Andi Drebes wrote:
> Hi Darren,
> > I was just wondering about finding an unmaintained driver. Should we
> > just look for
> > stuff marked as Orphan in the MAINTAINERS file or is there
> > another/better list/way
> > to find an un-maintained driver that we shuld be made aware of?

Better is to find drivers with no entry in the MAINTAINERS file at all
... though that's hard to do reliably.  If you announce to K-J that you
intend to take on a driver, someone with a bit more experience such as
Randy or myself can probably let you know if that driver has a maintainer.

> I don't think that the driver definitely has to be unmaintained in order to be 
> chosen by a kernel janitor. If you pick a driver that is currently 
> maintained, you could do the janitorial work and send a series of patches to 
> the maintainer and to the list. I think a maintainer would appreciate this 
> because somebody does the "dirty work".

That's going to vary by maintainer -- people are funny that way.
Definitely have a thick skin if you're going to do this.  I know how
frustrating it is if you've put in a lot of work cleaning up a driver,
only to have the maintainer reject it because "this driver has to work
on $otheros too, and they don't have a $foo".

I'm glad you two have taken my frustrated comment in such a positive
way.  Thanks.

-- 
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: A change of approach
  2007-07-31 22:05 A change of approach Matthew Wilcox
                   ` (2 preceding siblings ...)
  2007-08-06 22:59 ` Matthew Wilcox
@ 2007-08-07  7:05 ` Thomas Petazzoni
  3 siblings, 0 replies; 5+ messages in thread
From: Thomas Petazzoni @ 2007-08-07  7:05 UTC (permalink / raw)
  To: kernel-janitors

Hi,

Le Mon, 6 Aug 2007 16:59:06 -0600,
Matthew Wilcox <matthew@wil.cx> a écrit :

> Better is to find drivers with no entry in the MAINTAINERS file at all
> ... though that's hard to do reliably.  If you announce to K-J that
> you intend to take on a driver, someone with a bit more experience
> such as Randy or myself can probably let you know if that driver has
> a maintainer.

The problem with drivers is that (except for trivial janitorial tasks),
you need the hardware to hack on the driver. However, for most of the
common hardware today, there are working drivers, correctly maintained.
The unmainainted drivers are drivers for specific hardware, or hardware
that has become uncommon.

By saying that, I realize that I'm the owner of a SCSI card handled by
the advansys driver, which is marked as BROKEN since quite a long time,
and I never did anything for the driver. I tried a bit, but it was an
awful piece of code, very hard to grasp for someone with absolutely no
knowledge of the SCSI stuff.

I saw your recent cleanup and improvements patches, I hope I'll find
the time to give them a try. The SCSI card is still in my box,
connected to a 10 years old 4x CD burner, which I almost no longer use,
since it's so slow compared to more recent CD burners.

> That's going to vary by maintainer -- people are funny that way.
> Definitely have a thick skin if you're going to do this.  I know how
> frustrating it is if you've put in a lot of work cleaning up a driver,
> only to have the maintainer reject it because "this driver has to work
> on $otheros too, and they don't have a $foo".
> 
> I'm glad you two have taken my frustrated comment in such a positive
> way.  Thanks.

Thank you for your comment, I think it's a good idea. Like you, I'm not
sure that doing mechanical and repetitive changes to the kernel is
likely to allow the people doing it to really learn enough to be able
to do more serious changes. Working on a specific area is maybe a
better idea, as you suggest.

Sincerly,

Thomas
-- 
Thomas Petazzoni - thomas.petazzoni@enix.org
http://{thomas,sos,kos}.enix.org - http://www.toulibre.org
http://www.{livret,agenda}dulibre.org
-
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2007-08-07  7:05 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-31 22:05 A change of approach Matthew Wilcox
2007-08-04  6:30 ` Darren Jenkins
2007-08-06 17:20 ` Andi Drebes
2007-08-06 22:59 ` Matthew Wilcox
2007-08-07  7:05 ` Thomas Petazzoni

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.