Shareaza

The security manager is in kind of an unstable situation... It might be better to revert that commit for beta if one is made. It might be possible to leave the miss cache since it is a minor addition but I am not sure if we can properly test the bigger changes. For example I am not sure if ban user works in the search window. I had some problems with it not working but there is not much point checking the reason for that if OD is still working on rewriting the whole system.

I agree with both of you. Honestly, I am surprised that the effects of this bug are not noticeable on the G2 crawler graphs

I am talking about revision 8920 "submitting ailurophobe's miss cache code and OldDeaths IP filter optimization code for further testing and review", ryo fixed and refactored it but still neither my code nor yours that was committed was really ready for a commit and I am bit dubious if ryo really fixed everything. This code is after all supposed to be fully replaced/merged by the code you are working on.

Trust me, that code really works

BTW, I'd like to hear Ryo's opinion within this discussion...

Btw, I did a new "ban user" test and seems it does add the rule for the IP address, it just doesn't clean the hits from the search like it used to. A performance optimization, perhaps?

Anyway, I guess it won't be necessary to revert the code, I totally forgot that cyko would have been "testing" the code in the alphas while making filters.

This seems rather illogical to me, as no matter where the call to the security manager to ban a user IP comes from, the update call to all places where this IP could be used (including searches) should be identical...

So you all thinks that we need a new release soon...

Pretty much. Apparently the "stable" version has a bug that can make G2 pretty much unusable that has been, if not fixed, at least mitigated in the debug builds. If not a new "release" build, a new "beta" that people could be directed to instead of the "latest debug" would be useful. After all the "latest debug" might be arbitrarily unstable or dysfunctional depending on what the last commit was.

That said, with the low number of testers we have, it might be best policy for the project to update the release version relatively fast. There just is not enough of us to stop bugs from making it through to the release, so we might as well focus on making the bug fixes available on auto-update faster.

" so we might as well focus on making the bug fixes available on auto-update faster."

I like that!!

+1 for the beta release !

dying to see new release too

Well, I really don't want to press the matter, but we seem to be having a massive decrease of the population of the Gnutella2 network going on ATM. As this might be caused by the future dates bug (which has been fixed in the current debug builds), we should release either an official beta or a stable release to counter this negative effect - the sooner the better.

Have a look at the population drop during the last month:

As you see G2 population slightly decreased every May.

I agree to old _death. And we are going to see if it continues to descrease in the next month graphics...

Really, that future dates bug is totally annoying. As i said there is many outhere complaining about it, and they are right. what is the porpouse of using shareaza when the main source (gnutella2) is buggy?
Please release the beta version, or any version that only the specific G2 bug is fixed. I think that this has been delayed quite a lot for now, though that this bug has already a fix in the dev builds.