Re: bundlebuggy improvement
On Tue, 2008-03-18 at 09:57 +0100, Kinkie wrote: The idea is nice, but a bit dangerous IMO, as it lends itself to abuse. I second that we can try it out, and see how it works out. I think it will work out well. And in any case there is a second level human filter to make the actual commit. The point I don't understand then, is what is -core?. I had been told that it is about project governance, but this is not really governance. So either -core is being overloaded with a second task, or it is not just about governance. Today core is pretty much equal to committers, with some minor exceptions. Yes, the role of core is governance and management of the project. This among other things involves keeping an eye on what is being merged and vetoing things which doesn't make sense even if there is two other developers who is very excited about it.. For bundlebuggy it's not a hard distinction. The separation of meaningful and abuse veto votes is best dealt with at a human level by social interaction. Hence mainly reserved for squid-core. It's not meaningful to define yet another strict group for this purpose. The developer community around Squid is so small and with a pretty low churn rate, so the rules needs to be as simple and open as possible. For our project the less administration we need of bundlebuggy and the more meaningful information it picks up the better. Each time bundlebuggy misses a meaningful vote for whatever reason is a major obstacle for the project. But it's only a minor annoyance (moscito level) if someone on squid-dev tries to abuse the bundlebuggy system. The main problem in such case is on squid-dev and the social interaction needed to get that person to behave, not the traces left in bundlebuggy. Regards Henrik
Re: tcp proxy hackery
On Tue, Mar 18, 2008 at 3:00 AM, Adrian Chadd [EMAIL PROTECTED] wrote: On Tue, Mar 18, 2008, Henrik Nordstrom wrote: Does it? Most mallocs I know about has details about the allocated region just before the pointer (and optional red zone). http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf [...] If it is a drop-in replacement for malloc, why not just trying it out? I've heard of projects which benefited from going with jemalloc.. -- /kinkie
Re: tcp proxy hackery
http://www.creative.net.au/diffs/test1-355.tar.gz I've fixed the last few bugs - I'm seeing some occasional connect() failures from the ab box to the proxy server but that may be the hacky apachebench code. I can handle ~ 12,000 proxied connections a second at 96 byte replies. Userland CPU use still sits at ~5%. I'll try this on some larger hardware and see how far I can push it. I'll also play around now with some thread-based disk logging code to see if I can log requests to disk as fast as I can generate them. Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
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.
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
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 Web Proxy Wiki] Update of Features/LogDaemon by Amos Jeffries
Uhm, I'll do it Amos. It won't take me that long. I'll wait for your source organisation to be completed before I bring over the changes. Adrian On Tue, Mar 18, 2008, [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Squid Web Proxy Wiki for change notification. The following page has been changed by Amos Jeffries: http://wiki.squid-cache.org/Features/LogDaemon?action=diffrev2=4rev1=3 The comment on the change is: I'll port this myself if it none else will. -- * '''Status''': Done? - * '''ETA''': Unknown + * '''ETA''': 30 April 2007 * '''Version''': 3.1 - * '''Developer''': AdrianChadd + * '''Developer''': AdrianChadd, AmosJeffries == Squid3 status details ==
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: bundlebunny improvement
On Tue, 2008-03-18 at 01:52 +0100, Henrik Nordstrom wrote: It would be great if bundlebunny could accept email votes without first requiring an account. The rules on who may vode is not restricted to just squid-core, even if votes from squid-core is more important. My view regarding the voting procedure is that voting should be open to all on squid-dev who care to read and understand the patch they vote on, while immediate vetoing a mainly reserved for squid-core. Agreed, at least as the default mode to start with. We can always restrict the process if we are overwhelmed with poor quality votes, which is rather unlikely at this time. Thank you, Alex.
Re: Features/LogDaemon
On Tue, 2008-03-18 at 18:54 -0600, Adrian Chadd wrote: Uhm, I'll do it Amos. It won't take me that long. I'll wait for your source organisation to be completed before I bring over the changes. It looks like Amos wants the source reorganization to be the last project committed to v3.1. If my understanding is correct, the LogDaemon port should happen without waiting for reorganization (which may also make porting slightly easier if the affected areas have not changed much). If we want to close v3.1 for new features in the beginning of April, the ETA should be adjusted accordingly. Otherwise, we should bump the freeze date (provided LogDaemon is worth waiting for). Or does the feature freeze exclude Squid2 features being ported? Thanks, Alex. Adrian On Tue, Mar 18, 2008, [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Squid Web Proxy Wiki for change notification. The following page has been changed by Amos Jeffries: http://wiki.squid-cache.org/Features/LogDaemon?action=diffrev2=4rev1=3 The comment on the change is: I'll port this myself if it none else will. -- * '''Status''': Done? - * '''ETA''': Unknown + * '''ETA''': 30 April 2007 * '''Version''': 3.1 - * '''Developer''': AdrianChadd + * '''Developer''': AdrianChadd, AmosJeffries == Squid3 status details ==
