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

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20131028165301.GN13643@sirena.org.uk>
Date:	Mon, 28 Oct 2013 09:53:01 -0700
From:	Mark Brown <broonie@...nel.org>
To:	Thierry Reding <thierry.reding@...il.com>
Cc:	Randy Dunlap <rdunlap@...radead.org>, linux-next@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Olof Johansson <olof@...om.net>
Subject: Re: linux-next: Tree for Oct 25

On Mon, Oct 28, 2013 at 09:01:24AM +0100, Thierry Reding wrote:

> Perhaps something like the above scheme might be a good compromise. On
> one hand, many people are using linux-next for their daily work, myself
> included. That implies that if linux-next doesn't build, people either
> use a previous one that does build (so we don't get as much testing of
> new trees as we possibly could) or they fix the build errors themselves
> which in turn may cause potentially many people to have to fix the same
> issues. On the other hand, if patches to fix build issues are included
> then people might just assume that there are no problems.

This is one of the things that the per merge build tests really help
with - they filter out the vast majority of errors by just not letting
updates into -next (which applies some backpressure to get thing fixed
in the original tree too).

> With such a scheme next-YYYYMMDD could serve as a metric of how good or
> broken the various trees are, while next-YYYYMMDD-fixes would be a base
> that people could use for daily work, with a set of known build fixes.
> Perhaps it could even contain fixes for non-build issues, such as boot
> failures, if we can come up with those quickly enough to make sense in a
> linux-next context.

> Any thought?

This seems really tough to do given the rate of change of -next -
there's about 24 hours to get fixes in there before you have to rebase
forwards again.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)