New GRF-freenode process

As you might know, GRFs (Group Registration Forms) exist to form a relationship between a project and the PDPC (Peer Directed Projects Center). This relationship is relatively formal – personal details (address/tel no./etc) need to be shared by the project. For this reason, a severe backlog of GRFs has built up, since only a few staff have access to them (to protect this personal data). PDPC is the UK-based not-for-profit company which runs freenode. For most groups in our request backlog, their reason for registering is not to work with PDPC, but to gain a channel or cloak namespace on freenode. We’ve decided that running a separate, freenode-centric groups request system may help to move the system along. By requesting fewer details, we can open up this system to more staff, and hopefully keep on top of the queue of requests.

From now on, using a new, shorter form, projects can choose to file a GRF-f (for GRF-freenode) and submit a GRF for processing by freenode, rather than by PDPC. This sends details (no personal details, other than email address, will be required) to a system to which many more staff will have access. This new form will allow you to gain control of a channel and the right to issue cloaks much more quickly than previously, as we will double/treble the number of staff able to deal with requests. For now, please only apply if you are a ‘priority’ group – ie, you do not own the main channel of your namespace.

If you already have a group registered and approved with an old-style GRF, you do not need to do anything. Your registration remains valid. If you need to make changes to the registration, please contact staff on freenode who will, if appropriate, direct you to use the old (GRF) system. The GRF-f system cannot be used to update groups which filed under the GRF system.

If you have a request pending in the old GRF queue, you are welcome to re-file under the GRF-f system. This is likely to mean that your request will be dealt with much more quickly than otherwise. This approach supersedes the grfprocess@ system introduced a while back – unfortunately, we just weren’t able to keep up with requests to that address.

You might be wondering where all of this fits into the GMS (Groups Management System) masterplan. When GMS is ready, we may need to ask all projects registered under the GRF-f system, and likely some projects which are already registered, to re-file. The GMS system will allow us to dispense with GRF-fs, and just build project<=>PDPC relationships, since forms will be able to be processed much more quickly. To be clear – it is quite possible that any registration made now may be revoked if a registration is not re-filed after GMS is released. If this does become reality, as much warning as possible will be given.

We hope that this will change will counter some of the ill-feeling around the GRFs system. In effect, the mentality is shifting from one of “GMS will clear the GRFs backlog” to “GMS will help us to serve groups better”. We’re no longer waiting for GMS to clear the queue. We’re still looking for help with GMS: if you have Perl/Catalyst or web design experience and think you can help, join #freenode-gms.

Update 2012-06-09 – All group registration has been suspended whilst we evaluate the system and its implementation. A replacement should be available in due course, but for now it is not possible to register groups, and the link to the grf-f form has been removed.

Wednesday Server Updates

This Wednesday (September 14th, 2011) we will be continuing our server updates as mentioned here.

The following servers will be affected: leguin, gibson, wolfe, hitchcock, and pratchett.

During the update process these servers will be restarted and anyone connected to them will need to reconnect. You may wish to connect to an alternate server if you are currently connected to one of these.  You can check what server you are currently connected to using the command “/whois nickname” with your own nick as “nickname”.

We apologize for any inconvenience as we continue to improve the technology behind freenode.

Update: This is now done.

IRCD Upgrades

Over the next weeks we will be upgrading our servers to the next version of ircd-seven. This means restarting all our servers. Downtime should be minimal, and as we will not upgrade all servers at the same time this should not be as noisy as the upgrade from hyperion to ircd-seven was. When the server you are on is upgraded you will be disconnected, but should be able to reconnect immediately (most clients will do this automatically).

The following user-visible changes have been made since the versions in production:

– The channel quiet list is now sent using the new numerics RPL_QUIETLIST(728) and RPL_QUIETLISTEND(729) instead of overloading the same numerics as for ban lists. You may find that clients have to be updated before they will display this in a user-friendly format.
– Users who cannot send to a channel are now prevented from changing its topic, even when mode +t is not set.
– Sending a private message to another user while user mode +g is active will now automatically add an accept-list entry so that they can reply.
– Account names are now displayed in WHOWAS entries.
– Two new client capabilities are available: ACCOUNT-NOTIFY and EXTENDED-JOIN. These two together with the existing extended WHO syntax allow clients to track account names of other users who share a channel.
– Client flood control settings have been made configurable; you may notice them being stricter than before.

Once all ircds have upgraded we also plan to re-enable the +S channel mode, which only allows users connected using SSL to join.

Some more features will become available once we upgrade services, which will happen at some point after we have upgraded all irc servers:

– It will be possible to identify to services using SSL client certificates.
– ChanServ mode locks will be (mostly) enforced by the server. Instead of setting a mode and having ChanServ revert it immediately, you will not be able to change a locked mode.