linux-kernel - Re: Elaboration on "Equivalent fix must already exist in Linus' tree"

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, 3 Mar 2009 10:43:32 -0800
From:	"Luis R. Rodriguez" <mcgrof@...il.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Greg KH <greg@...ah.com>, Jeff Garzik <jeff@...zik.org>,
	wireless <linux-wireless@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Theodore Tso <tytso@....edu>
Subject: Re: Elaboration on "Equivalent fix must already exist in Linus' tree"

On Tue, Mar 3, 2009 at 10:13 AM, Stefan Richter
<stefanr@...6.in-berlin.de> wrote:
> Luis R. Rodriguez wrote:
>> On Tue, Mar 3, 2009 at 7:27 AM, Stefan Richter
>> <stefanr@...6.in-berlin.de> wrote:
>>> Luis R. Rodriguez wrote:
>>>> OK small silly example is convincing distributions it may be a good
>>>> idea to carry linux-next kernel packages as options to users to
>>>> hopefully down the road reduce the delta between what they carry and
>>>> what is actually upstream.
>>> Distros would do their users a bigger favour if [...]
>>
>> I don't think I was very clear in what I meant about "carrying
>> linux-next kernel packages as an option". What I meant was carrying it
>> just as an option for those users who want to test bleeding edge
>> without compiling their own linux-next, _not_ to merge linux-next
>> things into their own default kernel release and shove it down users
>> throats.
>
> Sorry, I meant "bigger favour" relative to carrying an own delta of
> considerable size.
>
> Packaging linux-next would be fine if the workload isn't a problem for
> the packager.  As pointed out elsewhere, there are caveats with
> linux-next (e.g. a functionality which was in it yesterday could be gone
> today because of a merge issue), but that's the nature of bleeding edge
> of course.

Sure, understood. That's all I meant really.

My argument here I guess is that the reasons used to support the
"equivalent fix" policy for patches upstream makes it apparent why
linux-next is so important and my hope would be to get it more
exposure by having distributions let users test it (as an option to go
with bleeding edge) and this in turn help stabilize code in our next
release.

But I certainly don't expect every distribution to carry such a
package, nor would I expect them to want to deal with it. Just wanted
to build a good case for distributions to consider it.

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