Re: IPv6 developments for HEAD
Alex Rousskov wrote: On Wed, 2007-04-11 at 11:41 +1200, [EMAIL PROTECTED] wrote: On Sat, 2007-04-07 at 17:24 +1200, Amos Jeffries wrote: Attached are two patches which constitute part of the core developments for protocol-independent handling of IP addresses in squid3. In your opinion, should these be committed to Squid 3.0? Are they likely to cause short-term stability problems? Should they be applied to Squid 3.1 instead? Thank you, Alex. Yes. No. both?. I would like to see them in 3.0. The new object I am submitting is isolated 'infrastructure' which does not affect the rest of squid in any way. It is itself the stable base needed for future work. Interesting. If IPAddress is not used by Squid before and after your patch, is there a reason to commit it now? Originally, I thought that you are modifying common code and want to commit ASAP to minimize future conflicts. Now I understand that IpAddress addition does not alter anything in Squid core (and you are not asking to commit the rest of your changes, which do). On one hand, I am tempted to vote immediate inclusion of IPAddress simply to satisfy a valuable developer. On the other hand, I do not understand why you want that file to be in HEAD if nothing is using it. Could you please clarify why you want to see IPAddress in HEAD? Currently the branch is looking at nearly 5500 lines of code changed. With nearly 3000 lines removed from the core of squid so far. In complete agreement with Henrik and Adrians views that stability in 3.0 should not be risked. I am nevertheless trying to drop that huge difference in 'small' discrete isolated chunks. I have managed to find 3 areas that will do a large amount of reduction without changing or touching the core code in any way. RFCs were step 1. IPAddress is step 2. A new rfc3596 (DNS) library based non the RFCs is a third, but that still needs major testing and is weeks away I think. When the 'non-changes' are out of the branch and in HEAD waiting to be used. The actual core changes can push ahead cleanly for IPv6 in 3.1, both inside my branch and in any others who want to jump for the new ability while HEAD is closed to them. Amos
Re: IPv6 developments for HEAD
On Wed, 2007-04-11 at 23:19 +1200, Amos Jeffries wrote: Currently the branch is looking at nearly 5500 lines of code changed. With nearly 3000 lines removed from the core of squid so far. In complete agreement with Henrik and Adrians views that stability in 3.0 should not be risked. I am nevertheless trying to drop that huge difference in 'small' discrete isolated chunks. I have managed to find 3 areas that will do a large amount of reduction without changing or touching the core code in any way. RFCs were step 1. IPAddress is step 2. A new rfc3596 (DNS) library based non the RFCs is a third, but that still needs major testing and is weeks away I think. When the 'non-changes' are out of the branch and in HEAD waiting to be used. The actual core changes can push ahead cleanly for IPv6 in 3.1, both inside my branch and in any others who want to jump for the new ability while HEAD is closed to them. Thank you for the explanation. I still do not see much practical value in committing unused code. To me, committing 5500 lines with IPAddress is pretty much the same as committing 5200 lines without IPAddress because IPAddress is not used by the current code. However, I am not objecting to committing IPAddress. If others think IPAddress should be added to Squid3 now, then we should commit them. Thank you, Alex.
Re: Squid-3 release cycle
tis 2007-04-10 klockan 21:38 -0600 skrev Alex Rousskov: Squid 3.1 is whatever comes after a stable 3.0 release. Open to experimentation. Not currently branched (but could be if needed). I think it might be wise to branch Squid-3.0 after PRE6, and that the model currently used for Squid-2 is then applied to Squid-3 as well. - HEAD always kept open for new reasonably stable stuff, allowing development to progress natuarlly without having completed stuff bitrotting in some seldom looked at development branch. - If problems is seen in HEAD they get fixed, or the changes causing the problems is thrown out back to their development branch until fixed. - Stuff which seem to have settled gets merged to the stable branch by the release manager (in person or delegated to patch owner whatever suits the release manager). This works very well at least as long as HEAD and the stable branch hasn't diverged too much. And if they have diverged too much it's probably time to plan a new stable version before long.. With the unordered development process we have it's very hard to build firm plans on what features will be in a certain release before it's there. It very much depends on what the active developers at the time is working on. What is important for the project survival is that HEAD is kept reasonably stable and always suitable as development reference, and that developments is merged incrementally when possible to catch problems early without sacrificing the stability criteria too much. Question then becomes, where is the existing list of agreed features for 3.0-STABLE1 ?? Whatever features have been committed already minus unstable optional features. This is just my understanding, of course. Not claiming to express the elusive consensus here... Shared here. But I'd probably not minus the unstable optional features, just not having then enabled by default and marked as experimental. Squid-3.0 was originally supposed to match Squid-2.5 except being C++. It's already far beyond that. Sadly over time Squid-2 and Squid-3 has diverged a bit from each other and for the foreseeable future there will be some features missing in Squid-3 only to be found in Squid-2. But assuming Squid-3 gets stable it should quickly gain ground and the gap from Squid-2 will shorten as people gets interested in what Squid-3 can provide and there gets some motivation to get the important missing things to Squid-3 as well. Some of the missing things probably isn't very important, and can be left to rot in Squid-2 when focus gets moved to Squid-3. The probably biggest yell from users will be the lack of support for passthru connection oriented authentication (NTLM/Negotiate/Kerberos), aka connection pinning. The rest of the feature gaps is pretty minor I think. Internally the gaps is a bit bigger, especially at the comm layer where the comm loops of Squid-2 is much lighter.. but both is definitely hitting the wall when it comes to SSL and how to integrate it into the comm loops in a sane manner and there is need for some serious thought on how the comm layer should look like, which if done in Squid-3 will most likely bring it far ahead of Squid-2 in that area. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
