public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@keyaccess.nl>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Brownell <david-b@pacbell.net>,
	Michael Buesch <mb@bu3sch.de>,
	sfr@canb.auug.org.au, linux-kernel@vger.kernel.org,
	Greg KH <greg@kroah.com>
Subject: Re: [PATCH] gpiolib: Allow user-selection
Date: Thu, 03 Jul 2008 12:19:41 +0200	[thread overview]
Message-ID: <486CA7BD.10206@keyaccess.nl> (raw)
In-Reply-To: <20080703020106.fec84f0f.akpm@linux-foundation.org>

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

> On Thu, 03 Jul 2008 10:36:44 +0200 Rene Herman <rene.herman@keyaccess.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.

  reply	other threads:[~2008-07-03 12:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-02 21:46 [PATCH] gpiolib: Allow user-selection Michael Buesch
2008-07-03  0:04 ` Andrew Morton
2008-07-03  0:26   ` Michael Buesch
2008-07-03  5:00   ` David Brownell
2008-07-03  5:08     ` Andrew Morton
2008-07-03  5:41       ` David Brownell
2008-07-03 19:37         ` Greg KH
2008-07-03 21:28           ` David Brownell
2008-07-03 23:08             ` Greg KH
2008-07-12  5:32               ` David Brownell
2008-07-03  8:36       ` Rene Herman
2008-07-03  9:01         ` Andrew Morton
2008-07-03 10:19           ` Rene Herman [this message]
2008-07-03  8:25   ` David Brownell
2008-07-03  8:42     ` Michael Buesch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=486CA7BD.10206@keyaccess.nl \
    --to=rene.herman@keyaccess.nl \
    --cc=akpm@linux-foundation.org \
    --cc=david-b@pacbell.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mb@bu3sch.de \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox