linux-kernel - Re: [GIT PATCH] scsi bug fixes for 2.6.23-rc2

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:	Tue, 07 Aug 2007 11:24:47 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	James Bottomley <James.Bottomley@...elEye.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PATCH] scsi bug fixes for 2.6.23-rc2

Andrew Morton wrote:
> On Mon, 06 Aug 2007 22:55:41 -0500 James Bottomley <James.Bottomley@...elEye.com> wrote:
>> I really, *really* think we need a pre-release tree that consists of all
>> the upstream targetted features (i.e. all of the for the next merge
>> window git trees) and nothing else.
> 
> That *is* -mm.  The vast majority of -mm is the 75-odd subsystem trees. 

Not quite.

-mm is git trees plus an amazing amount of random patches that turned up 
on LKML, a lot of which is not destined for kernel release 2.6.(X+1) or 
2.6.(X+2),


> Plus, an *amazing* amount of stuff turns up in the git trees which was
> committed just a few days prior to the merge window opening, or even after
> it opening.

Yes :(  That's a tough problem to solve, too.

Deadlines always motivate people, and so -- as in almost every other 
software project I've worked with -- everybody seems to submit their 
work on the day of the deadline.

Realistically, for the merge window to work perfectly, each step down 
the maintainership ladder needs to have time to review and integrate the 
changes destined for that merge window.  Ideally, people would do all 
this work beforehand, so that each step up the ladder has time prior to 
merge window for review and testing.

But that's just not software engineers as we know them ;-)


>>  The lack of a tree like this that we could have
>> persuaded people to test for the last month is what's causing us to
>> scramble like this at the closure of the merge window.
> 
> Nope.  The scramble is caused by subsystem maintainers jamming stuff into
> mainline at the last minute so they don't have to sit on it for the next
> two months.

Indeed.  Particularly in this case, where bsg didn't really grace -mm at 
all.


> Look.  If we're serious about this then the rule needs to be something like
> 
>   If it wasn't committed to your tree *at least* two weeks prior to the
>   2.6.x merge window opening, it shouldn't go into 2.6.x.
> 
> People are not presently observing this sort of discipline by a metric
> mile.  And I'm not sure that we should, really.

My goal AT A MINIMUM with netdev and libata is to get stuff in at least 
one -mm release prior to merge window opening (though preferably a 
longer lead time than that).  Of course, reality intrudes, but that's my 
goal.

And I think it's a reasonable goal to push upon others (but I'm biased:))

	Jeff


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