linux-ext4 - Re: [Lsf] [PATCH] xfstests-bld: Simplify determination of number of CPUs in build-all

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 2 Apr 2014 10:26:20 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Dave Chinner <david@...morbit.com>
Cc:	Sedat Dilek <sedat.dilek@...il.com>,
	lsf@...ts.linux-foundation.org, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, xfs@....sgi.com
Subject: Re: [Lsf] [PATCH] xfstests-bld: Simplify determination of number of
 CPUs in build-all

On Wed, Apr 02, 2014 at 09:28:23AM +1100, Dave Chinner wrote:
> > And of course, whether changes in the mainline kernel tree are
> > manually propagated changes from the xfstests.git tree, or whether
> > primary development happens in the kernel tree, is ultimately going to
> > be up to you and the XFS developers who have stewardship of xfstests.
> > I'm not sure I would be that excited about manual propagation of
> > changes from one git tree to another, but that is of course, up to
> > you.
> 
> And this is exactly my point, Ted. Again, you are presuming that the
> implementation is going to require syncing commits across disparate
> git trees and other such games will be needed to maintain separate
> packages. Nothing could be further from the truth: we already have
> this problem with the shared XFS kernel/userspace code and it's a
> royal PITA keeping them in sync. Hence introducing the same
> maintenance problem with new code and infrastructure is highly
> undesirable and something we'll try to avoid at all costs.

Actually, I was presuming that the thing that makes the most sense was
to move all or most of the tests in xfstests into the kernel tests
tree.  And then you complained that I was making a presumption that
this was the only sane thing to do.  That's why I said, "if you want
to do something insane, be my guest".

I have nothing against doing a formal requirements process, that's
fine, but I think there are certain things about what the final
solution of "test in the kernel git tree" will look like that are
pretty obvious.

Cheers,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html