Topics:
1/ How to keep using security.debian.org for Wheezy's LTS support period?
2/ What do we support for Wheezy LTS?
3/ How to handle embargoed issues?
4/ Misc questions
   - What to do when issue is not fixed in unstable?
   - What to do when issue is not fixed in stable?


Notes:

Topic 1 - Usage of security.debian.org for wheezy's lts period
--------------------------------------------------------------

Risk of seeing embargoed issues by LTS team members.
-> not an issue if we don't have a queue with packages to accept
Risk of unsupported architectures being not in sync.
-> drop the architectures from the suite at that time
Easy to drop the "queue" in front of the security suite.
-> let's do it and reconsider if it turns out to be a problem

Problem:
ACCEPTED mails redirected to team@security and not to the uploader/maintainer
-> ftpmaster already plans to send mails to the person who signed the upload

Benefits:
- no delay for mirroring
- no change to sources.list

We assume that we would not use EMBARGOED queues and just upload
at the right time. Downside: some builds will come a bit later.


Topic 2 - Packages / architectures supported for wheezy LTS
-----------------------------------------------------------

Review the list of unsupported packages:
Addition of armhf?
-> not for wheezy, might make sense for jessie

Support all architectures which (still) have buildds? 
-> difficult to ensure buildability everywhere, time better spent elsewhere


Start again from the current wheezy support list and work it out from
there on a case by case basis. We should aim to not exclude virtualization
related packages from support, even if at the cost of upgrading to a newer
upstream version.
	pmhahn: be careful when upgradeing qemu/ipxe/seabios/toolchain: This might change the RAM-layout (PCI-BARs) and breaks restoring previous snapshots and prevent live migration
	pmhahn: for Xen there is the is also a pre-disclosure-liste, where sometimes backports of fixes are posted (according to ijc)
	agx: libvirt might require updates when qemu is updated

asterisk
axis2c
bugzilla
chromium-browser
  -> need newer g++, already unsupported
couchdb
drupal6
ffmpeg
  -> not in wheezy, but libav may have same problems
flashplugin-nonfree
fusionforge
gksu-polkit
gridengine
horde3
iceape
icedove
iceweasel
kolab-cyrus-imapd
libplrpc-perl
libv8
libvirt
mahara
mantis
mediawiki
moodle
movabletype-opensource
openswan
piwigo
qemu
qemu-kvm
rails
serendipity
smarty
smarty3
spip
textpattern
turba2
typo3-src
vlc
wireshark
xen
xen-qemu-dm-4.0
zabbix

=> filter that list for packages available in wheezy and review packages
one by one based on sponsors data and analysis of the level of support
we have in Debian (active maintainer?)

Topic 3 - How to handle embargoed issues?
-----------------------------------------

Suggestion made on the mailing list a few months ago:
create lts-team@security.debian.org an alias to volunteers willing to handle
such updates.
=> it's doable

=> aliases can't be subscribed to closed linux-distros list but security team
   could forward relevant mail (if allowed); OR
=> have one person from LTS subscribed to linux-vendors to represent the
   interest of the project (and forward data at his discretion to the above
   alias)

Topic 4 - Misc questions
------------------------

What are we supposed to do when the bug is not fixed in unstable?