Hello,
The discussion on smoking and branching is driven by the need to maintain
quality across a wide
range of compilers and "target"(1) machines. I would add a couple of points.
0. When working through the review process the tool I wanted the most was a
simple way
to test cros
On Friday 30 March 2007 09:36, Nicholas Clark wrote:
> An alternative is to have C be an alias, either to C devtest> by default, and a smaller C (or somesuch) when the
> source tree is an official release. Having the source tree know when it's
> an official release (perhaps by including or not inc
On Fri, Mar 30, 2007 at 08:58:19AM -0700, Allison Randal wrote:
> I concur that the user shouldn't get failing tests for things like
> whitespace at the end of lines. More importantly, the user shouldn't be
> wasting time running tests for coding standards and documentation. How
> about a 'make
Will Coleda wrote:
So lets document what we need. Right now 'make smoke' generates an HTML
report which is uploaded to the smoke server.
Talk has happened in the past about making this more DB like instead of
rendered output, but my concern is for the user visible features we're
lacking. Perh
jerry gay wrote:
Should we even require all of these tests to be ran by default? These
tests should never fail for a user compiling a release version of
parrot, so should they need to test them? They're good for developers,
but only developers.
until we stop actively developing major subsyst
On 3/29/07, Joshua Isom <[EMAIL PROTECTED]> wrote:
On Mar 29, 2007, at 4:20 PM, jerry gay wrote:
> On 3/29/07, Nicholas Clark <[EMAIL PROTECTED]> wrote:
>> > and i'm not interested in testing every
>> revision,
>> > when so many might be coding standards
>>
>> Why are people ev
On Mar 29, 2007, at 4:20 PM, jerry gay wrote:
On 3/29/07, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> and i'm not interested in testing every
revision,
> when so many might be coding standards
Why are people even checking things in that fail coding standards?
because not a
On Thursday 29 March 2007 23:03, Joshua Isom wrote:
> One other thing I've noticed is that todo tests sometimes become
> forgotten tests. And since they're sometimes platform specific, they
> don't get fixed for that platform because feature x doesn't have the
> code support. Other than doing a
Easily compare different revisions of one platform, and two
platforms with near revisions, since unless we get cluster of very
heterogeneous computers, we must rely on user submissions. Updates to
languages/ don't really matter unless you're smoking languages for
instance, and sometimes a
On Mar 27, 2007, at 4:45 PM, Allison Randal wrote:
but, we need better smoke tools
So lets document what we need. Right now 'make smoke' generates an
HTML report which is uploaded to the smoke server.
Talk has happened in the past about making this more DB like instead
Eric Hanchrow wrote:
Here's the relevant bits from my
config file:
[miscellany]
### Set enable-auto-props to 'yes' to enable automatic properties
### for 'svn add' and 'svn import', it defaults to 'no'.
### Automatic properties are defined in the section 'auto-props'.
enable-
Eric Hanchrow wrote:
Here's the relevant bits from my
config file:
[miscellany]
### Set enable-auto-props to 'yes' to enable automatic properties
### for 'svn add' and 'svn import', it defaults to 'no'.
### Automatic properties are defined in the section 'auto-props'.
enable-
> "chromatic" == chromatic <[EMAIL PROTECTED]> writes:
chromatic> The line-ending coding standards tests can be a problem
chromatic> in some cases, where Windows developers add new files
chromatic> with their native format and forget to set the
chromatic> svn:eol-style=native
> > and i'm not interested in testing every revision,
> > when so many might be coding standards
> Why are people even checking things in that fail coding standards?
The line-ending coding standards tests can be a problem in some cases, where
Windows developers add new files with t
On 3/29/07, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> and i'm not interested in testing every revision,
> when so many might be coding standards
Why are people even checking things in that fail coding standards?
because not all coding standard tests are run with 'make test'
On Thursday 29 March 2007 13:05, Nicholas Clark wrote:
> I don't think that the stable/development spit in Perl 5 land is broken.
> There is a problem that there aren't enough people with good enough
> knowledge to be committers, and in particular to want to review and apply
> patches supplied by
On Tue, Mar 27, 2007 at 01:45:57PM -0700, Allison Randal wrote:
> It works OK if everyone agrees that one ( or a very
> few) access the maintanence branch
> How many branches are we talking about 1,2 or 10 ?
>Steve_p, I think Nicholas might disagree that
then we can do that prior to release day
particle: not the latest revision?
The fewer changes between smokes, the better... but being
able to narrow a failure down to a particular range (10 commits perhaps)
is better than what we have now.
every build lets
: "vtable_ops.c", line 67: error 1534: Illegal to use a function pointer as "+"
operand where an arithmetic type is required.
cc: "vtable_ops.c", line 67: error 1533: Illegal function call.
make: *** [vtable_ops.o] Error 1
l1:/pro/3gl/CPAN/parrot-current 105 >
These are the minimal fixes for smoking to take effect.
After these are in, I'll release Parrot::Smoke
* Makefile.in
* it is $(INC)/config.h, not config.h
* .o => $(O)
* test_main.c
* _read was ok when it was inside
ifdef WIN32
now it must be read ( or it
20 matches
Mail list logo
