From: Theodore Ts'o <tytso@mit.edu>
To: Dave Chinner <david@fromorbit.com>
Cc: Sedat Dilek <sedat.dilek@gmail.com>,
lsf@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-ext4@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [Lsf] [PATCH] xfstests-bld: Simplify determination of number of CPUs in build-all
Date: Mon, 31 Mar 2014 22:37:11 -0400 [thread overview]
Message-ID: <20140401023711.GE4911@thunk.org> (raw)
In-Reply-To: <20140331025148.GF16336@dastard>
On Mon, Mar 31, 2014 at 01:51:48PM +1100, Dave Chinner wrote:
> /me puts on his xfstests Maintainer Hat
>
> That's a problem of your own making, Ted: please don't speak on
> behalf of what the upstream xfstests developers might or might not
> do just because of what you do with it as a user. The existance of
> many different environments people have built up around it is one of
> the strengths of xfstests. Hence the very act of considering
> enforcing One True Way of running xfstests is, IMO, harmful
> to the wider filesystem and xfstests community.
I wasn't presuming to do so.
I am merely pushing xfstests-bld because it's better that more people
run tests. And if it makes it easier for people to run tests because
there is a turn-key way to run them, so much the better. Having a
diversity of ways of running xfstests is good. Having lots of people
run xfstests, even if many of them run it the same way, is better.
> You're also being rather presumptive that the existence of
> xfstests-bld requires us to change anything about the way xfstests
> is run.
I never said that any changes was needed to xfstests repository, or
how anyone else might choose to run xfstests.
> > especially given that based on a challenge which
> > Greg K-H gave us at the kernel pannel at Collab Summit,
> ^^^^
>
> Hmmmm. Not the way I remember it. Perhaps I should go look at the
> video and check that Greg was addressing me directly as the xfstests
> maintainer with those comments. After all, those lights on stage can
> be blinding.....
Sorry, I thought in the discussions we had afterwards you agreed with
me that *some* way of running xfststs easily was going to be a
requirement, as it is somewhat doubtful that most non-file system
developers will have the patience to deal with the "some assembly
required" in order to actually run xfstests, and actually putting
xfstests into the kernel sources wasn't going to be particularly
useful unless we have some way of making it possible to run the tests
in a semi-automated fashion.
Whether that method is based on what I have in xfstests-bld, or some
other way is I agree certainly up for discussion. At the moment the
system I have is only set up for ext4, although I will happily accept
patches and work with other file system developers to enhance it so it
can work with other file systems.
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.
Cheers,
- Ted
next prev parent reply other threads:[~2014-04-01 2:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-28 9:03 [PATCH] xfstests-bld: Simplify determination of number of CPUs in build-all Sedat Dilek
2014-03-28 16:18 ` tytso
2014-03-29 10:04 ` Sedat Dilek
2014-03-29 14:04 ` Theodore Ts'o
2014-03-31 2:51 ` [Lsf] " Dave Chinner
2014-04-01 2:37 ` Theodore Ts'o [this message]
2014-04-01 22:28 ` Dave Chinner
2014-04-02 14:26 ` Theodore Ts'o
2014-04-03 1:14 ` Dave Chinner
2014-04-03 10:26 ` Lukáš Czerner
2014-04-03 17:05 ` Andy Lutomirski
2014-04-03 17:35 ` Theodore Ts'o
2014-04-03 17:42 ` Andy Lutomirski
2014-04-03 19:06 ` Eric Sandeen
2014-04-03 19:21 ` Andy Lutomirski
2014-04-03 21:46 ` Eric Sandeen
2014-04-03 19:30 ` Theodore Ts'o
2014-04-03 21:20 ` Dave Chinner
2014-04-03 13:16 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140401023711.GE4911@thunk.org \
--to=tytso@mit.edu \
--cc=david@fromorbit.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf@lists.linux-foundation.org \
--cc=sedat.dilek@gmail.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).