linux-kernel - Re: [PATCH] gpiolib: Allow user-selection

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 for Android: free password hash cracker in your pocket

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

Message-ID: <486CA7BD.10206@keyaccess.nl>
Date:	Thu, 03 Jul 2008 12:19:41 +0200
From:	Rene Herman <rene.herman@...access.nl>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	David Brownell <david-b@...bell.net>,
	Michael Buesch <mb@...sch.de>, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org, Greg KH <greg@...ah.com>
Subject: Re: [PATCH] gpiolib: Allow user-selection

On 03-07-08 11:01, Andrew Morton wrote:

> On Thu, 03 Jul 2008 10:36:44 +0200 Rene Herman <rene.herman@...access.nl> wrote:

>> Development needs to happen against something relatively stable 
>> really and the last release would generally seem to be the best
>> choice.
> 
> Well one can develop against mainline and port to linux-next and then
> do a quick test.  But it seems like pointless additional overhead to
> me.

Other than developer needing a relatively stable base to develop against 
and run so as to concentrate on the effects of own code certainly people 
that said developer wants to test that which is in development want such 
a base. Fewer testers can/will be testing a particular feature if to do 
so they need to first drag in megabytes upon megabytes of other changes 
as well.

Last iteration I looked at and tested PNP patches and was using .25 as 
base which went smoothly. Then at 26-rc1 I needed to start running that 
since patches were against that which delayed things for a long time 
while I needed to find time to deal with that many unrelated changes 
some of which rather violently broke stuff here (ISA DMA most profoundly).

So should I have caught the ISA DMA breakage before it hit -rc1? Given 
that I tend to care about sound/isa which is its main user, perhaps. But 
the point was that I was trying to test ISAPnP, yet another thing that 
sound/isa is a main user of...

Many users/testers simply do not want to be running bleedin' edge all of 
the time because they'd be spending way too much time fighting bugs in 
places that are of no particular interest to them and when features are 
developed against said edge, you'd have just limited your tester base 
further to those who either will, or have enough sophistication to take 
the change in isolation and backport it to their current kernel 
themselves. And do it again on the next iteration of the feature.

As recently as yesterday I stalled on testing an ALSA patch when I saw 
it fail against mainline and wished for some other model than always 
having to run the very latest.

Not to sound overly pompous (I hope) but not everyone can be responsible 
for all these integration pains. People in corner A tend to care about 
corner A and might consider corners B, C and D unwelcome distractions 
mostly. Linux then has people like you and Linus to stand in the middle 
and make all the corners get along again.

Yes, porting to and checking -next before submission makes perfect sense 
but developing against it -- please not...

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