Re: AW: future of icap-patch
Baumgaertel Oliver wrote: Same procedure as last time... It won't patch against the normal STABLE9 branch. What is exactly what I was talking about in the first place. It's no use if we can't run the patch at least against ones that were already introduced some time ago... Ok, but this happens because the icap patch was not stable enough when the STABLE9 was released (still is not) , so it was not make sense to produce a squid-icap-2.5-STABLE9 version because it does not work well. Since STABLE9 was released I corrected a number of bugs, and it was not easy for me, I am not as experianced are the other squid developers, here. In the other hand we must follow the squid development, when the icap patch will be stable maybe the squid has reach the STABLE55 release.. The new version for squid planned for 8 May. If the icap patch looks enough stable, we can freeze a patch release for squid-icap, and why not, make a squid-icap-2.5.STABLE10.tgz file distribution. .And the only way around that is to get it into the main branch. As long as we need the main part of the time to get it into the current code at all it's not possible to really improve its condition. Henrik explained to us the development status of squid. I want to see an icap client in squid3. If someone starts the development of it, I will try to help. But, for my point of view, this is the only I can do in this phase Regards Christos
Re: AW: future of icap-patch
On Tue, 3 May 2005, Baumgaertel Oliver wrote: Well Henrik, that was my point exactly. The problem I have with that is plain and simple. Squid 3 is in development since what, 3 years now? It'll take at least another year to get it into a usable, complete release. Yes. Not the proudest release cycle, but these things happens. Then I'll have most likely to wait another half year until I can introduce it as a test version on one server of the main farm. And then I'll get permission to invest work into it to add the features we need or to fix issues we'll encounter. Then you will always be in a tricky position as your development will be based on a version in freezed state where no new additions will be allowed in. New additions is only allowed in the development phase of the release cycle. After a version has gone into the STABLE state of it's development cycle no new features is allowed in. If you finish your development reasonaly recent after the STABLE1 release then chances are high that it can get quite easily merged into the development version, but the more time which passes after the STABLE1 release the higher the risk that there will be significant amount of work to merge your developments into the current version. But I do not think we will see as large changes as in the Squid-2.X -> Squid-3.X in a long while to come. Besides, last time I looked the documentation of 3 was just as bad as the one 2 has. Squid-3 has somewhat better documentation than Squid-2 as each section restructured has had it's documentation updated/written, but there obviously is large gaps. However I put it, I am on the loosing end. I could start to write an icap version for S3, but I have also to make that same code run in S2. Perhaps I can give persuading my employer another shot to go with the current version as is and letting me concentrate on S3 as I originally intended in the first place. But given the current time frame I'd have a better chance to get the clearance for a complete own proxy project. To put things simple: Squid-3 needs more people looking at it for Squid development to move forward in a reasonable pace. Frankly until this happens we are all at the loosing end. The current state is that the main Squid project is currently 2 persons working actively some hours a week, one on Squid-3 (Guido) and one on Squid-2.5 (myself) plus some persons working an hour here or there. Then there is a handful independent developers working on a certain development feature of their interest. Regards Henrik
Re: future of icap-patch
On Mon, 2 May 2005, Joe Cooper wrote: Though there have been occasions where a new branch was started just to "keep up" with what a side project was doing. Sometimes those branches get merged into the next development release, either by someone else, or the same person that started the branch. True, but due to the amount of difference between Squid-2.5 and Squid-3 in the areas touched by ICAP I am not sure there is much value in yet another one given the two branches already existing. But, Henrik is the boss of devel.squid-cache.org, so my opinion is moot. Opinions are very much welcome. And I prefer to see myself as the guardian of devel.squid-cache.org rather than boss. Regards Henrik
Re: future of icap-patch
Hi, Ok the news for icap-patch for squid are not good. I am putting some effort and I believe that day by day will become more stable. Baumgaertel Oliver wrote: I've taken a look at 2.5.STABLE9 and managed sofar to apply all the patches but the 2Gig one to this combination, creating a thing that crashes sometimes 3 times within one hour. For us I am sure that the most of crashes came from the icap patch. Try the latest icap patch (last week) it corrects some of the most often crashes. The latest reports, said that squid-icap was worked for more than 50 hours without problem on a busy proxy server. It is not good but it is better that the 3 times per hour. (After these hours just stopped to talk to the icap server, maybe a problem within the icap server query code, if you are looking for bugs :-) ) However I put it, I am on the loosing end. I could start to write an icap version for S3, but I have also to make that same code run in S2. My opinion is that the icap-client for squid3 must start from scratch. Forget the current code for squid 2. It is problematic. I had thoughts about starting an icap client for squid3 but in practice I have not the time to do. Moreover I believe that this project must start by a person who has a clear view of squid design, in order to prevent in squid3 the problems which has the current squid-icap. For squid2, you have to report bugs and send patches, which corrects some of the problems, until the version for squid3 will be available. For squid 2 maybe I can report some tests which can be done, for someone who looking for bugs in squid-icap and I have in my mind some pieces of code which must be rewritten in order to make squid-icap faster and more stable. Regards, Christos
AW: future of icap-patch
>>> Baumgaertel Oliver wrote: >>> I do understand that there were a couple of people in the past asking >>> for exactly that and it was denied. I am currently in the position to >>> have the freedom to start a new icap code project. But before I dive >>> headfirst into it, I'd ask if it is at all possible to make it a part >>> of the mainline once it reaches a certain maturity and if so, what do >>> I have to do for it. >> Henrik Nordstrom wrote: >> For it to get included it must be to the development version of Squid, >> i.e. Squid-3. >> >> Squid-2.5 is in it's STABLE cycle where only bugfixes is accepted. No >> new features is accepted except as required to address security issues. > Joe Cooper wrote: > Though there have been occasions where a new branch was started just to > "keep up" with what a side project was doing. Sometimes those branches > get merged into the next development release, either by someone else, or > the same person that started the branch. > > But, Henrik is the boss of devel.squid-cache.org, so my opinion is moot. > Just mentioning what has been known to happen in the past... Well Henrik, that was my point exactly. The problem I have with that is plain and simple. Squid 3 is in development since what, 3 years now? It'll take at least another year to get it into a usable, complete release. Then I'll have most likely to wait another half year until I can introduce it as a test version on one server of the main farm. And then I'll get permission to invest work into it to add the features we need or to fix issues we'll encounter. Besides, last time I looked the documentation of 3 was just as bad as the one 2 has. However I put it, I am on the loosing end. I could start to write an icap version for S3, but I have also to make that same code run in S2. Perhaps I can give persuading my employer another shot to go with the current version as is and letting me concentrate on S3 as I originally intended in the first place. But given the current time frame I'd have a better chance to get the clearance for a complete own proxy project.
Re: future of icap-patch
Henrik Nordstrom wrote: On Mon, 2 May 2005, Baumgaertel Oliver wrote: I do understand that there were a couple of people in the past asking for exactly that and it was denied. I am currently in the position to have the freedom to start a new icap code project. But before I dive headfirst into it, I'd ask if it is at all possible to make it a part of the mainline once it reaches a certain maturity and if so, what do I have to do for it. For it to get included it must be to the development version of Squid, i.e. Squid-3. Squid-2.5 is in it's STABLE cycle where only bugfixes is accepted. No new features is accepted except as required to address security issues. Though there have been occasions where a new branch was started just to "keep up" with what a side project was doing. Sometimes those branches get merged into the next development release, either by someone else, or the same person that started the branch. But, Henrik is the boss of devel.squid-cache.org, so my opinion is moot. Just mentioning what has been known to happen in the past...
Re: future of icap-patch
On Mon, 2 May 2005, Baumgaertel Oliver wrote: I do understand that there were a couple of people in the past asking for exactly that and it was denied. I am currently in the position to have the freedom to start a new icap code project. But before I dive headfirst into it, I'd ask if it is at all possible to make it a part of the mainline once it reaches a certain maturity and if so, what do I have to do for it. For it to get included it must be to the development version of Squid, i.e. Squid-3. Squid-2.5 is in it's STABLE cycle where only bugfixes is accepted. No new features is accepted except as required to address security issues. Regards Henrik
future of icap-patch
Hi all. My company uses squid with ntlm and icap. That's a very unlucky combination I understand, as the history tells us that it's an unstable one. I've managed to fix or work around the various assertions in 2.5.STABLE6, so that we can be sure it's not crashing. You see, our farms are the frontend for roughly 40K users these days and without my work it wasn't that unusual for up to 70% of the servers to go down at once (round robin load balancer outside our jurisdiction). I've taken a look at 2.5.STABLE9 and managed sofar to apply all the patches but the 2Gig one to this combination, creating a thing that crashes sometimes 3 times within one hour. For us that's of course not acceptable. I do know roughly where the reason lies, but I am not willing to invest any work into it as long as the patch is not going to be part of the main squid code. Why? Because I have to go through the same nightmare everytime a needed patch comes along. I do understand that there were a couple of people in the past asking for exactly that and it was denied. I am currently in the position to have the freedom to start a new icap code project. But before I dive headfirst into it, I'd ask if it is at all possible to make it a part of the mainline once it reaches a certain maturity and if so, what do I have to do for it. If there's no way anyway, I'd write it in a way convenient for me and my company alone, skipping tedious tasks like keeping the code portable. In such a case... What about building an interface into squid that allows to add functionality like the ones icap offers? It'll prevent at least that any additional code will have to break the rest of the code. Regards, Oliver Baumgaertel
