linux-kernel - Re: linux-next: Tree for Oct 24

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: <20131025171721.GB8091@roeck-us.net>
Date:	Fri, 25 Oct 2013 10:17:21 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Thierry Reding <thierry.reding@...il.com>
Cc:	Olof Johansson <olof@...om.net>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mark Brown <broonie@...nel.org>
Subject: Re: linux-next: Tree for Oct 24

On Fri, Oct 25, 2013 at 05:17:18PM +0200, Thierry Reding wrote:
> > > 
> > "Doesn't even build" is relative, though. After all, there still _are_
> > 18 build failures out of 106 in my test builds alone. Where do you draw
> > the line ? arm failures are bad, who cares about blackfin ?
> 
> Well, I've been doing x86, ARM and PowerPC builds and of those only 3
> are failing and I didn't fix them because I didn't really know how to.
> But you're right, I guess one has to draw the line somewhere, and if
> people prefer the tree to just be broken rather than with odd fixes on
> top, then that's the way it going to be.
> 
> For now I've settled on pushing a branch which has only the fixes that
> are required to make the trees work happily together and a separate tag
> which has the patches that unbreak subsystem trees.
> 
> The reason I usually want linux-next to build is because I know that
> various people rely on it for their daily work, so my reasoning was that
> if I fix it before they even start using it, then they get to spend
> their time with something more useful and only one person ends up fixing
> the build issues instead of everyone.
> 
Frankly, I don't even know what the best approach would be.
Ultimately you are stuck between a rock and a hard place: You want the tree
to build so people can use it, but each patch you apply yourself might 
result in it not getting fixed in the contributing repository.

I think one problem we have is how to report breakages. Any summary 
mail or web page doesn't help if no one looks at it. It does help lot
to send specific e-mail along the line of "Commit 'bla' caused build 'x'
to fail as follows" to the respective mailing list and patch authors,
but that takes a lot of time which at least I don't have. And people
might get annoyed by automated e-mails, so that might not be a good
idea either. 

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