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: <20080501003855.GN29330@cs181133002.pp.htv.fi>
Date:	Thu, 1 May 2008 03:38:55 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	david@...g.hm, Linus Torvalds <torvalds@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Slaby <jirislaby@...il.com>
Subject: Re: Slow DOWN, please!!!

On Thu, May 01, 2008 at 01:45:38AM +0200, Rafael J. Wysocki wrote:
> On Thursday, 1 of May 2008, david@...g.hm wrote:
> > On Thu, 1 May 2008, Rafael J. Wysocki wrote:
> > 
> > > On Wednesday, 30 of April 2008, Linus Torvalds wrote:
> > >>
> > >> On Wed, 30 Apr 2008, Rafael J. Wysocki wrote:
> > >> So your "fewer commits over a unit of time" doesn't make sense.
> > >
> > > Oh, yes it does.  Equally well you could say that having brakes in a car
> > > didn't make sense, even if you could drive it as fast as the engine allowed
> > > you to. ;-)
> > >
> > >> We have those ten thousand commits. They need to go in. They cannot take
> > >> forever.
> > >
> > > But perhaps some of them can wait a bit longer.
> > 
> > not really, if patches are produced at a rate of 1000/week and you decide 
> > to only accept 2000 of them this month, a month later you have 6000 
> > patches to deal with.
> 
> Well, I think you know how TCP works.  The sender can only send as much
> data as the receiver lets it, no matter how much data there are to send.
> I'm thinking about an analogous approach.
> 
> If the developers who produce those patches know in advance about the rate
> limit and are promised to be treated fairly, they should be able to organize
> their work in a different way.
>...

We cannot control who develops what.

When someone wants some feature or wants to get Linux running on his 
hardware he will always develop the code.

We can only control what we merge.

And the main rationale for the 2.6 development model was that we do no 
longer want distributions to ship kernels with insane amounts of 
patches.

> Thanks,
> Rafael

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ