I suppose we could have a separate list, but that just seems sort of
bureaucratic.
On Thu, 2 May 2002, Kev wrote:
>
> > All this talk about X ... Does that belong on this list?
>
> X is a module of GNUWorld, which is a coder-com-sponsored project.
> Therefore discussion of it is appropriate for
On Thu, 2 May 2002, Kev wrote:
> X is a module of GNUWorld, which is a coder-com-sponsored project.
> Therefore discussion of it is appropriate for this list.
"so nuh!"
--
Chris "_Shad0w_" Crowther
[EMAIL PROTECTED]
http://www.shad0w.org.uk/
> All this talk about X ... Does that belong on this list?
X is a module of GNUWorld, which is a coder-com-sponsored project.
Therefore discussion of it is appropriate for this list.
--
Kevin L. Mitchell <[EMAIL PROTECTED]>
Well, it's not actually a bug since X will automaticly remove bans that
are covered by more restrictive bans. Example:
I ban *!*[EMAIL PROTECTED] *!*[EMAIL PROTECTED]
And after that I set ban *!*@*, *!*@* implies that *!*[EMAIL PROTECTED]
and *!*[EMAIL PROTECTED] are banned, so X removes thease ba
All this talk about X ... Does that belong on this list?
In order to preserve synchronization it is necessary for
the servers to remove all bans that are overlapped
by a new ban that is set. That means that when someone
(including when that someone is X) sets a ban *!*@*
then ALL bans are remove
You'll have to excuse my feeble mind on this one:
> Thats indeed a bug, and when it'll be fixed, I think the unban issue with
> *!*@* can be forgotten. That cmd SHOULD remove only bans matching
> [EMAIL PROTECTED] (*!*@*) and not the 2 others (*!*[EMAIL PROTECTED] and
> the other)
When setting t
I would guess that the *!*@* ban overwrote the other 2 bans, since the other
2 bans were covered by the *!*@*, and therefore they were probably deleted
in favor of the *!*@* ban. Therefore, the only ban left in the channel
would be the 1 *!*@* ban, and therefore only 1 ban would be removed. :-)
