Added support for Readline, which should simply adding receipes

Hmbf, should use the correct variable

Two external resources added that also contain references to some conferences

Added attribution

Ups, wrong year

Adjusted for LinuxTag 2004

Adjusted for LinuxTag 2004

Finally copied the configuration into this file so we can start for
next year.

Implemented search functionality again.

No need to keep the comments

This seems to be required if the right column is not "long enough".

Corrected the year

Copied the current set of files for the new year.

The edit link is not helpful, the link to assignments of that
particular person are more useful.

Sort the list case-insensitive

Err.. no section available for people

Added support for people who are supporters not primarily

Ouchi, should sort by title if we depend on it later...

Make the price for the social event configurable

Use the configurable price for the social event

Added support for phone numbers in the index listing

Stop sorting case-sensitive

Yay, there will be a social event

Pre-select the main sleeping facility in the limitation selection

I'm permitted to fill up the AKK with up to 90 people, hence I'll stop
counting at 85 and add supporters if available.  Don't hardcode the
name either.  (sync with other file)

Hmm, apparently, we didn't quote enough.

Oh dear, the link was long non-existant already...

Added support for removing comments, it's been part of update already.

Added support for adding the date of a comment when inserting it.
This makes sense when copying text from mails.

Added support for the comment of a project.

Added a link to the admin listing

This page will reveal the list of project admins for me

Shold properly filter out supporters and sleepers

Don't send out the password when an existing account is to be used

Small update to ensure that people know that the account is only valid
this year.

Don't send out a new password mail when an older account was only adjusted.

Hmm, interesting, there weren't enough of %d

The date was wrong, missed two more incarnations

Hmm, the date was wrong

Finally, the sleeping facility is fixed, great work KALUG!

Eeeks, should assign the result...

Cosmetic update

Cosmetical changes and stricter rules for adding a job

If the main project is changed, the resulting user record must not
have the admin flag set, otherwise he would be able to take over
another project.

Stupid constraint, can't cheat anymore, need to filter out here.

 . The whole DELETE mechanism became more complicated:

   1. Only delete the person record if this was the last project the
      person was a member of.

   2. If the person is a member of more than one projects, only remove
      one junction record.

   3. Take care of the case where the primary project is the one the
      person is removed from.  In this case the person record needs to
      be updated.  Here, another project, randomly choosen, will be
      used as new primary project.

 . The whole INSERT mechanism became more complicated:

   1. Only insert a new person record if the person does not exist
      already, hence, this needs to invesigated first.

   2. Only insert a new junction record if the person is not a member
      of that particular project (= Supporter) already.  This needs to
      be invesigated first as well.

   3. Insert a junction record if the person is not already a member.
      This is important since the system believes that such an item
      exists for all projects a person belongs to.

Pass the current project as context through so the following update
can differentiate between the current context and the primary project
of the person.  This is important for removing, for example, since the
person should probably be removed from the proper project (context).

Provide a means to set the primary field of a person to a particular
one through a normal select box that displays all projects the person
is a member of, but only if he's a member of more than just one single
project.

The list of people needs to be extended to reflect the situation in
which some people are members of many projects.

Also corrected the HTML code and tried to make it clear that the Name
E-Mail fields are only alternatives to the select box.

Expanded the query to gather the list of project members.  Since a
member doesn't need to be a member of this project in the first place,
need to investigate the junction relation instead of the primary
project field only.

Expanded the query to gather the list of project members.  Since a
member doesn't need to be a member of this project in the first place,
need to investigate the junction relation instead of the primary
project field only.

Additionally, append the current project as context to the named link
so the following edit can get its links correct and can differentiate
between the current context and the primary project of the person.
This is important for removing, for example, since the person should
probably be removed from the proper project (context).

Since the query to gather the list of supporters is expanded in
phptools.inc the calculation of all members is snafu (it contains
doubles).  Hence, we need to calculate it differently again, so it
only reflect unique people.

 . Don't hardcode the project, since the primary project of an item
   could be something else than 'Supporter' and we must not overwrite
   this.

 . The whole DELETE mechanism became more complicated:

   1. Only delete the person record if this was the last project the
      person was a member of.

   2. If the person is a member of more than one projects, only remove
      one junction record.

   3. Take care of the case where the primary project is the one the
      person is removed from.  In this case the person record needs to
      be updated.  Here, another project, randomly choosen, will be
      used as new primary project.

 . The whole INSERT mechanism became more complicated:

   1. Only insert a new person record if the person does not exist
      already, hence, this needs to invesigated first.

   2. Only insert a new junction record if the person is not a member
      of that particular project (= Supporter) already.  This needs to
      be invesigated first as well.

   3. Insert a junction record if the person is not already a member.
      This is important since the system believes that such an item
      exists for all projects a person belongs to.

The list of people needs to be extended to reflect the situation in
which some people are members of many projects.

Added support for the new semantic of projects:
 . default the project to 'Supporter' for later processing
 . don't hook the project to 'Supporter', since we may also edit
   somebody whose main project is something else
 . When editing an account display the main project (and others) if
   there are more than 1, otherwise just transmit the information hidden

Expanded the query to gather the list of supporters.  Since a
supporter doesn't need to be supporter in the first place, we'll have
to investigate the junction relation instead of the primary project
field only.

Deambiguification

This should be the current version.

A social event is not yet finalized and so is the cheap sleeping space

Include the configuration from ltp.conf

Added symbolic longer names, used for job assignments

Forgot one day and added the web location

Converted to use the tags from ltp.conf

Configuration for the entire LTP system

This file is obsoleted by ltp.conf

Changed the default to opt-out infomails, people can still unsubscribe
from them, but the information is important and they should be forced
to read it, at least at the first place.

Raised the events since they are edited mostly

Finally added support for half typed date strings which really should
be sufficient.

The new PostgreSQL is more picky about correct syntax.

The server does not escape slashes anymore, we'll need to do that manually

The server does not escape slashes anymore, we'll need to do that manually

Whoops, can't sort case insensitive

Better place small letters between upper case ones, that's less confusing.

We don't need that many lines

Use a better default value for the city

LinuxTag 2002 is over, but after a LinuxTag is before a LinuxTag.
Hence, we're continuing the development for next year's event.
The current version is exported and should be added to
www.open-events.org soon.  The first set of changes include:

 . Changed style file (changes the db on service.infodrom.org)

 . Changed the title (to make it use the general macro)

 . Use a tag for all days, so the iso date specification is only noted
   in the style file and not in all source files.

New style for the next event

Removed unused code

Added the year

Whoops, didn't remove all of it...

Development and organisation for 2003 has already started

Copy (fork) of the code for 2002 so we can start development for 2003

Small update to make the year menu more flexible

Removed unused code

Added flexibility code

*grr*  No wonder we found some problems...

Added more tests

Looks like that was a leftover from a copy action

Standardizing of links

Fixed a problem with double assignments when assignments weren't found
by the test query.  It missed two cases anyway...  I've also added a
little bit of documentation to the file.

 . Fixed handling of DELETE, i.e. make it actually delete a person
 . Improved handling of sending passwords, they will only be sent out
   if inserting or updating succeeded.

Rather stupid thing, create three passwords, ignore the first, store
the second in the db and mail out the third.  Well...

With this small patch, it's actually possible again to remove people
from the list.

Added information about the social event

Err, small bugfix

 . Added sane defaults in case an address is a list
 . Moved the insert_nili()
 . Moved password randomisation and sending via mail behind all
   queries, so it won't happen in case inserting failed
 . Also fixed a nasty field ordering bug

Added more restrictions to which fields will be available if an
address is indeed a list

Damn f*cking cut'n'paste error...

More correct view of different nightplaces, only displayed if there
are more than one different places.

Beaten by the time representation hack...

Nitpick, but the subject should be the same.