Agenda
======

 * Architectures:
   * review architecture qualification process
     o add requirement on suite for buildds
   * architectures for trixie
   * what to do with i386?
     o no installer, no kernel -> still release architecture?
   * Proposal:
     * We anticipate that kernel, d-i and images teams will cease to support i386 in the near future
     * Following that, two routes into running i386:
       1. as a multi-arch option on an otherwise amd64 system
       2. as a i386 chroot on another architecture system
     * Architecture:any will still contain i386 so everything builds by default
     * Maintainers who wish to drop i386 support can do so with rdep coordination
   * We have no opposition to changes to baseline (it's a port matter)
 * freeze policy for trixie
   * accept-list for new upstream releases during freeze (key packages)
   * longer freeze to facilitate d-i
   * timeline: align start with Ubuntu/Python/...?
 * RC policy rebuild requirement
   o build failures are RC, but our rebuild promise is for binaries
   o accepting building with nocheck profile is better than several other RC bugs
   o similar to our arch support policy packages should reasonably support uncommon build setups
     (e.g. accept maintainable patches for 1 or 100 cpu hosts)
 * "Tier" proposal
   o elbrus will stop persuing OoS architectures as an officially supported TIER as too
     many practical problems came up in the discussion
   o We do believe that PwS architectures would be a nice addition on the ports side
 * state of the team
   * the team remit is also a monster
     - Idea: document (e.g. on Wiki) the different roles and how is/feels responsible
     - Split the debian-release list -> stop taking the bugs on the list
         On-topic: stuff that's within our deligation or around the boundry
      [elbrus] first mail the team
      [elbrus] then move to tracker address
   o Extending the team: call for volunteers
     - Buy in by adding a hint file as Trainee?
     - Detail how starters can get involved:
       1. review unblock requests and "approve" or even hint (only works in freezes)
       2. review stable requests and get as far as upload, then someone else will approve
       3. be a manager for individual transitions - co-ordinating, checking, bug reporting and maybe scheduling
       4. tooling work, including from bug reports
     - Do we have 
 * Discussion with to other team:
   o ftp for blocking toolchain packages during build
   o ftp for not accepting transitions in unstable (or is this de-facto accepted?)
     https://lists.debian.org/debian-devel/2023/01/msg00040.html
   o DSA for discussion on tier proposal
   o 
 * britney improvements
   o Reproducible build results
   o Configurable level-n dependency triggers (autopkgtestPolicy)
   o [Fresh] check for RC bugs in testing where the version in unstable is not
     a decendent of the version in test
 * review existing release.debian.org bugs
 * Improving the release (day) work flow
  o https://lists.debian.org/debian-release/2020/05/msg00180.html
  o https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838106


Agenda
======

 * Architectures:
   * review architecture qualification process
     o add requirement on suite for buildds
   * architectures for trixie
   * what to do with i386?
     o no installer, no kernel -> still release architecture?
 * freeze policy for trixie
   * accept-list for new upstream releases during freeze (key packages)
   * longer freeze to facilitate d-i
   * timeline: align start with Ubuntu/Python/...?
 * RC policy rebuild requirement
   o build failures are RC, but our rebuild promise is for binaries
   o accepting building with nocheck profile is better than several other RC bugs
   o similar to our arch support policy packages should reasonably support uncommon build setups
     (e.g. accept maintainable patches for 1 or 100 cpu hosts)
 * "Tier" proposal
 * state of the team
 * Discussion with to other team:
   o ftp for blocking toolchain packages during build
   o ftp for not accepting transitions in unstable (or is this de-facto accepted?)
     https://lists.debian.org/debian-devel/2023/01/msg00040.html
   o DSA for discussion on tier proposal
   o 
 * britney improvements
   o Reproducible build results
   o Configurable level-n dependency triggers (autopkgtestPolicy)
   o [Fresh] check for RC bugs in testing where the version in unstable is not
     a decendent of the version in test
 * review existing release.debian.org bugs