Re: [squid-core] v3 roadmap
On Sun, 2008-03-23 at 15:24 +1300, Amos Jeffries wrote: > Henrik Nordstrom wrote: > > On Wed, 2008-03-19 at 11:15 +1300, Amos Jeffries wrote: > > > >> - I'm kind of in favour of it as a pure file-movements-only > >> alteration. 3.2 has no feature-requests yet and back-porting across a > >> file-re-arranged setup is likely to be more trouble than its worth. > > > > bzr tracks renames and merges changes across them fine. bzr operates > > using abstract file identifiers, separate from the file names. > > > > you only run into trouble from tree reshuffles if you split/merge files, > > or don't tell bzr that you are renaming a file.. > > > > bzr help mv > > > > Well, in light of that I don't have any objections to starting the > re-ordering now. OK. My plan is to publish the first eCAP-related changes for review and then start working on a cleanup patch. > I'd like to be closely involved though to get my head around the changes. Sure. Please review the source cleanup feature and raise any objections. I will start with the big changes already listed there, I guess. Let's move further discussions, if any to squid-dev. Thank you, Alex.
Re: [squid-core] v3 roadmap
Henrik Nordstrom wrote: On Wed, 2008-03-19 at 11:15 +1300, Amos Jeffries wrote: - I'm kind of in favour of it as a pure file-movements-only alteration. 3.2 has no feature-requests yet and back-porting across a file-re-arranged setup is likely to be more trouble than its worth. bzr tracks renames and merges changes across them fine. bzr operates using abstract file identifiers, separate from the file names. you only run into trouble from tree reshuffles if you split/merge files, or don't tell bzr that you are renaming a file.. bzr help mv Well, in light of that I don't have any objections to starting the re-ordering now. I'd like to be closely involved though to get my head around the changes. Amos -- Please use Squid 2.6STABLE17+ or 3.0STABLE1+ There are serious security advisories out on all earlier releases.
Re: [squid-core] v3 roadmap
Alex Rousskov wrote: On Wed, 2008-03-19 at 11:15 +1300, Amos Jeffries wrote: The file re-arranging polish: - I'm kind of in favour of it as a pure file-movements-only alteration. 3.2 has no feature-requests yet and back-porting across a file-re-arranged setup is likely to be more trouble than its worth. Can you clarify the above? I am not disagreeing, but am not sure whether you are saying we should move/rename files in 3.1. I want to see it done in 3.1, but I'd personally prefer it happens close to the 3.0/3.1 switchover. ie the last changes to go in. The maintainer hat on me thinks that if its not done in 3.1, I might be back-porting stuff for a while until 3.2 is worked out. For that whole as-yet-undefined period I don't want to be re-arranging patches because the files are in different places. Likewise from the point its done to the point we release 3.1 and close 3.0 series off I'll be doing the same downwards anyway. I'd like both periods of trouble to be as short as possible. - If you think you can get it done in a reasonable timespan to get done by the RC releases great. I don't think the PRE need to wait for it, its polish after all not a true feature. - It is your baby though. Understood. If you have the resources to move a few 2.6 features to 3.1 they should be timelined by 31 March or officially shifted to 3.2 pending later re-evaluation. Yes? Agreed. I am still evaluating what needs to be ported and whether the Factory can sponsor any of that. Thank you, Alex. Amos -- Please use Squid 2.6STABLE17+ or 3.0STABLE1+ There are serious security advisories out on all earlier releases.
Re: [squid-core] v3 roadmap
On Wed, 2008-03-19 at 11:15 +1300, Amos Jeffries wrote: > - I'm kind of in favour of it as a pure file-movements-only > alteration. 3.2 has no feature-requests yet and back-porting across a > file-re-arranged setup is likely to be more trouble than its worth. bzr tracks renames and merges changes across them fine. bzr operates using abstract file identifiers, separate from the file names. you only run into trouble from tree reshuffles if you split/merge files, or don't tell bzr that you are renaming a file.. bzr help mv Regards Henrik
Re: [squid-core] v3 roadmap
On Wed, 2008-03-19 at 11:15 +1300, Amos Jeffries wrote: > The file re-arranging polish: > - I'm kind of in favour of it as a pure file-movements-only > alteration. 3.2 has no feature-requests yet and back-porting across a > file-re-arranged setup is likely to be more trouble than its worth. Can you clarify the above? I am not disagreeing, but am not sure whether you are saying we should move/rename files in 3.1. > - If you think you can get it done in a reasonable timespan to get > done by the RC releases great. I don't think the PRE need to wait for > it, its polish after all not a true feature. > - It is your baby though. Understood. > If you have the resources to move a few 2.6 features to 3.1 they should > be timelined by 31 March or officially shifted to 3.2 pending later > re-evaluation. Yes? Agreed. I am still evaluating what needs to be ported and whether the Factory can sponsor any of that. Thank you, Alex.
Re: [squid-core] v3 roadmap
Amos Jeffries wrote: Alex Rousskov wrote: On Wed, 2008-03-19 at 00:25 +1300, Amos Jeffries wrote: I'm looking forward a few weeks to 3.0.STABLE3 by march 31st Great! Possibly even a 3.1.DEVEL0 at the same time. This should probably be discussed on squid-dev, but there are currently several projects on the TODO list that may not be committed until March 31st. There is even a project with unknown ETA, which is a violation of the TODO list definition! Also, what about the /Features/SourceLayout cleanup project? Should that wait for 3.2? Finally, if we have the resources to include a few missing Squid2 features into Squid3, should v3.1 wait for that? Our initial agreed time-plan called for an initial release around 31 March. I was thinking PRE at that time, but as Henrik suggested there is DEVEL for feature-incomplete releases to keep things relatively to plan. Hopefully we can ge the PRE1 out sooner, but any release of the for wider testing on time is better than long delays. For the unknown, thats fixed. I'm sponsoring it. But have not heard back from Adrian whether he wants to take the money and do it to be added to -3. Amos Oops, meat to do the squid-dev move on that. As for the cleanup... .h cleanup: - going in next time I have a spare minute to check for tweaks. The file re-arranging polish: - I'm kind of in favour of it as a pure file-movements-only alteration. 3.2 has no feature-requests yet and back-porting across a file-re-arranged setup is likely to be more trouble than its worth. - If you think you can get it done in a reasonable timespan to get done by the RC releases great. I don't think the PRE need to wait for it, its polish after all not a true feature. - It is your baby though. If you have the resources to move a few 2.6 features to 3.1 they should be timelined by 31 March or officially shifted to 3.2 pending later re-evaluation. Yes? - I've added the LogDaemon as one such, I can do at a pinch. Amos -- Please use Squid 2.6STABLE17+ or 3.0STABLE1+ There are serious security advisories out on all earlier releases.
