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
On Tuesday 05 August 2008 12:35:50 Geoffrey Broadwell wrote:
> We will definitely need multiple long-lived branches. Just to make
> explicit the reasoning: data loss, security, or otherwise critical
> bugfixes that should be backported to one or more already released
> versions and re-released im
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
On Tue, 2008-08-05 at 13:20 -0400, Will Coleda wrote:
> On Tue, Aug 5, 2008 at 1:10 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > Gah, no maintenance releases please! See "Mommy, why did it take over five
> > years to release a new stable version of Perl 5 with a bugfix I made in
> > 2002?"
>
> Per
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
On Tuesday 05 August 2008 07:51:35 Will Coleda wrote:
> Using svn as a backing store, how can we more easily work with long
> lived branches?
>
> I've some existing branches which are long lived, and doing the svn
> merge either way is extremely slow.
>
> I know much of our community used svk for
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?
On Tue, Aug 5, 2008 at 11:19 AM, Jesse Vincent <[EMAIL PROTECTED]> wrote:
>
> On Aug 5, 2008, at 10:51 AM, Will Coleda wrote:
>
>> Using svn as a backing store, how can we more easily work with long
>> lived branches?
>>
>> I've some existing branches which are long lived, and doing the svn
>> merg
On Aug 5, 2008, at 10:51 AM, Will Coleda wrote:
Using svn as a backing store, how can we more easily work with long
lived branches?
I've some existing branches 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 thin
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? What's the pain threshold?
>publishing local branches
Git is really nice for:
local branches,
frequently(daily) rebasing local branches to keep in sync with HEAD,
publishing local branches for others to review,
allowing non-committers to make changes and publish those changes
publicly
Kevin
Will Coleda wrote:
Using svn as a backi
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
24 matches
Mail list logo