[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

debconf6 video and infrastructure wishlist and notes


To be able to plan and request the debconf6 infrastructure, I have made a 
proposal about the video teams wishlist, which has received no feedback (so 
far), so I had to guess, so I think that everyone agrees :-)

The next step (after discussing this here) will be to put the information 
gathered here into taskjuggler (our demands, to keep track of the request, 
etc) and onto the website (network information for the participants, video 
team workflow, video team manuals and call for video-volunteers).

Basic infrastructure:
- master & servant (like in HEL): dhcp, dns, syslog-ng, nagios, munin, 
	- IMHO two machines are not mandatory, though very nice to have
- printers (located where?, how many)
- for installing and managing I propose roughly the same framework (d-i plus
FAI) as we used at debconf5, to get an idea what I mean, please read
"Proposal: how to setup and manage the computer infrastructure"
and http://layer-acht.org/fai/fai-at-debconf5/
- this time I really want to test those configurations in xen, qemu, vmware 
_before_ debcamp starts...

- what kind of uplink will we have ? we do control it 100%, do we ?
- what ip-range will we use (NAT real ips) ? will we have incoming 
connections ? what restrictions do we want ? 
- what kind of wireless do we want ? No encryption, WEP, WPA, xsupplicant ? :)

The video teams wants/needs
- dedicated video-editing room
- LDAP-server with account data for comas, website and all machines at
debconf6; besides the obvious users (everyone) we also want a videoteam-group
to grant special permissions like write on the videoraid etc.
- two gigabit-switches: one in the server room and another in the
video-editing room
- a 2TB-raid with nfs-mounts on all video machines (see below), writeable for
videogroup members
- two video-laptops with big internal disks (80gb), firewire and external 
- two presentation laptops with acroread, evince, xpdf, opera, istanbul
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316503) and whatnot?!
- the two build-machines from debconf5 could be used as number-crunchers for
the video team - at dc5 these machines where almost not used at all. IMHO be
should try to get and setup such machines again (they might be used more if
announce properly and in advance) and make a plan how to use them for video
(encoding..!) in any case.
- three video editing desktops with dual-cpus and dual-tfts, two would be ok,
but three is much nicer...
- micophones, mixers ?

- mandatory software on the video machines:
	- at least linux-2.6.12 (for working firewire)
	- raw1394-access for users in the videoteam group
	- dvgrab, sarge version is ok
	- ffmpeg (from cvs)
	- ffmpeg2theora (latest version)
	- kino, sarge version is ok
	- cinelerra-cvs (in a sid chroot, with mount --bind /home)

- nice to have softwhere:
	- whereami on the video & presentation laptops

- the video team has four basic workflows which should be described in more 
detail in a manual before debconf6 :-) (So people can more easily 
	- dvgrab etc. (get the raw videos from tape and harddisc on the raid)
	- cinelerra (post-processing)
	- ffmpeg/ffmpeg2theora (encoding)
	- upload to a local mirror and meeting-archives.debian.net

Step 5 is creating the dvd(s), but IMHO it's neglectable in this scenario, as
it's the very last step, likely to be done after debconf. Please object if
you think different :-)

It would also be very nice to integrate the papers (incl. their sources) into
this workflow... I would suggest to add another "job" in our volunteerplan
(the spreadsheet Henning maintained at debconf5..). This time we should
collect these files during the conference and upload instantly and together
with the video.

btw, the licence situation (of the talks and videos) will be taken care of in
COMAS (our conference management system) directly, something like "people
who'll commit talks will have to choose a (proper) licence at commit time".


Attachment: pgpKpVNiflXEv.pgp
Description: PGP signature

Reply to: