Re: Squid-2.7 release notes updated
That looks good to me. I attached a patch for 2171, will try to get it tested ASAP. On 12/03/2008, at 7:13 PM, Adrian Chadd wrote: I've updated the Squid-2.7 release notes. I'd like to release Squid-2.7.STABLE1 this weekend. Its possible my Bugzilla searches haven't turned up all of the relevant bugs to put in the release notes. Let me know if you have any objections. Thanks, Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA - -- Mark Nottingham [EMAIL PROTECTED]
Re: Time for squid 3.0 STABLE2 ?
On Mon, 2008-03-10 at 14:12 +1300, Amos Jeffries wrote: As it stands we can call one or the other an up/down and leave things as-is. I'm minded to call 2.6 a 'down' of 3.0 and 3.0/2.7/2.6 downs of 3.1. I have not looked closely at the update script to see if thats right though. As I said I don't think using the changesets as tracking method for determining what needs porting from Squid-2 to 3 is appropriate. Better to start with cf.data.pre differences between the two which should now be found in the release notes, and work from there (which secondare may include collecting relevant changesets) The changesets works for new small things (i.e. bugfixes to common code) but those have been quite faithfully ported and still are, and best tracked via bugzilla. Many of the missing features is not even found in the changesets, and often require substantial effort to port or reimplement, here the changesets is just one input. These is best tracked via the releasenotes I think, or their own branches when each effort gets started. Regards Henrik
Re: What's in the NT branch
On Tue, 2008-03-11 at 22:43 +0100, Guido Serassio wrote: This file comes from the original work of Romeo Anghelache. After some search, I have found the original one from Apache 1.3: http://svn.apache.org/viewvc/httpd/httpd/branches/1.3.x/src/os/win32/readdir.c?view=markup If I remember right, the Apache License is not good for Squid. Correct. The Apache license is GPL incompatible due to minor stupid things, but still incompatible. My final intention is to have all the code changes merged into STABLE/HEAD, but currently Squid 3.0 doesn't work at all on native Windows, so some heavy and separated development work is still need to fix all problems before any merge. That's fine. Such work should be done in a short lived development branch, and then merged upstream when it builds and runs, before the Windows release. If this first step will be successful, and I'm not so sure about this positive result , then there will the IPv6 on Windows challenge ... IPv6 on Windows is the same as above, but probably with more frequent merges to trunk. I think that a more appropriate attribute for the Windows port is too easily broken ... :-( It's a very acrobatic piece of code :-) I don't see how keeping a separate port branch helps that... it's more of a sign that something needs redesign to support windows better. What aspect of Windows do you see as the most fragile part? - integrity of tha build/make/project files? - the socket/filedescriptor emulation? - rename of open files - windows specific support features (i.e. service code, dns registry glue etc) - something else forgoten in the list above Regards Henrik
Re: Robustness project adjustments
Hi all, Alex Rousskov wrote: Hello, This email describes upcoming changes in the Squid3 robustness project. The Squid3 robustness project has two related goals: ... The current design has been disculeassed at the London meeting, and a few adjustments were requested. This email attempts to summarize the adjusted design. I have some questions about the adjustments. 1. The assert() code will not throw exceptions by default. It will continue to call abort() as before. To enable the robustness feature, a squid.conf option will need to be set. (In the future, that option may contain a date value so that it automatically disables itself if the administrator forgot to do that after fixing the problem.) As I can understand the assert() by default will abort squid as before. In async-calls branch there is the assert_burst_max configuration parameter which has a default value of 100. If set to 0 then the assert() call aborts immediately squid. Is it enough to set the default value of assert_burst_max to 0 or we need an extra configuration parameter to enable/disable the feature? 2. Assert() calls that are testing local, transaction-specific conditions will be manually converted to Must() calls. Must() always throws an exception. It is already used by the ICAP code. Must() name comes from IETF RFC MUST/SHOULD/MAY terminology. Suggestions for a better name are welcome. New code should use Must() whenever possible. Assert() with capital A it is not a different function than assert(), OK? If I am not wrong we should discover the safe cases and replace assert calls with Must() calls. Am I right? Must() call will have its current form (justs throws an exception) or will get some of the features of assert() call (eg. assert_max_burst feature) I think Must is a good name, maybe in the future a Should() call implemented which in addition allow squid to respond to the http client with messages like the 500 Internal server error etc :-) 3. Transactions that can handle exceptions with a proper cleanup will continue to handle them without aborting Squid. Other transactions will abort Squid if an exception is thrown. This design remains unchanged compared to the original version: we are changing when exceptions can be thrown, not how they are handled. OK. 4. We will continue to work on the transaction cleanup code. Corrections and improvements are welcome. Regards, Christos
Re: What's in the NT branch
Hi Henrik, At 12:59 13/03/2008, Henrik Nordstrom wrote: On Tue, 2008-03-11 at 22:43 +0100, Guido Serassio wrote: This file comes from the original work of Romeo Anghelache. After some search, I have found the original one from Apache 1.3: http://svn.apache.org/viewvc/httpd/httpd/branches/1.3.x/src/os/win32/readdir.c?view=markup If I remember right, the Apache License is not good for Squid. Correct. The Apache license is GPL incompatible due to minor stupid things, but still incompatible. So we should find another one. May be that the version included into the MinGW runtime could be fine. I will test it, but I don't know when ... My final intention is to have all the code changes merged into STABLE/HEAD, but currently Squid 3.0 doesn't work at all on native Windows, so some heavy and separated development work is still need to fix all problems before any merge. That's fine. Such work should be done in a short lived development branch, and then merged upstream when it builds and runs, before the Windows release. If this first step will be successful, and I'm not so sure about this positive result , then there will the IPv6 on Windows challenge ... IPv6 on Windows is the same as above, but probably with more frequent merges to trunk. I think that a more appropriate attribute for the Windows port is too easily broken ... :-( It's a very acrobatic piece of code :-) I don't see how keeping a separate port branch helps that... it's more of a sign that something needs redesign to support windows better. Too much times something like this is happened: - Update from CVS of my work dir - Fix of build problems - Commit of fixes - Finished the little time that I have available for development, usually during weekend - Hope to do some test/debug during the next weekend - During the next week someone commit changes in the source - Update from CVS of my work dir (again during weekend) - Fix of NEW build problems - Commit of fixes - Finished again the little time that I have available for development just for fix NEW problems . This is very disappointing and is the reason because I like to have a separated branch I think that the main problem here is that there is still only one Windows developer and this developer is not a full time developer: I'm mainly a consultant, not a developer. What aspect of Windows do you see as the most fragile part? The main problem is in the code that is touched from others developers. - integrity of tha build/make/project files? Not big problems here, usually the fix is add/remove a source file some the build project. But sometimes things was worse: i.e. the move from perl to awk for preprocessing. - the socket/filedescriptor emulation? Many times very big problems here, and also with proprietary IPC and IPv6 support. This is the section where currently Squid 3.0 is failing on Windows. I think that the forward port of the all 2.6+ related enhancements could help the Squid 3.0 Windows support. - rename of open files No problems here. - windows specific support features (i.e. service code, dns registry glue etc) Usually not so big problems here, because all the code is in Windows specific sources. - something else forgoten in the list above Different C/C++ compiler not always compatible with gcc and a totally different run time library not based on glibc and not Posix compliant. And many times this is a very big problem, true for both Visual Studio and MinGW native environments. Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
Re: What's in the NT branch
On Thu, 2008-03-13 at 20:48 +0100, Guido Serassio wrote: Too much times something like this is happened: - Update from CVS of my work dir - Fix of build problems - Commit of fixes - Finished the little time that I have available for development, usually during weekend - Hope to do some test/debug during the next weekend - During the next week someone commit changes in the source - Update from CVS of my work dir (again during weekend) - Fix of NEW build problems - Commit of fixes - Finished again the little time that I have available for development just for fix NEW problems . So why do you update your workdir if you only want to test the stuff you had last weekend? You'll get extact the same breakage when updating your branch (i.e. running cvsmerge in the CVS setup, or bzr merge in the new bzr setup), so I am sorry but I don't see why keeping a shared branch helps this. I don't mind you having as many private branches for testing as you like to support your own workflow (thats after all one of the points why we selected bzr), but I do mind having stable binary releases made from a possibly different tree, or including sources not seen in the main tree. What aspect of Windows do you see as the most fragile part? The main problem is in the code that is touched from others developers. I would say the main problem is code changes only tested on one developers platform and not Windows.. - the socket/filedescriptor emulation? Many times very big problems here, and also with proprietary IPC and IPv6 support. This is the section where currently Squid 3.0 is failing on Windows. I think that the forward port of the all 2.6+ related enhancements could help the Squid 3.0 Windows support. Which Squid-2 changes do you have in mind there? - something else forgoten in the list above Different C/C++ compiler not always compatible with gcc and a totally different run time library not based on glibc and not Posix compliant. And many times this is a very big problem, true for both Visual Studio and MinGW native environments. Yes, and this will always be seen for as long as we develop for more than one platform and compiler. But see above for my counter argument here.. Regards Henrik
Re: What's in the NT branch
On Thu, 2008-03-13 at 20:48 +0100, Guido Serassio wrote: Too much times something like this is happened: - Update from CVS of my work dir - Fix of build problems - Commit of fixes - Finished the little time that I have available for development, usually during weekend - Hope to do some test/debug during the next weekend - During the next week someone commit changes in the source - Update from CVS of my work dir (again during weekend) - Fix of NEW build problems - Commit of fixes - Finished again the little time that I have available for development just for fix NEW problems . This is very disappointing and is the reason because I like to have a separated branch Having a separate branch will not fix the above problem, it will only mask it. It is pretty much the same as if you were to stop updating from HEAD: the problems will accumulate and become more difficult to fix when you decide to merge. I think it is perfectly fine to have a private branch if you want to commit often and merge infrequently. I just would not expect that to save you time or nerve cells, unfortunately. I think that the main problem here is that there is still only one Windows developer and this developer is not a full time developer: I'm mainly a consultant, not a developer. I think the main problem is that folks committing changes have no sane way of testing those changes on Windows. We do not see Windows-specific bugs and have no sane way of detecting them. Thus, we cannot fix them. What we should probably do as a first step is to setup a Windows machine and compile Squid there as a part of nightly regression tests (and on-demand). Commits failing regression tests will be backed out. Can you provide and configure such a machine for remote ssh access to a restricted account that will run your regression test script? We can then integrate that with the Unix regression test bench. If you cannot provide the machine with remote access, can you be responsible for configuring the [virtual] machine that I will provide? If yes, please let me know what Windows version it should run and what is the best way to enable you to access it for configuration. Thank you, Alex.
Bzr commits
On Thu, 2008-03-13 at 13:49 -0600, [EMAIL PROTECTED] wrote: http://www.squid-cache.org/bugs/show_bug.cgi?id=2186 --- Comment #9 from Bernhard Schmidt [EMAIL PROTECTED] 2008-03-13 13:49:20 --- Seems to work now, thanks. Applied without changes to BZR Berni, Are you talking about some private bzr branch that you are maintaining? Or did I stop receiving emails generated by Squid commits? Do I need to subscribe somewhere to receive them? Thank you, Alex.
Re: Robustness project adjustments
On Thu, 2008-03-13 at 21:15 +0200, Tsantilas Christos wrote: 1. The assert() code will not throw exceptions by default. It will continue to call abort() as before. To enable the robustness feature, a squid.conf option will need to be set. (In the future, that option may contain a date value so that it automatically disables itself if the administrator forgot to do that after fixing the problem.) As I can understand the assert() by default will abort squid as before. Correct. In async-calls branch there is the assert_burst_max configuration parameter which has a default value of 100. If set to 0 then the assert() call aborts immediately squid. Is it enough to set the default value of assert_burst_max to 0 or we need an extra configuration parameter to enable/disable the feature? It is enough to change the default, I think. 2. Assert() calls that are testing local, transaction-specific conditions will be manually converted to Must() calls. Must() always throws an exception. It is already used by the ICAP code. Must() name comes from IETF RFC MUST/SHOULD/MAY terminology. Suggestions for a better name are welcome. New code should use Must() whenever possible. Assert() with capital A it is not a different function than assert(), OK? Same function; I should not have capitalized it, sorry. If I am not wrong we should discover the safe cases and replace assert calls with Must() calls. Am I right? Correct. Must() call will have its current form (justs throws an exception) or will get some of the features of assert() call (eg. assert_max_burst feature) Must() call retains its current form. Must() exceptions will be either handled by the current job or kill Squid. In the second case, it would be nice to print something intelligent before abort()ing, I guess. I think Must is a good name, maybe in the future a Should() call implemented which in addition allow squid to respond to the http client with messages like the 500 Internal server error etc :-) Not exactly. Should() is for proceeding further with a debugging message printed to cache.log if the condition fails. Unlike Must(), Should() returns a boolean value so that the caller can detect and handle the minor inconsistency. Should() is quite handy, but unrelated to robustness issues. May() is a no-op, just like in RFCs. 3. Transactions that can handle exceptions with a proper cleanup will continue to handle them without aborting Squid. Other transactions will abort Squid if an exception is thrown. This design remains unchanged compared to the original version: we are changing when exceptions can be thrown, not how they are handled. OK. 4. We will continue to work on the transaction cleanup code. HTH, Alex.
Re: Bzr commits
Hi Alex, http://www.squid-cache.org/bugs/show_bug.cgi?id=2186 --- Comment #9 from Bernhard Schmidt [EMAIL PROTECTED] 2008-03-13 13:49:20 --- Seems to work now, thanks. Applied without changes to BZR Are you talking about some private bzr branch that you are maintaining? Or did I stop receiving emails generated by Squid commits? Do I need to subscribe somewhere to receive them? Sorry, I think that was a misunderstanding. The patch applies fine to my local checkout (I think that means 'branch'), so there are no differences between your codebase and my local codebase (which is BZR trunk). I don't have any right to commit code to the repository and I certainly don't want or need that right :-) Bernhard
bzr commit stuff?
Has anyone actually committed to the bzr tree? I haven't seen any commit messages. adrian
Re: bzr commit stuff?
Adrian Chadd wrote: Has anyone actually committed to the bzr tree? I haven't seen any commit messages. Henrik and Robert committed the release script updates before messages were done. Since Robert said the commit messages were supposed to be done I don't think anyone has. Amos -- Please use Squid 2.6STABLE17+ or 3.0STABLE1+ There are serious security advisories out on all earlier releases.
Re: bzr commit stuff?
Amos Jeffries wrote: Adrian Chadd wrote: Has anyone actually committed to the bzr tree? I haven't seen any commit messages. Henrik and Robert committed the release script updates before messages were done. Since Robert said the commit messages were supposed to be done I don't think anyone has. Amos Just committed a trivial grammar change to the release notes. Lets see if that gets notified. Revision 8881. On a side note. Henrik, are you able to get the maintainers .update scripts pulling the changesets from bzr? I'm not here this weekend to look it over and I think the revison counter has taken a step backward between VCS so something will need to be worked out now to cope with the future overlap. Amos -- Please use Squid 2.6STABLE17+ or 3.0STABLE1+ There are serious security advisories out on all earlier releases.
Re: bzr commit stuff?
On Fri, 2008-03-14 at 12:34 +0900, Adrian Chadd wrote: Has anyone actually committed to the bzr tree? I haven't seen any commit messages. I have not committed or seen any messages either. I still need to find and read the instructions :-( Commit messages are still being sent to [EMAIL PROTECTED], right? Alex.
