Re: [PROPOSAL] 3.3.x "release" processes

On 6/8/12 10:06 PM, Leif Hedstrom wrote: On 6/8/12 7:30 PM, Bryan Call wrote: I agree with John, I would rather only have and work on trunk and then make a branch two weeks before a release. 1. Two weeks before a dev release, we "git rebase" the 3.3.x branch from master. Forgot to include

Re: [PROPOSAL] 3.3.x "release" processes

On 6/8/12 7:30 PM, Bryan Call wrote: I agree with John, I would rather only have and work on trunk and then make a branch two weeks before a release. Including feature freezing the trunk (master) for those 2 weeks? My proposal was what you said, I think, but maybe I misunderstood? In my prop

Re: [PROPOSAL] 3.3.x "release" processes

I agree with John, I would rather only have and work on trunk and then make a branch two weeks before a release. As for having full patches in Jira, I would think commit messages should be used from trunk inside of Jira. This way we know the fix also went into trunk. -Bryan On Jun 8, 2012, at

Who's using ATS

Thanks to Daniel, we now have: http://trafficserver.apache.org/users.html If anyone would like to be added to this, please let us know (make sure you get approval from your corp / legal). Cheers, -- Leif

Re: [PROPOSAL] 3.3.x "release" processes

On 6/8/12 5:16 PM, Nick Kew wrote: 1. We formalize a strong development plan for 3.4, and we try to stick to it. We tried this, very loosely with 3.0 and 3.2, and we failed miserable. For v3.4, to meet a ~6 month release cycle, we have to reduce the number of feature additions t

Re: [PROPOSAL] 3.3.x "release" processes

On Fri, 08 Jun 2012 16:22:48 -0600 Leif Hedstrom wrote: > Hi all, > > after our mini-fiasco with 3.1.4, and the delays of 3.2 in general, I'd > like to propose a few changes to our development release processes. John > made some suggestions here, which I'm formulating in this proposal. > > Pl

Re: [PROPOSAL] 3.3.x "release" processes

I like this proposal, but I would rather not have a 3.3.x and just freeze the trunk and only allow commits from patches attached in jira. This would add extra incentive to get the release out and not check in buggy stuff to near that date as all your commits will have to go through jira. john On

[PROPOSAL] 3.3.x "release" processes

Hi all, after our mini-fiasco with 3.1.4, and the delays of 3.2 in general, I'd like to propose a few changes to our development release processes. John made some suggestions here, which I'm formulating in this proposal. Please discuss. And yes, we will update the release process on the Wiki

attribute T and tunnelling

Hi, (I checked the forums - apologies if I missed this somewhere already) I had a quick question on what the use case is for configuring ATS with attribute 'T' i.e. This attribute SERVER_PORT_BLIND_TUNNEL is only set when configured with 'T' which implies HandleBlindTunnel the main tunnelling

Re: [SUGGESTIONS] s/-unstable/-dev/ for 3.3.x release cycle

On 6/8/12 3:01 PM, James Peach wrote: On Jun 8, 2012, at 12:29 PM, Leif Hedstrom wrote: I'd like to suggest that starting with v3.3.0, we make our development releases named e.g. trafficserver-3.3.0-dev Any objections? The reason is that "unstable" has bad connotation in the communitie

Re: [SUGGESTIONS] s/-unstable/-dev/ for 3.3.x release cycle

On Jun 8, 2012, at 12:29 PM, Leif Hedstrom wrote: > I'd like to suggest that starting with v3.3.0, we make our development > releases named e.g. > >trafficserver-3.3.0-dev > > > Any objections? The reason is that "unstable" has bad connotation in the > communities in general, and corporat

Re: [SUGGESTIONS] s/-unstable/-dev/ for 3.3.x release cycle

Good idea. +1 from me. --Original Message-- From: Leif Hedstrom To: dev@trafficserver.apache.org To: 'us...@trafficserver.apache.org' ReplyTo: us...@trafficserver.apache.org Subject: [SUGGESTIONS] s/-unstable/-dev/ for 3.3.x release cycle Sent: Jun 9, 2012 02:29 I'd like to suggest that s

[SUGGESTIONS] s/-unstable/-dev/ for 3.3.x release cycle

I'd like to suggest that starting with v3.3.0, we make our development releases named e.g. trafficserver-3.3.0-dev Any objections? The reason is that "unstable" has bad connotation in the communities in general, and corporations in particular. And we really want people to have the guts t

RE: syn flooding

I could not find this variable in records.config proxy.config.net.listen_backlog Thanks & Regards Saraswathi Venkataraman | Xoriant Solutions Pvt. Ltd. Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA. Tel: +91 22 30511000 | Ext: 1113 | http://www.xoria