From: Davidlohr Bueso <dave@gnu.org>
To: Bernhard Voelker <mail@bernhard-voelker.de>
Cc: Karel Zak <kzak@redhat.com>,
kerolasa@gmail.com, util-linux@vger.kernel.org
Subject: Re: v2.22-rc2 wish list
Date: Fri, 27 Jul 2012 15:13:24 +0200 [thread overview]
Message-ID: <1343394804.2752.5.camel@offbook> (raw)
In-Reply-To: <50127F34.70406@bernhard-voelker.de>
On Fri, 2012-07-27 at 13:44 +0200, Bernhard Voelker wrote:
> On 07/27/2012 01:15 PM, Karel Zak wrote:
> > On Fri, Jul 27, 2012 at 12:47:46PM +0200, Bernhard Voelker wrote:
> >> On 07/27/2012 12:31 PM, Karel Zak wrote:
> >>> Maybe, but many of the tests requires root permissions and it's
> >>> designed for developers only. I'd like to avoid situations when the
> >>> tests are executed with root permissions by automatic distro build
> >>> systems etc.
> >>
> >> Why? The more folks run the tests, the more bugs can be reported and fixed.
> >> What's wrong about the tests? And if there's something wrong: shouldn't
> >> they not be made more robust?
> >>
> >> E.g. coreutils also has many tests which "require_root", and I think
> >> it's safe to run these tests.
> >
> > Does the tests modify /etc/fstab, mount another filesystems and
> > initialize scsi_debug, loop and raid devices?
>
> yes, but I don't consider mount/umount as too dangerous - coreutils'
> test suite also does it. Some more harmful tests could be guarded by
> some special mechanism, e.g. an environment variable.
>
> > I have experience that some distros and end-users rebuild packages
> > as superuser.
>
> Building as root is certainly not okay, but prior to packaging UL into a
> distro or applying it on a few servers, I expect every admin and
> distro maintainer to run 'make check'.
>
> With a proper test suite, we give him/her a basic test to check whether
> the software is running as expected in his/her environment. Otherwise,
> he doesn't have much chance other than waiting for productive problems.
>
I partially agree with this. However our test scripts are strictly
regression testing and, of course, that is part of the development
cycle, so end-users have no business dealing with this. For example, we
cannot ask users to rebuild their kernel just to run theses tests (like
scsi_debug module).
> > I don't want to be responsible for possible problems on
> > the target systems.
>
> You aren't:
> $ grep -i warranty COPYING
> ;-)
>
> Have a nice day,
> Berny
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2012-07-27 13:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-27 8:10 v2.22-rc2 wish list Karel Zak
2012-07-27 8:26 ` Sami Kerola
2012-07-27 10:31 ` Karel Zak
2012-07-27 10:47 ` Bernhard Voelker
2012-07-27 11:15 ` Karel Zak
2012-07-27 11:44 ` Bernhard Voelker
2012-07-27 13:13 ` Davidlohr Bueso [this message]
2012-07-27 20:27 ` Karel Zak
2012-07-30 16:37 ` Karel Zak
2012-07-31 5:21 ` Bernhard Voelker
[not found] ` <5012B7B4.8070001@gmail.com>
2012-07-27 17:59 ` Bruce Dubbs
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=1343394804.2752.5.camel@offbook \
--to=dave@gnu.org \
--cc=kerolasa@gmail.com \
--cc=kzak@redhat.com \
--cc=mail@bernhard-voelker.de \
--cc=util-linux@vger.kernel.org \
/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).