public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Rene Herman <rene.herman@keyaccess.nl>
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, 3 Jul 2008 02:01:06 -0700	[thread overview]
Message-ID: <20080703020106.fec84f0f.akpm@linux-foundation.org> (raw)
In-Reply-To: <486C8F9C.7080507@keyaccess.nl>

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

> On 03-07-08 07:08, Andrew Morton wrote:
> 
> > But what I am repeatedly seeing is people cheerfully raising 2.6.27 
> > patches against the 2.6.26 tree when we have a nice 2.6.27 tree for 
> > developing against.  Those days are over, guys.
> > 
> > I'm also seeing obvious signs that developers aren't _testing_ their 
> > new code within the context of the 2.6.27 tree.  They're obviously 
> > testing their stuff against 2.6.26 and then hoping and praying, only
> > it doesn't always work out for them.
> 
> Developing against -next is even worse than developping against an -rc1. 
> You normally want to be running the code you develop meaning you'd very 
> frequently drown in everyone else's bugs without getting to your own if 
> you do.

Stuff happens.  linux-next is generally OKish.

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

What else can we do?  People are frequently sending patches which don't
even apply to the tree for which they're intended.  And some which
simply fail at compile-time or runtime when they are applied to that tree.

> Now ofcourse, _porting_ it to -next before submitting makes lots of 
> sense but positioning -next as THE devel tree a bit less I feel...

If one wishes.

It's readily obvious that people (ie: top-level maintainers) aren't
even compile-testing their own stuff once it's merged into linux-next. 
You say (but don't provide evidence that) linux-next is too unstable to
develop against.  Well guess why?  Because people are choosing to let
it be that way.


Now the upshot of this might be that people end up having to spend more
time testing and less time developing.  It is fairly apparent that this
is a desirable outcome.

  reply	other threads:[~2008-07-03 11:58 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 [this message]
2008-07-03 10:19           ` Rene Herman
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=20080703020106.fec84f0f.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=david-b@pacbell.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mb@bu3sch.de \
    --cc=rene.herman@keyaccess.nl \
    --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