rename -> *.git

[irc.git] / software / RELEASES / ircservices / achurch.org / services / lists / ircservices / 2001.txt

From &quot  Mon Jan  1 12:31:32 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:04 2004
Subject: [IRCServices] MemoServ and UNSEND 
Message-ID: 001301c07431$d54a26c0$1cfe3cd0@pavilion

 
I was willing to suggest the command /msg MemoServ UNSEND , I have found this to be VERY useful and most users would thank IRCservices for it. 
Any plans to make that command available ? 
Thanks in advance. 
Ely 
======================
RealCFC@ChatFIRST.COM
http://www.chatfirst.com
======================
From bclark at bclark.yi.org  Mon Jan  1 16:52:02 2001
From: bclark at bclark.yi.org (Bryan Clark)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] MemoServ and UNSEND
References: <001301c07431$d54a26c0$1cfe3cd0@pavilion>
Message-ID: 3A512632.157312DB@bclark.yi.org

I doubt it would be hard to implement, but it'd have to be done so that
only unread memos could be unsent ..............

"[Real]" wrote:

> I was willing to suggest the command /msg MemoServ UNSEND , I have
> found this to be VERY useful and most users would thank IRCservices
> for it.Any plans to make that command available ?Thanks in
> advance.Ely======================
> RealCFC@ChatFIRST.COM
> http://www.chatfirst.com
> ======================


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From andy at strugglers.net  Mon Jan  1 20:22:22 2001
From: andy at strugglers.net (Andy Smith)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] CLEAR MODES and mode R
Message-ID: rpl25tgpvtb7o1kd4ennegsak7mrfg692n@4ax.com

CHANSERV CLEAR MODES does not appear to clear mode R, is this intentional?

We are using bahamut 1.4.8.

-- 
Andy Smith <andy@strugglers.net>

---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From andy at strugglers.net  Mon Jan  1 20:42:38 2001
From: andy at strugglers.net (Andy Smith)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] CLEAR MODES and mode R
In-Reply-To: <rpl25tgpvtb7o1kd4ennegsak7mrfg692n@4ax.com>
References: <rpl25tgpvtb7o1kd4ennegsak7mrfg692n@4ax.com>
Message-ID: e1n25t4e9jjiqj2dvlod6co95gc4f73tdv@4ax.com

On Tue, 02 Jan 2001 04:22:22 +0000, Andy Smith <andy@strugglers.net> wrote:

>CHANSERV CLEAR MODES does not appear to clear mode R, is this intentional?
>
>We are using bahamut 1.4.8.

And ircservices 4.4.8, I should add.

-- 
Andy Smith <andy@strugglers.net>

---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From achurch at achurch.org  Thu Jan  4 11:00:40 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] CLEAR MODES and mode R
Message-ID: 3a53d9c0.61023@prima&#45;lan.net

>CHANSERV CLEAR MODES does not appear to clear mode R, is this intentional?
>
>We are using bahamut 1.4.8.

     Fixed for version 4.5.0.  Thanks for the report.

  --Andrew Church
    achurch@achurch.org | New address - please note.
    http://achurch.org/ | \e$B%a!<%k%"%I%l%9$,JQ$o$j$^$7$?!#\e(B

---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Thu Jan  4 06:30:21 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] IRCServices Patch Archive
References: <200101040846.f048kn931818@dymwsm09.mailwatch.com>
Message-ID: 000701c0765a$df4ec6f0$0100a8c0@excalibur

Anyone who has any type of patchs that they have written or have found you
may email them to me at dryder@qx.net When you email them please use the
following:

1.) Author name and support email address.
2.) Conplete installation instructions.
3.) State which version of IRCServices the patch affects.
4.) Patch version number (in case changes are made)

I'm still planning to do a patch archive, I just need to finish up on
another project first. :) I ask that you all remember that any patch sent to
me will be _unsupported_ by the coding team of IRCServices, Andrew Kempe,
Andy Church, The ShadowFire IRC Network, This or any other mailing list
graciously hosted by Shadowfire or myself. All patches sent will also be
concidered "as-is", supported by the author only and covered by the GPL
license agreement unless otherwise stated. I will have a simple web board on
my site as well in the near future, however I'm keeping this as simple as
possible for today until I've had my daily quota of caffine! ;P

For a list of supported patches please see the official IRCServices website
at http://ender.shadowfire.org/ircservices/ Any patch located on my not yet
completed website will be unsupported by the above mentioned contacts.

Thanx,

Scott
aka Dryder

PS
Please pardon the cross post.

----- Original Message -----
From: "Pinto, Joao luis (J.M.)" <jpinto17@visteon.com>
To: <ircservices-coding@snow.shadowfire.org>
Sent: Thursday, January 04, 2001 3:10 AM
Subject: RE: [IRCServices Coding] Services segfaults on newer linux?


> The patch posted (I don't remember  who) about two months ago for this
> problem will fix it without no need for configure changes or extra
> compatibilty function overheard.
>
> Joao Pinto - Lamego@PTlink.net
> PTlink Tech Admin
> <A  HREF="http://www.ptlink.net">http://www.ptlink.net</A>
>
> -----Original Message-----
> From: achurch@achurch.org [<A  HREF="mailto:achurch@achurch.org">mailto:achurch@achurch.org</A>]
> Sent: quinta-feira, 4 de janeiro de 2001 2:37
> To: ircservices-coding@snow.shadowfire.org
> Subject: Re: [IRCServices Coding] Services segfaults on newer linux?
>
>
> >Services (and import-db) segfaults on reaching blank lines in
> services.conf.
> >I can only assume this is due to changes in glibc, cos I am sure there
are
> >plenty of people running ircservices on redhat.  My example machine is a
> >redhat 6.0 box upgraded with a bunch of 7.0 SRPMS, including the latest
> >glibc:
> [...]
> >glibc-2.2-5
> [...]
> >[andy@aeriss services]$ /tmp/services/bin/services
> >Segmentation fault (core dumped)
>
>      RedHat 7.0 has been reported to be very unstable, so at the moment
your
> best solution would be to downgrade to 6.x packages (glibc in particular).
> As a more long-term solution, I've added a check for this bug in 4.5.0's
> configure script and a workaround strtok() function in compat.c.
>
>   --Andrew Church
>     achurch@achurch.org | New address - please note.
>     <A  HREF="http://achurch.org/">http://achurch.org/</A> | \e$B%a!<%k%"%I%l%9$,JQ$o$j$^$7$?!#\e(B
>
> ----------------------------------------------------------------
> To unsubscribe, send email to majordomo@snow.shadowfire.org with
> "unsubscribe ircservices-coding" in the body, without the quotes.
>
>
> ----------------------------------------------------------------
> To unsubscribe, send email to majordomo@snow.shadowfire.org with
> "unsubscribe ircservices-coding" in the body, without the quotes.
>


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Mon Jan  8 14:48:59 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Services Help
Message-ID: 000401c079c5$487ccab0$0100a8c0@l33tz0r


We are trying to setup UltimateIRCd with a services agent but we do not know which ones work with the ircd. Any assistance would be appreciated, thanks. 
  
  
_________________________ 
Leo Zhadanovsky 
webmaster@007sdomain.com 
Webmaster of 007's Domain 
http://www.007sdomain.com 
Leader of QF7 
http://qf7.hypermart.net 
 
From &quot  Mon Jan  8 15:04:17 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Services Help
References: <000401c079c5$487ccab0$0100a8c0@l33tz0r>
Message-ID: 001501c079c7$5486ff40$0100a8c0@excalibur

 
Greetings Leo, 
  
Our officially supported IRC Daemon is Bahamut found at http://www.bahamut.net. By saying this I am in no way stating that your daemon of choice will not work, nor am I saying that by writing this list for help that your request will be ignored. I am however saying that if you choose a daemon other than Bahamut, you may not get any or much help. 
  
A list of previously supported daemons is located within the documentation that came with IRCServices, and I do believe a list of damons known _not_ to work is as well. If your daemon is not listed and works, please feel free to email this list so that it may have a chance of being added to the documentation. 
  
Dryder 
   
----- Original Message -----  
From: Leo Zhadanovsky  
To: ShadowMaster@Shadow-Realm.org ; ircservices@snow.shadowfire.org  
Sent: Monday, January 08, 2001 5:48 PM 
Subject: [IRCServices] Services Help 

 
We are trying to setup UltimateIRCd with a services agent but we do not know which ones work with the ircd. Any assistance would be appreciated, thanks. 
  
  
_________________________ 
Leo Zhadanovsky 
webmaster@007sdomain.com 
Webmaster of 007's Domain 
http://www.007sdomain.com 
Leader of QF7 
http://qf7.hypermart.net 
 
From achurch at achurch.org  Tue Jan  9 13:59:29 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
Message-ID: 3a5a9dc8.34264@prima&#45;lan.net

     One of the features going into 4.5.0 will be channel suspension.
However, there are a number of potential issues as to how a suspended
channel should be treated, so I'd like to gather opinions on the
following points: (my current thoughts are in [brackets])

     - Should a suspended channel be treated like a forbidden one (no
one can enter it) or an unregistered one (it can be used, but Services
won't do anything do it)?  [forbidden]

     - Should Services allow changes to the channel settings?  I think
this one is a pretty clear "no", but I'll put it up for debate.  [no]

     - Should Services allow the founder to drop the channel?  The
current behavior of suspended nicknames is that the owner cannot drop
them, but this is only because the owner cannot identify for them and
not because Services specifically prevents dropping; I could see
suspended channels going either way.  [undecided]

     - Should Services allow memos to be sent to the channel?  [no]
Incidentally, 4.4.x allows memos to be sent to suspended nicks; I'm
planning on disabling that as well unless someone convinces me
otherwise.

  --Andrew Church
    achurch@achurch.org | New address - please note.
    http://achurch.org/ | \e$B%a!<%k%"%I%l%9$,JQ$o$j$^$7$?!#\e(B

---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From bclark at bclark.yi.org  Mon Jan  8 21:21:28 2001
From: bclark at bclark.yi.org (Bryan Clark)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
References: <3a5a9dc8.34264@prima-lan.net>
Message-ID: 3A5A9FD8.3AF35442@bclark.yi.org

Andrew Church wrote:

>       - Should a suspended channel be treated like a forbidden one (no
> one can enter it) or an unregistered one (it can be used, but Services
> won't do anything do it)?  [forbidden]

This I'm not too sure on, though I'm leaning toward unregistered. A light
tap could send me going in the other direction on that one, though. ;)

>      - Should Services allow changes to the channel settings?  I think
> this one is a pretty clear "no", but I'll put it up for debate.  [no]

Agreed, definitely.

>      - Should Services allow the founder to drop the channel?  The
> current behavior of suspended nicknames is that the owner cannot drop
> them, but this is only because the owner cannot identify for them and
> not because Services specifically prevents dropping; I could see
> suspended channels going either way.  [undecided]

I would say "no" here, unless you want to change how dropping channels
works internally. If you're just setting another flag in ci->flags for
it, then dropping it will effectively unsuspend it unless you check for
the flag first. My reasoning here is that it's probably something the
founder did or allowed to happen that got the channel suspended in the
first place. :P

>      - Should Services allow memos to be sent to the channel?  [no]
> Incidentally, 4.4.x allows memos to be sent to suspended nicks; I'm
> planning on disabling that as well unless someone convinces me
> otherwise.

There's no reason to, since it's apparently turning a blind eye to the
channel everywhere else. ;)



---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Mon Jan  8 21:26:29 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
References: <3a5a9dc8.34264@prima-lan.net>
Message-ID: 002d01c079fc$b94fad20$05090a0a@kroag


----- Original Message -----
From: "Andrew Church" <achurch@achurch.org>
To: <ircservices@Snow.shadowfire.org>
Sent: Monday, January 08, 2001 11:59 PM
Subject: [IRCServices] Desired behavior of channel suspension?

>      - Should a suspended channel be treated like a forbidden one (no
> one can enter it) or an unregistered one (it can be used, but Services
> won't do anything do it)?  [forbidden]

Forbidden

>      - Should Services allow changes to the channel settings?  I think
> this one is a pretty clear "no", but I'll put it up for debate.  [no]

No

>      - Should Services allow the founder to drop the channel?  The
> current behavior of suspended nicknames is that the owner cannot drop
> them, but this is only because the owner cannot identify for them and
> not because Services specifically prevents dropping; I could see
> suspended channels going either way.  [undecided]

No, because they could just turn around and re-register the channel, which
defeats
part of the purpose of suspending it.

>      - Should Services allow memos to be sent to the channel?  [no]
> Incidentally, 4.4.x allows memos to be sent to suspended nicks; I'm
> planning on disabling that as well unless someone convinces me
> otherwise.

No.


Anyway, that's just my $1.82.  Now I just need my change back... ;D


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From mmassena at qwest.net  Tue Jan  9 05:38:57 2001
From: mmassena at qwest.net (Morgan Massena)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
In-Reply-To: <3a5a9dc8.34264@prima-lan.net>
References: 3a5a9dc8.34264@prima&#45;lan.net
Message-ID: 5.0.0.25.2.20010109053447.00a56d20@pop.spkn.qwest.net

At 01:59 PM 1/9/01 +0900, you wrote:
>      One of the features going into 4.5.0 will be channel suspension.
>However, there are a number of potential issues as to how a suspended
>channel should be treated, so I'd like to gather opinions on the
>following points: (my current thoughts are in [brackets])

Speaking of 4.5.0, is there anywhere the masses can d/l this while it's 
being worked on? Is there a CVS anywhere?


>      - Should a suspended channel be treated like a forbidden one (no
>one can enter it) or an unregistered one (it can be used, but Services
>won't do anything do it)?  [forbidden]

Maybe this can be a setting, This could easily go either way...
If not than Forbid

>      - Should Services allow changes to the channel settings?  I think
>this one is a pretty clear "no", but I'll put it up for debate.  [no]

No

>      - Should Services allow the founder to drop the channel?  The
>current behavior of suspended nicknames is that the owner cannot drop
>them, but this is only because the owner cannot identify for them and
>not because Services specifically prevents dropping; I could see
>suspended channels going either way.  [undecided]

No

>      - Should Services allow memos to be sent to the channel?  [no]
>Incidentally, 4.4.x allows memos to be sent to suspended nicks; I'm
>planning on disabling that as well unless someone convinces me
>otherwise.

Why not? Wont hurt anything. Besides, memos to channels aren't used that often.

>   --Andrew Church
>     achurch@achurch.org | New address - please note.
>     http://achurch.org/ | $B%a!<%k%"%I%l%9$,JQ$o$j$^$7$?!#(B
>
>---------------------------------------------------------------
>To unsubscribe, send email to majordomo@snow.shadowfire.org
>with "unsubscribe ircservices" in the body, without the quotes.


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Mon Jan  8 22:50:57 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
References: <5.0.0.25.2.20010109053447.00a56d20@pop.spkn.qwest.net>
Message-ID: 03ef01c07a08$8529cc90$9c011ac4@africa.didata.local

> Speaking of 4.5.0, is there anywhere the masses can d/l this while it's
> being worked on? Is there a CVS anywhere?

I don't know about Andy, but I was reluctant to allow the general world to
use under development source due to the number of unhelpfull bug reports I
was getting. People did not seem to get the fact that the source was VERY
alpha and as such didn't do many of the things it should - like saving
databases or working properly. As things get closer to a final release it
becomes easier to release it as beta code. 4.5 was getting very close to
that stage when I last worked on it. However, Andy has to pick up where I
left off, which means that it will probably be longer until it gets
released.

I hope this makes it clearer as to why the source was not released to the
public.

Andrew


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From chromatix at cyberspace.org  Mon Jan  8 22:53:16 2001
From: chromatix at cyberspace.org (Jonathan Morton)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
In-Reply-To: <002d01c079fc$b94fad20$05090a0a@kroag>
References: <3a5a9dc8.34264@prima-lan.net>
Message-ID: l03130303b680644a55a2@[192.168.239.105]

>>      - Should a suspended channel be treated like a forbidden one (no
>> one can enter it) or an unregistered one (it can be used, but Services
>> won't do anything do it)?  [forbidden]
>
>Forbidden

Agreed.

>>      - Should Services allow changes to the channel settings?  I think
>> this one is a pretty clear "no", but I'll put it up for debate.  [no]
>
>No

Agreed.

>>      - Should Services allow the founder to drop the channel?  The
>> current behavior of suspended nicknames is that the owner cannot drop
>> them, but this is only because the owner cannot identify for them and
>> not because Services specifically prevents dropping; I could see
>> suspended channels going either way.  [undecided]
>
>No, because they could just turn around and re-register the channel, which
>defeats
>part of the purpose of suspending it.

Agreed.

>>      - Should Services allow memos to be sent to the channel?  [no]
>> Incidentally, 4.4.x allows memos to be sent to suspended nicks; I'm
>> planning on disabling that as well unless someone convinces me
>> otherwise.

I'm not sure on this one - in my limited experience MemoServ isn't used
often even for personal memos, let alone channel ones (though it can be
invaluable when it does get used).  If I were implementing this myself, I'd
probably allow the memo to be sent, but then notify the sending user of the
suspension and the fact it may never be read.  I would also ensure there
was a limit on how many memos could be queued up.  If there is an option to
"un-send" memos, this would work well with notification, IMHO.

Since MemoServ usage is fairly individual to any specific network or
channel, I'd advise making this one configurable between "no", "notify",
"notify/limit", "yes" and "yes/limit".

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a19 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-----END GEEK CODE BLOCK-----



---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From mike at chat.za.net  Mon Jan  8 23:58:44 2001
From: mike at chat.za.net (Michael Smith)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
Message-ID: 2.2.32.20010109075844.0109052c@196.14.3.98


I take it that Andrew Church has resumed development on services then?

Mike

At 08:50 AM 01/01/09 +0200, you wrote:
>> Speaking of 4.5.0, is there anywhere the masses can d/l this while it's
>> being worked on? Is there a CVS anywhere?
>
>I don't know about Andy, but I was reluctant to allow the general world to
>use under development source due to the number of unhelpfull bug reports I
>was getting. People did not seem to get the fact that the source was VERY
>alpha and as such didn't do many of the things it should - like saving
>databases or working properly. As things get closer to a final release it
>becomes easier to release it as beta code. 4.5 was getting very close to
>that stage when I last worked on it. However, Andy has to pick up where I
>left off, which means that it will probably be longer until it gets
>released.
>
>I hope this makes it clearer as to why the source was not released to the
>public.
>
>Andrew
>
>
>---------------------------------------------------------------
>To unsubscribe, send email to majordomo@snow.shadowfire.org
>with "unsubscribe ircservices" in the body, without the quotes.
>
>
---
Michael Smith (Warlock on IRC)
http://www.warlock.web.za
 "Do you smell something burning or is it me?"
                -- Joan of Arc                                         


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Tue Jan  9 00:28:33 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
References: <3a5a9dc8.34264@prima-lan.net>
Message-ID: 027301c07a16$3ec06800$430ba8c0@hostel1.giki.edu.pk

>      - Should a suspended channel be treated like a forbidden one (no
> one can enter it) or an unregistered one (it can be used, but Services
> won't do anything do it)?  [forbidden]

I would go with forbidden, with some differences as noted below.


>      - Should Services allow changes to the channel settings?  I think
> this one is a pretty clear "no", but I'll put it up for debate.  [no]

If its forbidden, its makes no difference. But it should not be allowed.


>      - Should Services allow the founder to drop the channel?  The
> current behavior of suspended nicknames is that the owner cannot drop
> them, but this is only because the owner cannot identify for them and
> not because Services specifically prevents dropping; I could see
> suspended channels going either way.  [undecided]

I think this shouldn't be allowed. If the Services Admin thinks the channel should be dropped, he can drop it, but
otherwise let the founder keep the channel, that way, its easier to give it back if the Services Admin wants to, and its
a sort of a punishment since he can now register one less channel.


>      - Should Services allow memos to be sent to the channel?  [no]

No. Its a suspended channel :)

> Incidentally, 4.4.x allows memos to be sent to suspended nicks; I'm
> planning on disabling that as well unless someone convinces me
> otherwise.

Good idea.


>   --Andrew Church
>     achurch@achurch.org | New address - please note.
>     http://achurch.org/ | \e$B%a!<%k%"%I%l%9$,JQ$o$j$^$7$?!#\e(B
>

Imran Ali Rashid


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Tue Jan  9 04:51:34 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
References: <3a5a9dc8.34264@prima-lan.net>
Message-ID: 001f01c07a3a$e69b6790$0100a8c0@excalibur


----- Original Message -----
From: "Andrew Church" <achurch@achurch.org>
To: <ircservices@Snow.shadowfire.org>
Sent: Monday, January 08, 2001 11:59 PM
Subject: [IRCServices] Desired behavior of channel suspension?


>      One of the features going into 4.5.0 will be channel suspension.
> However, there are a number of potential issues as to how a suspended
> channel should be treated, so I'd like to gather opinions on the
> following points: (my current thoughts are in [brackets])
>
>      - Should a suspended channel be treated like a forbidden one (no
> one can enter it) or an unregistered one (it can be used, but Services
> won't do anything do it)?  [forbidden]
>

ok, I'm gunna be different :). I believe that a suspended channel should be
mlock'd +tns
and chanserv "ignore" commands issued by chanops, or at least set secure on
and have chanserv act as if the op is attempting to use commands as an
un-identified nick.

>      - Should Services allow changes to the channel settings?  I think
> this one is a pretty clear "no", but I'll put it up for debate.  [no]
>

No

>      - Should Services allow the founder to drop the channel?  The
> current behavior of suspended nicknames is that the owner cannot drop
> them, but this is only because the owner cannot identify for them and
> not because Services specifically prevents dropping; I could see
> suspended channels going either way.  [undecided]
>

non-opers should not be allowed to drop, IMO there wouldn't be anything to
stop them from drop'ing the channel then re-registering (since to UN-forbid
a channel you drop it.)

>      - Should Services allow memos to be sent to the channel?  [no]
> Incidentally, 4.4.x allows memos to be sent to suspended nicks; I'm
> planning on disabling that as well unless someone convinces me
> otherwise.
>

No

>   --Andrew Church
>     achurch@achurch.org | New address - please note.
>     http://achurch.org/ | \e$B%a!<%k%"%I%l%9$,JQ$o$j$^$7$?!#\e(B
>
> ---------------------------------------------------------------
> To unsubscribe, send email to majordomo@snow.shadowfire.org
> with "unsubscribe ircservices" in the body, without the quotes.
>


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Tue Jan  9 16:13:14 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
References: <3a5a9dc8.34264@prima-lan.net>
Message-ID: 005f01c07a9a$20e56270$37526dd1@tiphares.com


----- Original Message ----- 
From: Andrew Church <achurch@achurch.org>
To: <ircservices@ender.shadowfire.org>
Sent: Monday, January 08, 2001 10:59 PM
Subject: [IRCServices] Desired behavior of channel suspension?


] ... SNIP ... [

> 
>      - Should a suspended channel be treated like a forbidden one (no
> one can enter it) or an unregistered one (it can be used, but Services
> won't do anything do it)?  [forbidden]
>

I think it should be treated more as a modeless channel.  First person
to enter it is deoped.  After that services treats it as if the channel
is unregistered, but forbids people from registering it (obviously)

>
>      - Should Services allow changes to the channel settings?  I think
> this one is a pretty clear "no", but I'll put it up for debate.  [no]
>

No, otherwise it would contradict my above idea.

>
>      - Should Services allow the founder to drop the channel?  The
> current behavior of suspended nicknames is that the owner cannot drop
> them, but this is only because the owner cannot identify for them and
> not because Services specifically prevents dropping; I could see
> suspended channels going either way.  [undecided]
>

Absolutely not.  The founder could drop the channel and then re-register
the channel there by removing the suspend.  On the other hand.  You might
wish to add this in this sort of manner.

Founder sends the drop command to ChanServ.  ChanServ then tags the channel
to be dropped once the amount of time the suspension has elapsed.  I.e. 
It won't actually drop the channel until the suspension has been lifted in
one way or another.

>
>      - Should Services allow memos to be sent to the channel?  [no]
> Incidentally, 4.4.x allows memos to be sent to suspended nicks; I'm
> planning on disabling that as well unless someone convinces me
> otherwise.
> 

This wouldn't bother me either way.  However, I think that if it is
allowed, then the users should NOT be allowed to read those memo's
until the suspension is up.

My two cents,
Bryce Simonds (Kelmar K. Firesun)


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Tue Jan  9 18:06:36 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
References: <3a5a9dc8.34264@prima-lan.net> <005f01c07a9a$20e56270$37526dd1@tiphares.com>
Message-ID: 000901c07aa9$f790af50$0100a8c0@excalibur


----- Original Message -----
From: "Kelmar K. Firesun" <kfiresun@ix.netcom.com>
To: <ircservices@snow.shadowfire.org>
Sent: Tuesday, January 09, 2001 7:13 PM
Subject: Re: [IRCServices] Desired behavior of channel suspension?


>
> ----- Original Message -----
> From: Andrew Church <achurch@achurch.org>
> To: <ircservices@ender.shadowfire.org>
> Sent: Monday, January 08, 2001 10:59 PM
> Subject: [IRCServices] Desired behavior of channel suspension?
>
>
> ] ... SNIP ... [
>
> >
> >      - Should a suspended channel be treated like a forbidden one (no
> > one can enter it) or an unregistered one (it can be used, but Services
> > won't do anything do it)?  [forbidden]
> >
>
> I think it should be treated more as a modeless channel.  First person
> to enter it is deoped.  After that services treats it as if the channel
> is unregistered, but forbids people from registering it (obviously)

I would dissagree with "modeless" I believe that the channel should be:

 +t so users cannot "have fun" with setting the topic to something childish
or obsene towards IRCops because the channel is suspended.
+n to prevent outside messages.
+s to keep the channel off the channel list and out of users /whois as a
measure to prevent any type of attraction drawn to the channel.

Optional:

+m to really make the users usage of the channel pleasant <EG>.
+i to keep the channel user count at the max of 1


My $0.02,

Dryder


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Tue Jan  9 18:36:05 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
References: <3a5a9dc8.34264@prima-lan.net> <005f01c07a9a$20e56270$37526dd1@tiphares.com> <000901c07aa9$f790af50$0100a8c0@excalibur>
Message-ID: 004b01c07aae$152af990$0100a8c0@excalibur

Actually now that I think about it ... how about having the channel being
suspended and no modes set, and for those that wish to set modes via
chanserv they could do so with either operserv mode or chanserv mlock. Other
options could be set too, via allowing Services Opers or admins to set
options as if they had founder access. Since these options already exist,
minimal coding to allow opers/admins to act as the founder would be needed.

This should make the suspend command do what the oper/admin wishes or allows
the rules regarding how suspend works to be determined by the network
administration.

Dryder

----- Original Message -----
From: "Scott Seufert" <dryder@qx.net>
To: <ircservices@snow.shadowfire.org>
Sent: Tuesday, January 09, 2001 9:06 PM
Subject: Re: [IRCServices] Desired behavior of channel suspension?


> >
> > ] ... SNIP ... [
> >
> > >
> > >      - Should a suspended channel be treated like a forbidden one (no
> > > one can enter it) or an unregistered one (it can be used, but Services
> > > won't do anything do it)?  [forbidden]
> > >
> >
> > I think it should be treated more as a modeless channel.  First person
> > to enter it is deoped.  After that services treats it as if the channel
> > is unregistered, but forbids people from registering it (obviously)
>
> I would dissagree with "modeless" I believe that the channel should be:
>
>  +t so users cannot "have fun" with setting the topic to something
childish
> or obsene towards IRCops because the channel is suspended.
> +n to prevent outside messages.
> +s to keep the channel off the channel list and out of users /whois as a
> measure to prevent any type of attraction drawn to the channel.
>
> Optional:
>
> +m to really make the users usage of the channel pleasant <EG>.
> +i to keep the channel user count at the max of 1
>
>
> My $0.02,
>
> Dryder
>
>
> ---------------------------------------------------------------
> To unsubscribe, send email to majordomo@snow.shadowfire.org
> with "unsubscribe ircservices" in the body, without the quotes.
>


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Tue Jan  9 19:19:56 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
References: <3a5a9dc8.34264@prima-lan.net> <005f01c07a9a$20e56270$37526dd1@tiphares.com> <000901c07aa9$f790af50$0100a8c0@excalibur>
Message-ID: 001801c07ab4$361f8070$37526dd1@tiphares.com


----- Original Message -----
From: Scott Seufert <dryder@qx.net>
To: <ircservices@snow.shadowfire.org>
Sent: Tuesday, January 09, 2001 8:06 PM
Subject: Re: [IRCServices] Desired behavior of channel suspension?

] ... SNIP ... [


>
> I would dissagree with "modeless" I believe that the channel should be:
>
>  +t so users cannot "have fun" with setting the topic to something
childish
> or obsene towards IRCops because the channel is suspended.
> +n to prevent outside messages.
> +s to keep the channel off the channel list and out of users /whois as a
> measure to prevent any type of attraction drawn to the channel.
>
> Optional:
>
> +m to really make the users usage of the channel pleasant <EG>.
> +i to keep the channel user count at the max of 1
>
>

Well they wouldn't be modeless channels persay.  Just no ops.  ChanServ
and OperServ could still affect the modes or grant ops of course.  So
you could do a +tns on the channel, just don't op people by default to
keep them from doing much.  They can't kick or ban this way for example.

Perhaps the mlock on a suspended channel could be setable in the
configuration file.


As a side note:
In all reality services can change modes on a modeless channel as well, but
they don't like it too much.  (The IRCd doesn't seem to mind though)

Bryce Simonds (Kelmar K. Firesun)



---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Wed Jan 10 17:26:58 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Have Problems
Message-ID: F133prR0E6faZWZaend0000790d@hotmail.com


I have probleme to run ircservices with my ircu, can u answer me please ? 
  
Regards, Bryan.Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
 --------------------------------------------------------------- To unsubscribe, send email to majordomo@snow.shadowfire.org with "unsubscribe ircservices" in the body, without the quotes.
From smkelly at zombie.org  Wed Jan 10 17:59:32 2001
From: smkelly at zombie.org (Sean Kelly)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Have Problems
In-Reply-To: <F133prR0E6faZWZaend0000790d@hotmail.com>; from wfteam@hotmail.com on Thu, Jan 11, 2001 at 01:26:58AM -0000
References: <F133prR0E6faZWZaend0000790d@hotmail.com>
Message-ID: 20010110195932.A5758@edgemaster.zombie.org

On Thu, Jan 11, 2001 at 01:26:58AM -0000, Bryan Templeton wrote:
...some crap that showed up as an HTML attachment...


First of all, HTML formatted mail is evil.  Please stick with the
standard ASCII stuff that we all know and love.  Secondly, what version
of ircu are you having problems with?  IRCServices is known not to work
with newer versions of ircu due to the drastic changes in server to
server protocol.  And for that matter, what version of IRCServices?

-- 
Sean Kelly <smkelly@zombie.org> or <smkelly@slashnet.org>
   PGP KeyID: 77042C7B        http://www.sean-kelly.org

---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From salde at silli.hao.osakk.fi  Fri Jan 12 06:50:06 2001
From: salde at silli.hao.osakk.fi (Sauli Halttu)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] ircd2.10.3 says old version
Message-ID: Pine.LNX.4.10.10101121646450.2315&#45;100000@silli.hao.osakk.fi

i use ircd2.10.3p1, redhat 6.1, ircservices 4.3.3 and my ircd says when i
start services that server version is too old. what can i do for that ??
i also have try ircservices version 4.3.4 and 4.4.8, and i get same
error...

/-----------------------------------------------\
| E-Mail:       sauli.halttu@silli.hao.osakk.fi |
| WWW:		http://www.salde.cjb.net	|
| Phone:        +358-40-5596161                 |
|		+358-45-6789577
|               +358-50-3578110                 |
\-----------------------------------------------/

Matrix Has you...


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Sat Jan 13 04:26:41 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] IRCServices-4.5.0 Release Date?
Message-ID: E14HQ91&#45;0000c2&#45;00@gadolinium.btinternet.com

Hey there,

Just 2 quick questions to the list here :

1) Is there anywhere I can grab a pre-release CHANGES file for
IRC-Services 4.5?

2) Does anyone out there know when 4.5 will be released,
either in Beta or as an official release?

Thanking you in advance,

Quinn

---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Sat Jan 13 04:37:06 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Desired behavior of channel suspension?
Message-ID: E14HQ96&#45;0000c2&#45;00@gadolinium.btinternet.com

[snip]
Sorry about my late (and probably useless) reply...

>      One of the features going into 4.5.0 will be channel suspension.
> However, there are a number of potential issues as to how a suspended
> channel should be treated, so I'd like to gather opinions on the
> following points: (my current thoughts are in [brackets])
> 
>      - Should a suspended channel be treated like a forbidden one (no
> one can enter it) or an unregistered one (it can be used, but Services
> won't do anything do it)?  [forbidden]
> 
I'd agree with forbidden here, but maybe a config file option to allow
setting
whether no-one can enter it or whether people can enter it, but Services
just
won't interract with the channel at all (as if it was unregistered).

However, if you don't want Services to interract with a registered channel,
wouldn't it just be a good idea to add an IGNORE command?  Probably not the
best idea, but this would allow you to just stop Services interracting with
channels IF you decide to make SUSPEND disallow people going into the
channel at all.

>      - Should Services allow changes to the channel settings?  I think
> this one is a pretty clear "no", but I'll put it up for debate.  [no]
> 
No, if it's suspended the only action you should be able to take against it
as
a Services Admin would be to DROP the channel or make it unsuspended.

>      - Should Services allow the founder to drop the channel?  The
> current behavior of suspended nicknames is that the owner cannot drop
> them, but this is only because the owner cannot identify for them and
> not because Services specifically prevents dropping; I could see
> suspended channels going either way.  [undecided]
> 
I'd say no, if a channel is suspended, only a Services Admin can DROP or
unsuspend the channel in question.  If you allow DROP to channel founder,
then all they'd have
to do is DROP it, then re-register it.  In which case, you may as well
forbid the channel because they'd DROP it, lose the access/akick lists 'n'
such.  They'd lose that on a FORBID anyhow.

>      - Should Services allow memos to be sent to the channel?  [no]
> Incidentally, 4.4.x allows memos to be sent to suspended nicks; I'm
> planning on disabling that as well unless someone convinces me
> otherwise.
> 
I'd agree here too, you can't send memos to a suspended nick.
Obviously someone did something bad to warrant having their nick or channel
suspended, so why should you give them the right to have memos sent or
received.
If a nick can't get memos, most people would re-register a new nick so they
can or just to bypass the suspension of their old nick.  So they COULD
still get Memos then, unless you've had them AKILL'd in which case IMHO the
suspension of their nick is pointless.

Just my 0.2p's worth of input there.

>   --Andrew Church
>     achurch@achurch.org | New address - please note.
>     http://achurch.org/ | \e$B%a!<%k%"%I%l%9$,JQ$o$j$^$7$?!#\e(B
> 
> ---------------------------------------------------------------
> To unsubscribe, send email to majordomo@snow.shadowfire.org
> with "unsubscribe ircservices" in the body, without the quotes.

---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From chojin at tarakan-network.com  Sat Jan 13 06:08:59 2001
From: chojin at tarakan-network.com (chojin@tarakan-network.com)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] IRCServices 4.5.0 ?
In-Reply-To: <E14HQ96-0000c2-00@gadolinium.btinternet.com>
References: <E14HQ96-0000c2-00@gadolinium.btinternet.com>
Message-ID: 20010113140859.865199B04@mail.freesurf.fr


Hi

4.5.0 version will come soon ?

What is the lastest version I can download and where ? thank you

Regards

---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Sat Jan 13 06:26:17 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] IRCServices 4.5.0 ?
References: <E14HQ96-0000c2-00@gadolinium.btinternet.com> <20010113140859.865199B04@mail.freesurf.fr>
Message-ID: 000701c07d6c$cbdb49e0$964efea9@excalibur

IRCServices can be downloaded from:

http://ender.shadowfire.org/ircservices/

Since there is such a large difference in the current version and 4.5.0,
there has been no release date scheduled as of yet. Many things are still
being ironed out. IRCServices-4.5.0 will not be a standard "bug fix"
version. Many new features that have been requested will also be included in
4.5.0.

The current version is IRCServices-4.4.9 [beta] which is available at the
link listed above.

Dryder

----- Original Message -----
From: <chojin@tarakan-network.com>
To: <ircservices@snow.shadowfire.org>
Sent: Saturday, January 13, 2001 9:08 AM
Subject: [IRCServices] IRCServices 4.5.0 ?


>
> Hi
>
> 4.5.0 version will come soon ?
>
> What is the lastest version I can download and where ? thank you
>
> Regards
>
> ---------------------------------------------------------------
> To unsubscribe, send email to majordomo@snow.shadowfire.org
> with "unsubscribe ircservices" in the body, without the quotes.
>


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Sun Jan 14 21:59:49 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] IRCServices-4.5.0 Release Date?
References: <E14HQ91-0000c2-00@gadolinium.btinternet.com>
Message-ID: 095e01c07eb8$5ec5afb0$9c011ac4@africa.didata.local

Here are the changes as of the last time I made a _new_ change worth
documenting. It should be noted that most of the development time has been
spent around implementing AOP, SOP and VOP and getting the conversion
between ACCESS LEVELS and these commands to work well. Andy's changes since
the end of last year and the beginning of this one are NOT here. So this
list could change quite a bit.

Andrew


2000/09/17      Channels can now be suspended - preventing anyone from using
                    or identifying for them. CS LIST/INFO have been updated.
                Fixed some cosmetic NS INFO bugs.
                Added support for Bahamut 1.4(07)'s +O channel mode.
2000/08/27      SJOIN now passes the real source of the SJOIN, for channel
                    modes, to do_cmode().
                The listnicks binary now displays the correct nick options.
                    Above two reported by Uziel <uziel@ingsoc.com>
                Fixed a bug with config option NSEnforcerUser not accepting
                    user@host values.
                0 (zero) is now a valid DefSessionLimit config value.
                ChanServ now bans *@* when a user enters a forbbiden
channel -
                    instead of just the user's host. Above two reported and
                    suggested by Mauritz Antunes
<mauritz@americasnet.com.br>
                Fixed a bug where do_cmode() was called for forbidden
channels
                    from check_kick() resulting in many log entries warning
                    about non-existant users.
                OS will not allow a server to be JUPE'ed if it's "visible"
to
                    Services. Suggested by Harvey Elliott <sh33pz@furl.org>
                Services now uses Bahamut's wildcard matching routine. This
is
                    to correct bugs in Services' internal wildcard matching.
                    From now on all wildcard matching is case-insensitive.
                    Bug reported by Stefan Funke <bundy@germany.net>
2000/08/16      Added a -noakill command line option. AKills will not be
                    enforced by Services when this option is used.
2000/08/13      Split NickServ and MemoServ memory usage statistics.
                OperServ can now be set to AKILL hosts that exceed their
                    session limit X times within X seconds. See the
                    SessionLimitAkill configuration option. Suggested by
                    Samuel Graenacher <sam@breakfree.com>
2000/06/26      Added SOP, AOP and VOP commands - a'la DALnet. These are an
                    alternative to the ACCESS command. See the WhatsNew file
                    for details about other changes relating to this.
2000/06/24      Reworked the numbered list and range handling code.



----- Original Message -----
From: "Dr. K. Hawkes" <k.hawkes@zombies.force9.net>
To: "IRC Services Mailing List" <ircservices@snow.shadowfire.org>
Sent: Saturday, January 13, 2001 2:26 PM
Subject: [IRCServices] IRCServices-4.5.0 Release Date?


> Hey there,
>
> Just 2 quick questions to the list here :
>
> 1) Is there anywhere I can grab a pre-release CHANGES file for
> IRC-Services 4.5?
>
> 2) Does anyone out there know when 4.5 will be released,
> either in Beta or as an official release?
>
> Thanking you in advance,
>
> Quinn
>
> ---------------------------------------------------------------
> To unsubscribe, send email to majordomo@snow.shadowfire.org
> with "unsubscribe ircservices" in the body, without the quotes.
>


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From &quot  Sun Jan 14 22:06:42 2001
From: &quot (&quot)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Bahamut 1.4(21) released
Message-ID: 097201c07eb9$5525e410$9c011ac4@africa.didata.local

For those that don't monitor the DALnet mailing lists, version 1.4.21 of
Bahamut has been released. It has some really big new features.

Some examples:

- RC4 streaming encryption added, diffie hellman key exchange
- zlib-compressed links added
- Oper hostmasking

You can get it from : http://bahamut.dal.net/

Now for the bad news, it has not been tested with IRC Services. However, it
should, in theory, work. When IRC Services will start supporting the new
features is another question entirely - one that I don't think anyone can
answer at this stage.

Andrew


---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From achurch at achurch.org  Mon Jan 15 15:33:12 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Why there's no public CVS
Message-ID: 3a629ae8.40200@prima&#45;lan.net

>> Speaking of 4.5.0, is there anywhere the masses can d/l this while it's
>> being worked on? Is there a CVS anywhere?
>
>I don't know about Andy, but I was reluctant to allow the general world to
>use under development source due to the number of unhelpfull bug reports I
>was getting. People did not seem to get the fact that the source was VERY
>alpha and as such didn't do many of the things it should - like saving
>databases or working properly. As things get closer to a final release it
>becomes easier to release it as beta code. 4.5 was getting very close to
>that stage when I last worked on it. However, Andy has to pick up where I
>left off, which means that it will probably be longer until it gets
>released.
>
>I hope this makes it clearer as to why the source was not released to the
>public.

     Just for the record, this is more or less my reasoning as well, though
for me it's simply that I _know_ the code won't work right and I don't need
dozens or hundreds of E-mails telling me that.  I plan to do like I did with
previous versions: when 4.5.0-to-be is more or less stable, I'll release
"pre-versions" (4.5pre0, 4.5pre1 etc.) for people to play with.

     P.S.  I'll get to the channel suspension stuff later--I have a bit of a
mail backlog to work through.

  --Andrew Church
    achurch@achurch.org | New address - please note.
    http://achurch.org/ | \e$B%a!<%k%"%I%l%9$,JQ$o$j$^$7$?!#\e(B

---------------------------------------------------------------
To unsubscribe, send email to majordomo@snow.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.


From beast at chat.za.net  Sun Jan  7 05:52:09 2001
From: beast at chat.za.net (beast)
Date: Sat Oct 23 23:01:05 2004
Subject: [IRCServices] Bahamut 1.4(21) released
References: <097201c07eb9$5525e410$9c011ac4@africa.didata.local>
Message-ID: 004301c078b1$35e02380$0d251ec4@e4d2v7