Feedback on the previous release cycle
Release BoF:
 * Feedback on the previous release cycle
   - Time-based freezes
     + Remind people of the freeze date more often as it gets closer.  Announce the exact date early.  Be assertive.
     + Announce the way the freeze will work early.
     + Limit the "carte blanche" exceptions at the start of the freeze to new debian revisions and not new upstream releases.
 * Things we are thinking about
   - Key packages
      + http://udd.debian.org/cgi-bin/key_packages.cgi (SLOW load time)
      + https://lists.debian.org/debian-devel/2013/05/msg00496.html
      + Are these criteria what we want?
   - Autopkgtest (DEP-8) => less delay to testing
      + If package + all rdeps have autopkgtest => 0 delay
        (though test failures will block the migration)
      + eventually remove the delay
      + add piuparts (and other tools)
      + assemble data on types of RC bugs filed within migration delay (claim: most of them could be supplied by automated tests)
   - Automated removals from testing
     + Completely automated (unlike now)
     + Any non-key package would be a possible candidate
   - Architecture qualification
     + "Hard" (unfun) decisions that ticks off some people: http://release.debian.org/jessie/arch_qualify.html
       idea: define hard(er) criteria, have fixed evaluation dates which result
       in todos with a specific date. then reevaluation, if not met, remove $arch.
       + provide evaluation results continuously, and not only at fixed evaluation time?
     + idea: split dsa-concerns into concerns (yellow) and blocker (red)
       [XXX: who's asking them?]
     + Make it easier to drop and re-add architectures to testing.
     + Installer criteria aren't clear - d-i is built on everything (except Hurd) but does it work (apparently not on armhf/mx5 at present...)

 * Use Freeze to remove old versions of packages:
   - e.g. remove python2.6 during freeze
   - Maybe limit it to "unfinished" ("small" set of packages)
   - might not work every time (e.g. Java 6 -> 7)
   - Should be done by maintainers themselves
   - Sometimes implies to rebuild lots of other packages.
   - The idea isn't to postpone this kind of cleanup to the freeze, but to allow it
     during the freeze too.

Continuously working d-i:
we can't release without d-i. d-i needs love.
More rapid d-i release cycle would help.
 - uploads are happening more often now, and jenkins CI is helping to catch bugs... we will see in jessie how the situation with d-i changes.

Toolchain maintainers would like to drop support for archs that are not maintained (at the toolchain level), the same as they did for Java. Most packages in the archive still build for these archs.

Porters are aware that there are problems (e.g. lack of stable porter box).

Idea: make it clear to sponsors (of machines) what we need to support $ARCH (and when).
The porters might want to do that (if they're not doing it yet).

Idea: remove $ARCH only from testing and allow it to re-enter easily once (DSA)-criteria are satisfied. (aka reduce in-out friction)
      But is it realistic to see $ARCH catch up later?