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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 3 Jul 2008 02:01:06 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Rene Herman <rene.herman@...access.nl>
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 Thu, 03 Jul 2008 10:36:44 +0200 Rene Herman <rene.herman@...access.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.
--
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/