Unreal4 Development

Unreal4 is a fork of InspIRCd. UnrealIRCd will sync its code with InspIRCd. The goal is to make this fork feature-complete to produce a modern Unreal. Do also view our main development site - has information on teams and such.

• Read through the documents below and for the http://bugs.unrealircd.org url's, point out your observations on what is missing
• Check out our SVN and play with it, find bugs and things that are missing, comment about it
• Stay in our IRC channel, #unreal-devel, on irc.unrealircd.com
• If you have interests in joining one of our teams, contact the team leader
• If you can code or contribute, do so, we are welcoming patches of any kind.

• Code guidelines: http://www.inspircd.org/wiki/Coding_Guidelines - we follow same due to we are probably going to send some patches upstream.
• Server protocol: http://www.inspircd.org/wiki/InspIRCd_Server-to-Server_Protocol_Documents
• Things that really need an overhaul in Unreal4 that Unreal3 does stupidly: http://bugs.unrealircd.org/view.php?id=3446 (post here if you have stuff you have opinions on)
• Things in InspIRCd/Unreal4 that are stupidily done and needs an overhaul: http://bugs.unrealircd.org/view.php?id=3451 (post here if you have stuff you have opinions on)
• TODO list, on bugs.*: http://bugs.unrealircd.org/view.php?id=3417
• Things that are missing in Unreal4 that are in Unreal3, http://bugs.unrealircd.org/view.php?id=3441
• http://dev.unrealircd.com/bugtracker_conventions#global_filters_of_interest_for_qa has a lot of RSS feeds that list bugs you can work on, test, etc.
• Bugtracker conventions, submitting patches procedure, etc. - Important read if you want to report bugs, is in QA, wanting to contribute patches, etc.
• Various: Small study on Insp vs U3 size source/compiled/stripped sizestudy
• Module API differences from InspIRCd: apidifferences

svn checkout svn://svn.unrealircd.com/trunk/unreal4

http://cvs.ircsystems.net/cgi/viewvc.cgi/UnrealIRCd%20SVN/trunk/unreal4

We will be syncing towards InspIRCd 1.2 fixes and not trunk from the time of InspIRCd 1.1.10 release, as there will be major breakage in the trunk from that moment. We will however be using trunk again once 1.2 is stable. This will allow us space to work on making a stable Unreal4 without having to work on an IRCd in pieces.

CIA.vc page for Unreal4: http://cia.vc/stats/project/Unreal4

RSS: http://cia.vc/stats/project/Unreal4/.rss

Target: A “modern” UnrealIRCd without the shackles of the old code base that can last at least 8 more years.

UnrealIRCd will work with InspIRCd to tackle the core issues shared by both products. This will allow contributors to exchange features between the two. UnrealIRCd and InspIRCd will complement, not compete with, each other.

Reasoning:

• The code base of Unreal3 is stale. The needed improvements are difficult and would take a long time to complete.
• It's difficult to find coders willing to consume months to learn the Unreal3 code base.
• InspIRCd was (partly?) inspired by UnrealIRCd, as the two are quite similar.
• The cooperation of UnrealIRCd and InspIRCd will help the two projects to cover a broader spectrum, providing the user with more choices.
• UnrealIRCd would have slowly died out due to this brick wall of problems and the weight of the Unreal3 code base.
• UnrealIRCd can better affect the IRC community through this cooperation, keep the user-friendly attitude of UnrealIRCd, and keep the project.
• This will expose the InspIRCd code to a lot more users.
• UnrealIRCd will keep the modular compatibility of InspIRCd. This will benefit itself and InspIRCd, as any feature available for InspIRCd will be available to UnrealIRCd, and vice versa.
• UnrealIRCd will be able to continue providing its users with a proper IRCd that can last yet another 8 years.

Unreal3 will continue to be maintained as long as adoption of Unreal4 doesn't overwhelm the the adoption of Unreal3, with bug fixes and some features to aid in the transition from Unreal3 to Unreal4.

In the future UnrealIRCd will work on issues that InspIRCd would never touch, but our users request, to make Unreal4 as feature rich as Unreal3. Unreal4 will live in the same spirit as all prior Unreal products have, complete with support channels, documentation, and professionalism.

• Milestone 1: (Discovery, teams setting up) [DONE]
  • Set up svn.unrealircd.com [DONE]
  • Release 3.2.7 (Planned 14th July) [DONE]
  • Find differences between client interface for current U4 commands and U3 commands. Find what modules are needed to be feature-equal with Unreal - http://bugs.unrealircd.org/view.php?id=3451 [DONE]
  • Find missing features that are in U3 but not in U4. - http://bugs.unrealircd.org/view.php?id=3441 [DONE, sortof]
  • Brand U4 so it doesn't reference to InspIRCd in daily running more than needed [DONE]
  • Announce strategy change: [DONE]
    • Unreal3.* getting phased out, but maintained and bugfixed until a stable Unreal4 is ready. Will not have major features. Unreal3.2.8 will arrive at some point with changes to support linking to Unreal4 and bugfixes.
    • Unreal4 - fork of InspIRCd
  • Set up developers team, QA, documentation, supporters and assign leaders to these. [DONE]
  • Set up proper bugs.*, forums.*, new website [DONE]
  • Look into possibilities for linking an Unreal3 server with Unreal4 server: Two fronts, danieldg's perl bridge, and work on making a u3 patch for linking to u4. [DONE]
  • Set up formal procedures for sending patches upstream to InspIRCd [DONE]
  • Set up semi-automated sync with downstream patches [DONE]
  • Set up development sites with references how to do things [DONE]
  • Brand fork as Unreal4 [DONE]
  • Drop cygwin support [DONE]
  • Set up ./configure that is simple, and ./configure –advanced for all the options [DONE]
  • Implement u3 config parser for Unreal4, and one that works backwards compatible with InspIRCd's ConfigReader interface. [DONE]
  • Keep up sync with insp code until they branch for 1.2 [DONE]
• Milestone 2:
  • At this point QA, supporters, documentation team should be active.
  • Involve popular Unreal-supporting services to support Unreal4
  • Implement missing features (this will have a lot of subnodes)
  • Fix cosmetic differences between Unreal3 and Unreal4 (this will have a lot of subnodes)
  • Implement link, maybe via netbridge between U3 and U4. This is meant as a temporary measure to help people transition to U4 from U3.
  • Make u3 config format for U4 more like U3 - through transformations of the conf structures
  • New build system: buildsystem
  • New oper type system: operstyle
• Milestone 3: Unreal4.0-beta
  • Release beta, test throughly, check if transition works from U3 to U4 for networks.
• Milestone 4: Unreal4.0 release
  • Release Unreal4.0, check adoption - if adoption successful, drop 3.2.* support after 4 months.
  • After this, sync with current SVN of InspIRCd trunk (1.2), gaining the new reworked stuff etc. http://inspircd.org/wiki/Roadmap
• Milestone 5: The future
  • Start adding the features we've been wanting to play with for years.

Inspircd features a more enhanced way of defining opers. Opers aren't divided into predefined groups, but instead totally customizable. This is a big advantage over the old style, but also has some problems that needs to be dealt with. One big problem is that an opertype consists of several classes. A terminology used for what is called connect now. This will be a huge step in u4 support, as a class is a connect for years now. It would be better to rename <connect …> to <class …> and call the new oper class definitions e.g. flag definitions. flag netadmin { …. } and then opertype { foo; flags { }; bar; }

I'll start out by my overview of how the state of the UnreaIIRCd project was when I started having the consideration if to kill the UnrealIRCd project or not.

• We have lost the only person who has any kind of proper overview of what goes on in the UnrealIRCd code these days - I know IRCd basics but most of the new changes, Syzop failed to document properly.
• We had 3 coders - me, aquanight, WolfSage - last two had only an entry level knowledge of how the IRCd worked - but more than the usual contributor and enough to work on features and bugs, but not huge changes. Other coders had been in the play but they were more unreliable than danish trains.
• Through stirring up the development community through taking active part again, cleaning up bug tracker, we got some new people a little active - but they lack the ability to work on the remaining big issues of UnrealIRCd that has been haunting us for ages.
• The whole ircd code is simply a horrid monster to work with and takes more than 4 years to master properly.
• I (Stskeeps) don't have time to use half of my week on Unreal matters, due to studies, work, gf, etc. needed to do the major changes
• Realising the project would surely, slowly die, as it had already made hints of it would be doing, we had two options - kill it now or let it slowly die and leave our users in doubt about the project

Slowly dying would/could have caused this:

• Some users would keep on running stock Unreal, some networks with network only patches for security / improvement, returning to the whole business of per-network IRCds
• Entry level new IRCd admins would have difficulties getting hold of these patches and therefore decide not to run IRCd - or be unhappy with their IRCd setup - maybe run off to other IRCds - InspIRCd, ratbox, charydbis, Ultimate, etc
• People would run to InspIRCd because it's the most like Unreal. Fact is - InspIRCd is not always good with users, bug reports, and InspIRCd with the sudden inflow would collapse under it's own weight, developers not wanting to develop on it, users frustrated they cannot get proper support. InspIRCd prefers to just code nicely on the IRCd “cos it's fun - if it works for them, it is good” - though this attitude seems to be changing with this move.
• Users would therefore stop running IRC networks or move to other technologies, contributing to the death of IRC.

Quickly dying:

• We signal on unrealircd.com that we're stopping development, offer links to people who start forks or Unreal-related projects, maybe ideas on projects, and we give up leadership of the brand or anything dealing with it - causing the passionate people about Unreal to get scattered and this move would most likely contribute to death of IRC as well, and user dissatisfaction.

Talking to some of our users about this move, Stealth suggests a radical move instead - to keep the project alive but change things radically.

We look around - how can we improve our situation? We can't start from scratch. It took InspIRCd 5 years to get to sane stability.

It would be stupid to base off any of the other current ircds - we would just rehash the same bugs of the past that haunts every single ircd

Upsides of this move:

Redundancy: InspIRCd dies - unreal continues, someone wants an Insp - they just unload all modules. Unreal dies? People can fork and keep on syncing their code with InspIRCd easily, keep the unreal branch going with updates.

Better I/O engine support - kqueue, epoll, and I/O completition ports on Windows.

The fact they gained windows support instead of cygwin.

Fresh code base, free of the bugs of the past - lost messages, etc.

“Free work force” - InspIRCd “works” for us and we may choose to contribute back if we share interest in a matter. - and reverse.

Many of the InspIRCd community members are former Unreal users - many who still like the form of Unreal and the principles - and this has shown in the last couple of days too - that means, many new recruits who want to make a difference on a “bigger” IRCd

We can fix what's wrong with InspIRCd - they want not to include dependancies or when they think they can code it themselves (remote includes - http client, we write it ourselves instead of using something sane).

We have a different attitude towards users in general and listen more to what networks would like (this view may vary)

For the matters that we share same opinion, we have a louder voice together with InspIRCd. In the future, more traditional IRC networks would move to InspIRCd if the conditions are right.

The module API is 200x easier to learn than Unreal3 API, making it possible for people to easier enter into the project and code and move on to core issues

UnrealIRCd doesn't want to be InspIRCd and InspIRCd doesn't want to be UnrealIRCd, yet we share some same concerns - performance, server protocol, modularity

Downsides:

There is craq in the code and many stupid things, but not as hard to fix as to fix Unreal3.2.* - this view is from the side of our paradigms and ideas.

We'll have to take the blow of the incoming InspIRCd bugs - which may require some taking users in the hand and guiding them through reproducing and telling us the information we need.

The trolls disliking InspIRCd now hates us :)

The fact it's C++ and old shell providers (versions) don't work properly with it

It takes up more space, but there are things we can do to help that.