[Daniel Burrows]
> To me, this sounds like the argument that "I don't need seat belts
> or air bags because only bad drivers crash and I'm a good driver".
Or even better, "using seat belts is showing distrust to the
driver". :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "u
On Sat, Nov 19, 2005 at 01:28:34AM -0600, Peter Samuelson <[EMAIL PROTECTED]>
was heard to say:
> Do you really think packaging mistakes not caught by lintian would be
> caught by the test suite put together by the same goober who made those
> packaging mistakes?
To me, this sounds like the arg
Ian Jackson wrote:
> The scheme I'm proposing is useful to Debian even if the buildds don't
> get enhanced to run the tests automatically, because package
> maintainer tools can easily be enhanced to do that. Of course Ubuntu
> will do that testing automatically but Ubuntu apparently has (will
> h
Bill Allombert writes ("Re: Automated testing - design and interfaces"):
> My fault, I wrote literally half of the sentence. What I meant is that
> nothing prevent you to run arbitrary test in your 'debian/rules build'
> target even if you have to add more Build-
Peter Samuelson writes ("Re: Automated testing - design and interfaces"):
> Do you really think packaging mistakes not caught by lintian would be
> caught by the test suite put together by the same goober who made those
> packaging mistakes?
The goobers (as you say) who make
to, 2005-11-17 kello 18:43 +, Ian Jackson kirjoitti:
> Note: that this is one of two messages on roughly the same topic.
>
> This message will deal solely with TECHNICAL issues. If you have some
> technical followup then please go ahead and reply here. If you have a
> complaint or comment ab
On Thu, 2005-11-17 at 14:36 -0800, Steve Langasek wrote:
> [let's get this over to a technical list like it was supposed to be ;)]
> > Following your exit status based approach you could add to stanzas
> > something like:
>
> > Expected-Status: 0
>
> > I found the above requirement the very mi
[Ian Jackson]
> Running the upstream test suite in debian/rules usually isn't the
> answer to packaging mistakes, library mismanglements, and the like.
I have an idea. What if we had a script that ran dpkg-buildpackage and
then immediately ran lintian and linda if available, to look for common
p
On Fri, Nov 18, 2005 at 12:23:49PM +, Ian Jackson wrote:
> (Note: sorry about my earlier header mixup. This thread is on the
> wrong list so I'm crossposting this reply to -project and -policy and
> have set Reply-To to point to -policy. I will also quote more of
> Stefano's message than woul
On Fri, Nov 18, 2005 at 03:35:25PM +, Ian Jackson wrote:
> Bill Allombert writes ("Re: Automated testing - design and interfaces"):
> > piuparts is a first answer to that: it allows maintainer to check that
> > their package will install, remove and upgrade in a clea
On Fri, Nov 18, 2005 at 03:35:25PM +, Ian Jackson wrote:
> Bill Allombert writes ("Re: Automated testing - design and interfaces"):
> > On Fri, Nov 18, 2005 at 12:08:25PM +, Ian Jackson wrote:
> > > maintainer didn't really test the package after installing
Bill Allombert writes ("Re: Automated testing - design and interfaces"):
> On Fri, Nov 18, 2005 at 12:08:25PM +, Ian Jackson wrote:
> > maintainer didn't really test the package after installing it because
> > it was too much trouble. If it can be standardised a
On Fri, Nov 18, 2005 at 12:08:25PM +, Ian Jackson wrote:
> maintainer didn't really test the package after installing it because
> it was too much trouble. If it can be standardised and automated, and
> if a way can be found for Ubuntu to share tests with Debian, then
> everyone wins.
piupart
(Note: sorry about my earlier header mixup. This thread is on the
wrong list so I'm crossposting this reply to -project and -policy and
have set Reply-To to point to -policy.)
Sven Luther writes ("Re: Automated testing - design and interfaces"):
> How will this interact w
asier time.)
Stefano Zacchiroli writes ("Re: Automated testing - design and interfaces"):
> On Thu, Nov 17, 2005 at 06:43:32PM +, Ian Jackson wrote:
> > This means execute debian/tests/fred, debian/tests/bill, etc.,
> > each with no arguments, expecting exit status 0
Ian Jackson writes ("Automated testing - design and interfaces"):
> Note: that this is one of two messages on roughly the same topic.
>
> This message will deal solely with TECHNICAL issues. [...]
Damn! I must have gotten confused while editing headers and this went
to
Stefano Zacchiroli writes ("Re: Automated testing - design and interfaces"):
> Having been involved in various unit testing packages [...]
These are technical, not political, comments and should be on
-policy. Could I trouble you to repost your message there ? Or would
you prefe
Bill Allombert writes ("Re: Automated testing - design and interfaces"):
> Currently Debian packages are tested through a lot of channel:
> [stuff]
Right.
> Debian is an organisation which can afford a lot of decentralisation,
> but where centralisation is very expensive
* Ian Jackson [Fri, 18 Nov 2005 11:58:26 +]:
> This is a technical comment and ought to be discussed on -policy,
> rather than -project.
Note that you posted to the wrong list first.
--
Adeodato Simó
EM: dato (at) the-barrel.org | PK: DA6AE621
So, irregular/impure/non-elegant syntax
Sven Luther writes ("Re: Automated testing - design and interfaces"):
> How will this interact with stuff like the powerpc32/powerpc64
> biarch situation, where there is a series of tests which can only be
> handled on powerpc64, but no powerpc32 ? I know ubuntu has only
>
On Thu, Nov 17, 2005 at 06:43:32PM +, Ian Jackson wrote:
> Note: that this is one of two messages on roughly the same topic.
>
> This message will deal solely with TECHNICAL issues. If you have some
> technical followup then please go ahead and reply here. If you have a
> complaint or commen
Bcc'ed to -project; followups to -devel.
On Thu, Nov 17, 2005 at 06:43:32PM +, Ian Jackson wrote:
> Note that the point is to be able to test the _actual package_, _as
> installed_ (eg on a testbed system). This is much better than testing
> the package from the source treeu during build time
[let's get this over to a technical list like it was supposed to be ;)]
On Thu, Nov 17, 2005 at 10:43:34PM +0100, Stefano Zacchiroli wrote:
> On Thu, Nov 17, 2005 at 06:43:32PM +, Ian Jackson wrote:
> > This means execute debian/tests/fred, debian/tests/bill, etc.,
> > each with no argumen
On Thu, Nov 17, 2005 at 06:43:32PM +, Ian Jackson wrote:
> This means execute debian/tests/fred, debian/tests/bill, etc.,
> each with no arguments, expecting exit status 0 and no stderr. The
Having been involved in various unit testing packages I found the above
expectations too much const
Bill Allombert <[EMAIL PROTECTED]> writes:
> Debian is an organisation which can afford a lot of decentralisation,
> but where centralisation is very expensive (debian-admin time, etc.).
> Doing the checks in debian/rules is not perfect, but it happens before
> the package is uploaded, is perform
On Thu, Nov 17, 2005 at 06:43:32PM +, Ian Jackson wrote:
> So, what do you think ?
Currently Debian packages are tested through a lot of channel:
-- At build-time, if the package run a test-suite in debian/rules,
which is strongly encouraged.
-- By the maintainer before uploading them.
-
Note: that this is one of two messages on roughly the same topic.
This message will deal solely with TECHNICAL issues. If you have some
technical followup then please go ahead and reply here. If you have a
complaint or comment about my or Ubuntu's approach, please reply in
debian-*project* to my
27 matches
Mail list logo
