On Wednesday 02 May 2007, Ciaran McCreesh wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > On Tuesday 01 May 2007, Piotr Jaroszyński wrote:
> > > There was some discussion about forcing/not forcing tests in
> > > EAPI-1, but there was clearly no compromise.
> >
> > the compromise was that req
On Wed, 2 May 2007 16:05:06 -0400
Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Tuesday 01 May 2007, Piotr Jaroszyński wrote:
> > There was some discussion about forcing/not forcing tests in
> > EAPI-1, but there was clearly no compromise.
>
> the compromise was that requiring in spec is wrong ..
On Tuesday 01 May 2007, Piotr Jaroszyński wrote:
> There was some discussion about forcing/not forcing tests in EAPI-1, but
> there was clearly no compromise.
the compromise was that requiring in spec is wrong ... default handling of
tests is up to the package manager / profiles / teams
> Imho,
On Tue, 01 May 2007 21:51:17 -0400
Daniel Gryniewicz <[EMAIL PROTECTED]> wrote:
> Sure, but now you're requiring me to go through all that extra work
> if I want any of the benefits of EAPI=1.
It is likely that EAPI-1 will be stricter in quite a few areas...
> Or, third option, is that everyone m
On Tue, 1 May 2007 17:34:07 -0700
Brian Harring <[EMAIL PROTECTED]> wrote:
> On Wed, May 02, 2007 at 12:55:05AM +0100, Ciaran McCreesh wrote:
> > You're talking implementation details. This isn't the time for that!
> > No-one has worked out what, if anything, is to be done, so you can't
> > know ho
On 02.05.2007, at 02:32, Marius Mauch wrote:
a) cost (in terms of runtime, resource usage, additional deps)
Tools for this could be implemented in the package manager. The
package has to be installed and tested by the developer, so if
portage would show the times for each stage or the tim
Am Mittwoch, 2. Mai 2007 schrieb Rémi Cardona:
> Piotr Jaroszyński a écrit :
> > On Tuesday 01 of May 2007 21:53:36 Maurice van der Pot wrote:
> >> I'm not sure why this is a reply to my message instead of the
> >> message I replied to. They both provide more or less the same
> >> choice to the use
Hi Daniel,
Am Mittwoch, 2. Mai 2007 schrieb Daniel Gryniewicz:
> Honestly, tests are nice, but too many of them are broken upstream,
> and we are not (and should not be, IMO) in the position of fixing
> them all. If a developer wants to work with her upstream to fix the
> tests in her packages, gr
Piotr Jaroszyński a écrit :
On Tuesday 01 of May 2007 21:53:36 Maurice van der Pot wrote:
I'm not sure why this is a reply to my message instead of the message I
replied to. They both provide more or less the same choice to the user.
Err I wasn't providing any choices for users yet, I only tho
On Wed, 2007-05-02 at 01:12 +0100, Stephen Bennett wrote:
> On Tue, 01 May 2007 19:46:56 -0400
> Daniel Gryniewicz <[EMAIL PROTECTED]> wrote:
>
> > There is one serious problem with this: Who's going to do the work to
> > figure all this out for the 11,000 odd packages in the tree? This
> > seem
On Wed, May 02, 2007 at 12:55:05AM +0100, Ciaran McCreesh wrote:
> You're talking implementation details. This isn't the time for that!
> No-one has worked out what, if anything, is to be done, so you can't
> know how much work whatever it is is.
>
> Having said that, there's no need to figure it
On Tue, 01 May 2007 19:46:56 -0400
Daniel Gryniewicz <[EMAIL PROTECTED]> wrote:
> There is one serious problem with this: Who's going to do the work to
> figure all this out for the 11,000 odd packages in the tree? This
> seems like a *huge* amount of work, work that I have no plan on doing
> for
On Tue, May 01, 2007 at 07:46:56PM -0400, Daniel Gryniewicz wrote:
> On Wed, 2007-05-02 at 01:32 +0200, Marius Mauch wrote:
> > I'd approach it a bit different: Before creating fixed classification
> > groups I'd first identify the attributes of tests that should be used
> > for those classificatio
On Tue, 01 May 2007 19:46:56 -0400
Daniel Gryniewicz <[EMAIL PROTECTED]> wrote:
> There is one serious problem with this: Who's going to do the work to
> figure all this out for the 11,000 odd packages in the tree? This
> seems like a *huge* amount of work, work that I have no plan on doing
> fo
On Wed, 2 May 2007 01:32:20 +0200
Marius Mauch <[EMAIL PROTECTED]> wrote:
> (btw, could someone give some real examples for packages with
> "necessary" tests?)
There're two groups of packages with necessary tests that come to mind:
those that are very compiler / system sensitive (certain scientifi
On Wed, 2007-05-02 at 01:32 +0200, Marius Mauch wrote:
>
> I'd approach it a bit different: Before creating fixed classification
> groups I'd first identify the attributes of tests that should be used
> for those classifications.
> a) cost (in terms of runtime, resource usage, additional deps)
>
On Tue, 1 May 2007 15:08:56 +0200
Piotr Jaroszyński <[EMAIL PROTECTED]> wrote:
> Hello,
>
> There was some discussion about forcing/not forcing tests in EAPI-1,
> but there was clearly no compromise. Imho, tests are very important
> and thus I want to discuss them a little more, but in more sensi
On Tue, 01 May 2007 14:52:30 -0700
Josh Saddler <[EMAIL PROTECTED]> wrote:
> anyway, on the subject of tests...as others have covered the *first*
> time this was discussed on the lists, mandatory tests being run every
> time the user installs a package? no. oh hell no. we don't seem to do
> that mu
On Tue, 1 May 2007 21:53:36 +0200
Maurice van der Pot <[EMAIL PROTECTED]> wrote:
> > Too complicated. Bombarding the user with pointless alternatives is
> > not the same as giving the user choice.
>
> I'm not sure why this is a reply to my message instead of the message
> I replied to. They both p
On Wednesday 02 of May 2007 00:28:42 Josh Saddler wrote:
> Not a knee jerk reaction, just a strong one. One of the key reasons why
> mandatory tests were not desired was the fact that sometimes much more
> stuff will be installed than what you'd normally get. Exhibit A:
> robbat2's message just sen
Stephen Bennett wrote:
> On Tue, 01 May 2007 14:52:30 -0700
> Josh Saddler <[EMAIL PROTECTED]> wrote:
>
>> anyway, on the subject of tests...as others have covered the *first*
>> time this was discussed on the lists, mandatory tests being run every
>> time the user installs a package? no. oh hell
On Tue, 01 May 2007 14:52:30 -0700
Josh Saddler <[EMAIL PROTECTED]> wrote:
> anyway, on the subject of tests...as others have covered the *first*
> time this was discussed on the lists, mandatory tests being run every
> time the user installs a package? no. oh hell no. we don't seem to do
> that m
On Tue, May 01, 2007 at 10:10:28PM +0200, Jure Varlec wrote:
> On Tuesday 01 of May 2007 21:24:17 R??mi Cardona wrote:
> > - require other and bigger deps than what the actual package requires
> Hm, perhaps this one should be split into:
> -- additional deps are already installed
> -- additional
Maurice van der Pot wrote:
>>> fex:
>> Please don't abuse the English language in that manner.
>
> Since you took the time to highlight this apparently grave injustice to
> the English language, would you please explain it to me so I can do
> better next time?
he just doesn't like it because it's
On Tuesday 01 of May 2007 21:24:17 Rémi Cardona wrote:
> - require other and bigger deps than what the actual package requires
Hm, perhaps this one should be split into:
-- additional deps are already installed
-- additional deps are not yet installed
Regards
signature.asc
Description: This
On Tuesday 01 of May 2007 21:53:36 Maurice van der Pot wrote:
> I'm not sure why this is a reply to my message instead of the message I
> replied to. They both provide more or less the same choice to the user.
Err I wasn't providing any choices for users yet, I only thought about the
below as thi
On Tue, May 01, 2007 at 06:35:22PM +0100, Ciaran McCreesh wrote:
> On Tue, 1 May 2007 19:18:28 +0200
> Maurice van der Pot <[EMAIL PROTECTED]> wrote:
> > I'd say, let the user decide based on the properties
>
> Too complicated. Bombarding the user with pointless alternatives is not
> the same as g
Piotr Jaroszyński wrote:
> Hello,
>
> There was some discussion about forcing/not forcing tests in EAPI-1, but
> there
> was clearly no compromise. Imho, tests are very important and thus I want to
> discuss them a little more, but in more sensible fashion.
>
> Firstly each test can be(not all
On Tuesday 01 of May 2007 19:18:28 Maurice van der Pot wrote:
> Isn't it easier to list a set of boolean properties of _individual_
> tests?
It was just a list of different test classes, which came to mind. The
question, which still persist, was how precisely we want to divide them into
groups as
On Tue, 1 May 2007 19:18:28 +0200
Maurice van der Pot <[EMAIL PROTECTED]> wrote:
> I'd say, let the user decide based on the properties
Too complicated. Bombarding the user with pointless alternatives is not
the same as giving the user choice.
I'm also highly sceptical that the properties you lis
On Tue, May 01, 2007 at 03:08:56PM +0200, Piotr Jaroszyński wrote:
> Firstly each test can be(not all categories are mutually exclusive):
> - not existant
> - non-functional
> - not runnable from ebuild
> - useful but unreasonable resource-wise
> - useful and reasonable resource-wise
> - necessary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Gryniewicz wrote:
> On Tue, 2007-05-01 at 15:08 +0200, Piotr Jaroszyński wrote:
>> Hello,
>>
>> There was some discussion about forcing/not forcing tests in EAPI-1, but
>> there
>> was clearly no compromise. Imho, tests are very important and
On Tue, 2007-05-01 at 15:08 +0200, Piotr Jaroszyński wrote:
> Hello,
>
> There was some discussion about forcing/not forcing tests in EAPI-1, but
> there
> was clearly no compromise. Imho, tests are very important and thus I want to
> discuss them a little more, but in more sensible fashion.
>
Piotr Jaroszyński wrote:
> Hello,
>
> There was some discussion about forcing/not forcing tests in EAPI-1, but
> there
> was clearly no compromise. Imho, tests are very important and thus I want to
> discuss them a little more, but in more sensible fashion.
>
> Firstly each test can be(not all
On Tue, 01 May 2007 09:24:34 -0400
Josh Sled <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-05-01 at 15:08 +0200, Piotr Jaroszyński wrote:
> > Firstly each test can be(not all categories are mutually exclusive):
> [...]
> > - necessary
>
> Could you qualify, please? Is this "necessary for the (non-tes
On Tue, 2007-05-01 at 15:08 +0200, Piotr Jaroszyński wrote:
> Firstly each test can be(not all categories are mutually exclusive):
[...]
> - necessary
Could you qualify, please? Is this "necessary for the (non-test) build
artifact"?
If so, I'd not call it a test, just part of the build that's in
Hello,
There was some discussion about forcing/not forcing tests in EAPI-1, but there
was clearly no compromise. Imho, tests are very important and thus I want to
discuss them a little more, but in more sensible fashion.
Firstly each test can be(not all categories are mutually exclusive):
- not
On Mon, 23 May 2005 10:45:24 +0200 Francesco Riosa
<[EMAIL PROTECTED]> wrote:
| Cons:
| - additional overhead on syncing portage tree
Actually, with the new elib/eclass layout, this one's easy to avoid.
Just make a tests/ subdirectory and exclude it from sync.
--
Ciaran McCreesh : Gentoo Develop
Ciaran McCreesh wrote:
>On Tue, 10 May 2005 22:19:27 -0500 Brian Harring <[EMAIL PROTECTED]>
>wrote:
>| On Tue, May 10, 2005 at 09:54:33PM +0100, Ciaran McCreesh wrote:
>| > Is there a standard way of handling testing for utility-type
>| > eclasses? For versionator I currently have a
>| > __versio
On Sat, 14 May 2005 13:21:55 +0200 Francesco Riosa
<[EMAIL PROTECTED]> wrote:
| ciaranm, would you commit it ?
Only if you comment on the bug with the results of the extensive testing
you've done to make sure that I haven't missed anything.
--
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools
Ciaran McCreesh wrote:
>Is there a standard way of handling testing for utility-type eclasses?
>For versionator I currently have a __versionator__test_blah function
>included in the eclass (source versionator.eclass works, it doesn't have
>any portage-specific code), but this is going to get a bit
On Tue, 10 May 2005 22:19:27 -0500 Brian Harring <[EMAIL PROTECTED]>
wrote:
| On Tue, May 10, 2005 at 09:54:33PM +0100, Ciaran McCreesh wrote:
| > Is there a standard way of handling testing for utility-type
| > eclasses? For versionator I currently have a
| > __versionator__test_blah function incl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Francesco Riosa wrote:
> Not tested version_sort() but I've already
> idea on where to use it.
http://dev.gentoo.org/~ka0ttic/bash/vsort
Wrote that up last night in order to test version_sort on a whole bunch of
packages at once (vsort -r ). Requir
Ciaran McCreesh wrote:
>On Tue, 10 May 2005 21:54:33 +0100 Ciaran McCreesh <[EMAIL PROTECTED]>
>wrote:
>| Is there a standard way of handling testing for utility-type eclasses?
>| For versionator I currently have a __versionator__test_blah function
>| included in the eclass (source versionator.ecl
On Tue, May 10, 2005 at 09:54:33PM +0100, Ciaran McCreesh wrote:
> Is there a standard way of handling testing for utility-type eclasses?
> For versionator I currently have a __versionator__test_blah function
> included in the eclass (source versionator.eclass works, it doesn't have
> any portage-s
On Tue, 10 May 2005 21:54:33 +0100 Ciaran McCreesh <[EMAIL PROTECTED]>
wrote:
| Is there a standard way of handling testing for utility-type eclasses?
| For versionator I currently have a __versionator__test_blah function
| included in the eclass (source versionator.eclass works, it doesn't
| have
Is there a standard way of handling testing for utility-type eclasses?
For versionator I currently have a __versionator__test_blah function
included in the eclass (source versionator.eclass works, it doesn't have
any portage-specific code), but this is going to get a bit messy when I
add in another
47 matches
Mail list logo
