linux-kernel - Re: [PATCH 3/5] watchdog: cleanup a bit omap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080921184058.GC7961@atomide.com>
Date:	Sun, 21 Sep 2008 11:41:00 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	David Brownell <david-b@...bell.net>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
	Wim Van Sebroeck <wim@...ana.be>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"George G. Davis" <gdavis@...sta.com>
Subject: Re: [PATCH 3/5] watchdog: cleanup a bit omap_wdt.c

* Russell King - ARM Linux <linux@....linux.org.uk> [080920 11:01]:
> On Sat, Sep 20, 2008 at 10:18:41AM -0700, David Brownell wrote:

<snip snip>

> 
> > > We're into the third day on this one driver.  If every OMAP driver takes
> > > this long ...
> > 
> > That seems like a strange way to account things.  It presumes
> > that the only time review comments should be accepted is within
> > a day of the patch getting posted.  Regardless of whether the
> > reviewer has time at that point.
> 
> You define accounting for things in real time as "strange" - lol.  Your
> following sentences don't follow either.
> 
> My point is that we currently have a BIG problem, and that is the OMAP
> fork being so far out of line with mainline, it isn't funny.  It's
> causing lots of pain for everyone here.  Folk are screaming for mainline
> to be buildable for OMAP.
> 
> There are two approaches to achieve that: take each driver, polish it
> for weeks on end until it's nice and shiney, and then submit it upstream.
> Eventually, given enough man hours, you'll get to the point where you've
> pushed everything upstream, but in the mean time, new work has been
> queued so you need to start at the beginning again.  You've got a job
> for life constantly polishing code.
> 
> The other approach is to decide that we have what we have, and that in
> the interests of efficiently reducing divergence, merging the upstream
> changes with the downstream changes and pushing the result upstream ASAP.
> Once merged, further improvements and cleanups can be made by pushing
> them separately upstream along with any other bug fixes.
> 
> Given the amount of divergence, the only approach which gives realistic
> progress is the second one.
> 
> If you think the first approach is the way to go, then please join in
> with Tony and myself reviewing the _entire_ OMAP tree, polishing every
> patch, and pushing it upstream.  And I mean _everything_.  Not just the
> USB stuff.  Encourage everyone else to do the same - because it will
> take an army of individuals to make any forward progress.

Hey, you gotta give Dave some credit! Dave's been polishing tons of omap
code in addition to the USB, at least I2C, gpio, SPI come to mind. Not to
mention all the blinking leds!

Regarding getting and army of people to fix code, we need to start
following another standard policy: All drivers must have a MAINTAINER
who is capable of fixing things, and ideally doing things the right
way from the start.

It's not going to be enough that few people try to fix stuff and get
burnt out on it over and over again when new omaps come around every
1.5 years.

<snip snip>

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/