All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.