[IRCServices Coding] Services 5

[Andrew Church]

>I hope other people don't know so much about ircservices as you know about
>sourceforge. You probably wouldn't like to see your project  named as
>piece-of-shit-formerly-known-as-irc-services.

     Everyone's entitled to their opinions, and I suspect someone with that
opinion wouldn't be using it in the first place so I'd never have to deal
with them anyway.

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/

>>3) Not really, mostly because it would be a pain to set up and manage.
>>I may set something up once 5.0 has gone stable, but until then it's just
>>too much to deal with.  And I want absolutely nothing to do with the
>>piece-of-shit-formerly-known-as-Sourceforge.
>
>Joao Pinto
>Lamego at PTlink.net
>
>
>-----Original Message-----
>From: achurch at achurch.org [mailto:achurch at achurch.org]
>Sent: 14 December 2001 09:44
>To: ircservices-coding at ircservices.za.net
>Subject: Re: [IRCServices Coding] Services 5
>
>
>     Looks like this didn't get through the first time, so:
>
>1) No, because I have no clue how many bugs will turn up ;)  At this point
>I'm tempted to say beta in February and stable release in April or so, but
>I have absolutely no basis for saying that, so don't quote me on it.
>
>2) The notice is intended more for lamers who say "ooh it's version 5!" and
>rush to download it.  Feel free to use it on your production network, as
>long as you take responsibility for any problems it causes.  There aren't
>too many major issues right now that I can think of, but it's the ones I
>haven't found yet that worry me more.  (One major issue I do know of is
>that rehashing modules.conf doesn't work yet and could easily break
>things.)
>
>3) Not really, mostly because it would be a pain to set up and manage.
>I may set something up once 5.0 has gone stable, but until then it's just
>too much to deal with.  And I want absolutely nothing to do with the
>piece-of-shit-formerly-known-as-Sourceforge.
>
>4) For autojoin in particular, it was pointed out to me that not everyone
>always accesses IRC from the same computer, which would make client
>settings irrelevant.  In general, though, with the module system, I'm a bit
>more lenient in terms of what I'll let in, since you can just disable
>modules you don't need.  (And the reason for almost everything being
>enabled in the default config is so you'll all test them for me. ;)  Some
>will probably be disabled in beta/final releases.)
>
>  --Andrew Church
>    achurch at achurch.org
>    http://achurch.org/
>
>>Firstly, thanks to Andrew for releasing the alpha version. Hopefully he
>will
>>not feel that he has to later remove this opportunity.
>>
>>A few early questions that maybe Andrew or the Alpha team might be able to
>>comment on.
>>
>>1) Do we have any idea on time scale for development beyond alpha? I
>>understand that it is a difficult question to answer given RL committments
>>but based on work so far and this extended open test hopefully highlighting
>>major issues quite quickly, might make it easier to provide an estimate.
>>
>>2) Despite the warning not to run the alpha on a production network, it
>does
>>seem to be the best place to run it since it will give a much more
>realistic
>>test of the code. It is also very tempting to upgrade :) To this end, are
>>there specific known issues at this time with the current build that would
>>make it completely impractical to run on a small production network? The
>>"knownbugs" file does not seem to have anything specific to Services 5 and
>>nothing serious mentioned either way but those who have already had chance
>>to play with Services 5 may have a good idea of things that would make it
>>unsuitable for risking in a production environment.
>>
>>3) At present we seem to be restricted to the mailing list for bug
>reporting
>>and discussion which makes the process qyute closed. Has there been any
>>thought given to providing some kind of online tracking system which would
>>both show what bugs are currently known and their status? Maybe something
>on
>>sourceforge or similar system would suffice.
>>
>>4) I was wondering about the reasons for AJOIN being included in Services
>5.
>>It seems to place an overhead on NickServ that has been handled by many IRC
>>clients for a number of years. Even clients which do not specifically
>>support it, but that implement perform can easily provide AJOIN
>>functionality. Any client supporting scripting could easily manage an AJOIN
>>list. A number of clients support dynamic AJOIN lists by offering to
>>remember hannels that a user uses on a regular basis.
>>
>>Since part of the ethos behind IRC Services development is not to perform
>>tasks that really belong in IRCd or in clients or could be scripted, it
>>seems odd that firstly this system has been implemented and secondly it is
>>enabled in a default configuration.
>>
>>Is there something specific that I am missing about this services managed
>>auto join list which makes it preferable to the existing client code which
>>already performs this task?
>>
>>
>>Anyway, back to play around with the source some more.
>>
>>Mark.
>>
>>------------------------------------------------------------------
>>To unsubscribe or change your subscription options, visit:
>>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding