On Tue, Aug 5, 2008 at 1:47 PM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-08-05 at 16:19 -0400, Michael Peters wrote:
>> We also need to think about deprecation cycles. If you deprecate a
>> feature in 1 version and then it disappears in the next then the time
>> between when my
On Tue, 2008-08-05 at 16:19 -0400, Michael Peters wrote:
> We also need to think about deprecation cycles. If you deprecate a
> feature in 1 version and then it disappears in the next then the time
> between when my code works and when it doesn't is only 6 months. Some
> distros provide support
On Tuesday 05 August 2008 13:19:52 Michael Peters wrote:
> If you deprecate a
> feature in 1 version and then it disappears in the next then the time
> between when my code works and when it doesn't is only 6 months. Some
> distros provide support for several years.
If they want to support ancien
On Tuesday 05 August 2008 13:14:27 Geoffrey Broadwell wrote:
> > I can see patching the previous release in case of a critical bugfix, but
> > if we get in the habit of encouraging users to expect updates of anything
> > older than the previous stable release for free, we've doomed the
> > project
On Aug 5, 2008, at 3:46 PM, Geoffrey Broadwell wrote:
On Tue, 2008-08-05 at 11:19 -0400, Jesse Vincent wrote:
["branch" feature]
This sounds very useful. Is the SVK paradigm changing so that online
use is assumed, and offline is a mode to switch to temporarily?
No. But that's a common eno
Geoffrey Broadwell wrote:
Complete and
utter refusal to support users who expect that they can install Parrot 1.0
and get free support from the mailing list or IRC for the next eight to ten
years.
Half agree. I agree that we should only *directly* support a release
for a limited time, thoug
On Tue, 2008-08-05 at 12:54 -0700, chromatic wrote:
> On Tuesday 05 August 2008 12:35:50 Geoffrey Broadwell wrote:
> > bugfixes that should be backported to one or more already released
> > versions and re-released immediately.
>
> I can see patching the previous release in case of a critical bugfi
work, and why
feature-based releases don't work.)
> However, I'm against the practice of branching before release to
> "stabilize" an assumed-crazy trunk. I prefer the (general) way we do
> things now: releases are made from the trunk code, which is kept as
> high-quali
On Tue, 2008-08-05 at 11:19 -0400, Jesse Vincent wrote:
> ["branch" feature]
This sounds very useful. Is the SVK paradigm changing so that online
use is assumed, and offline is a mode to switch to temporarily? I'm
used to thinking of SVK in one two ways:
1. As a better SVN client for normal
branches. Of course, you can branch lazily, since releases
are tagged. But we have to assume that there *will* be multiple
long-lived branches that won't merge and go away.
However, I'm against the practice of branching before release to
"stabilize" an assumed-crazy trunk. I
On Tue, Aug 5, 2008 at 1:10 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Tuesday 05 August 2008 09:48:22 Will Coleda wrote:
>
>> Branches that don't rebase from trunk regularly are out of
>> touch, yes. If you rebase regularly, then you're basically just a
>> patch waiting to be applied.
> ... an
On Tuesday 05 August 2008 09:48:22 Will Coleda wrote:
> Branches that don't rebase from trunk regularly are out of
> touch, yes. If you rebase regularly, then you're basically just a
> patch waiting to be applied.
... and, as time goes by, an ever-larger patch waiting to land on trunk with a
big
On Tue, Aug 5, 2008 at 12:16 PM, Andy Lester <[EMAIL PROTECTED]> wrote:
>
> On Aug 5, 2008, at 11:12 AM, chromatic wrote:
>
>> Don't use long-lived branches. The smaller the merge in *any* system, the
>> easier it is.
>
>
> I agree 100%. If you think your project is so big that you have to have a
On Aug 5, 2008, at 11:12 AM, chromatic wrote:
Don't use long-lived branches. The smaller the merge in *any*
system, the
easier it is.
I agree 100%. If you think your project is so big that you have to
have a long-lived branch, then it should be broken up into smaller,
mergeable miles
our community used svk for a while; I think the usage
> there has dropped off as git is the new shiny. My usage of svk was for
> local branching; I couldn't easily share my work in progress with the
> community.
>
> Does anyone have *any* recommendations? (including: you'
On Aug 5, 2008, at 11:50 AM, Reini Urban wrote:
2008/8/5 Will Coleda <[EMAIL PROTECTED]>:
So these branch commands actually create branches on the svn
repository that's doing the hosting, so they're defacto shared with
the community in the obvious location? (presuming you're online and
pushing
--- Begin Message ---
Will Coleda wrote:
On Tue, Aug 5, 2008 at 11:04 AM, Kevin Tew <[EMAIL PROTECTED]> wrote:
Git is really nice for:
local branches,
This is on par with svk...
frequently(daily) rebasing local branches to keep in sync with HEAD,
How does this work?
2008/8/5 Will Coleda <[EMAIL PROTECTED]>:
> So these branch commands actually create branches on the svn
> repository that's doing the hosting, so they're defacto shared with
> the community in the obvious location? (presuming you're online and
> pushing changes back?)
>
> That seems to be the best
On Aug 5, 2008, at 11:32 AM, Will Coleda wrote:
[SVK 2.2]
Sounds spiffy.
So these branch commands actually create branches on the svn
repository that's doing the hosting, so they're defacto shared with
the community in the obvious location? (presuming you're online and
pushing changes back?
ches which are long lived, and doing the svn
>> merge either way is extremely slow.
>>
>> I know much of our community used svk for a while; I think the usage
>> there has dropped off as git is the new shiny. My usage of svk was for
>> local branching; I couldn't easily s
le; I think the usage
there has dropped off as git is the new shiny. My usage of svk was for
local branching; I couldn't easily share my work in progress with the
community.
Not that I'm biased, but
SVK 2.2b1 is out today. It contains many, many bugfixes and
performance imp
>> merge either way is extremely slow.
>>
>> I know much of our community used svk for a while; I think the usage
>> there has dropped off as git is the new shiny. My usage of svk was for
>> local branching; I couldn't easily share my work in progress with the
>
ge of svk was for
local branching; I couldn't easily share my work in progress with the
community.
Does anyone have *any* recommendations? (including: you're doing the
merge wrong).
I'm bccing the current svn admins to find out if they have any ideas as well.
Would an upgrade on th
e new shiny. My usage of svk was for
local branching; I couldn't easily share my work in progress with the
community.
Does anyone have *any* recommendations? (including: you're doing the
merge wrong).
I'm bccing the current svn admins to find out if they have any ideas as well.
Wou
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
On Mar 29, 2007, at 10:14 PM, Will Coleda wrote:
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
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
ok. This is basically a followup to discussions that have
occurred on #parrot and pp - what are our expectations about trunk in
terms of stability? how can we use branching and tools to support these
expectations?
the outline of the various topics is on the wiki.
(and I have
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Since I'm about to start in on some of the Irrevocable Changes (or
> something like that) to the string system with the new
> encoding/charset stuff, I tagged CVS and will be working in a branch
> (I hope).
> If you feel like watching or playing along at h
Since I'm about to start in on some of the Irrevocable Changes (or
something like that) to the string system with the new
encoding/charset stuff, I tagged CVS and will be working in a branch
(I hope).
If you feel like watching or playing along at home, the branch is
"pluggable_encodings", assu
Will Coleda via RT wrote:
Status: resolved
Not really. Resolved on one JIT platform.
leo
On Saturday 02 October 2004 13:10, Stephane Peiry wrote:
> This patch adds tests for is style ops (isgt, isge, isle, islt,
> iseq, isne) on integers, numbers and strings, in t/op/comp.t.
Thanks, applied.
jens
Stephane Peiry <[EMAIL PROTECTED]> wrote:
> These two patches add jit support for is style ops (isgt,
> isge, isle, islt, iseq, isne) on integers for the sun/sparc platform.
Thanks, applied.
leo
Sorry the previous core.jit patch for sun contained a typo. The correct
patch file is attached here again.
Thanks!
Stephane
On Sun, Sep 26, 2004 at 02:40:29AM -0700, Leopold Toetsch wrote:
> The integer and number variants of these opcodes could need JIT support.
Index: jit/sun4/core.jit
These two patches add jit support for is style ops (isgt, isge, isle,
islt, iseq, isne) on integers for the sun/sparc platform.
The jitted code follows this "pattern":
cmp %r2, %r3
b,a next
mov 1, %r1
mov 0, %r1
next: ..
defining th
This patch adds tests for is style ops (isgt, isge, isle, islt,
iseq, isne) on integers, numbers and strings, in t/op/comp.t.
Thanks,
Stéphane
PS.: maybe t/op/*.t could be reorganized so that test filenames match
what is under ops/*.ops? and t/op would test only I, N, and S stuff,
leaving any P
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #31725]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31725 >
I've moved these opcodes to ops.num and added some missing variants.
These opcode
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #31726]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31726 >
The integer and number variants of these opcodes could need JIT support.
Thanks,
52 matches
Mail list logo
