Authors

Public Pad

Revision 11
Saved June 5, 2011
Current state: Done!
 
Agenda:
  • (done) Squeeze release wrap-up / retrospective
  • (done) Release goals
  • (deferred) RC Policy
  • (done) Time-based freeze
  • (done) team membership?
  • (done) 0-day NMU policy
  • (done / deferred) Arch (re)qualification
  • (done) britney2/3/sat solver
  • (done) next {old,}stable point release
  • (done) stable feedback process?
  • (done) #debian-release-private
  • (done) communication/cooperation maintainers?
  • (done) NMU campaigns/BSPs?
  • (done) non-urgent removals from testing
  • (done) Debian live et al
  • (done) udebs/tdebs/ddebs
  • (deferred) Browsers/graphics drivers in stable
  • (done) CUT/rolling/making something more attractive for new development
 
Minutes:
 
Squeeze feedback collection
Good
  • high quality release
  • wifi works but didn't in other distributions
  • bts handling (tags)
  • unblock handling
  • communication (personal and announcements) improved
  • length of time between releases
Bad
  • dc9 freeze discussion / announcement
  • ack
  • freeze announcement
  • ack
  • freeze duration
  • would time-based freezes help?
  • clairty of process / policy
  • see action items
  • manpower
  • administrative / co-ordination vs technical; role of RMs
  • better tracking / distribution of ongoing work
  • more involvement of / delegation to resources outside of the team
  • better tools to manage tracking of unblocks, review of larger patches?
  • find / talk to interested people?
 
Team membership
  • What is membership - gid, hint file, orga page, something else?
  • SF/NT/NW/CB/PW/JH
  • maulkin prodded inactive members to confirm intentions
 
Time-based freezes
  • In theory, good idea
  • Previous schemes for picking freeze dates:
  • Number of RC bugs
  • When RC bug rate flatlines
  • When kernel/gnome/kde/stuff is ready
  • Possible problems
  • will kernel be ready? (Probably)
  • d-i? (Probably not? How to solve: Release early and often? Start releasing before freeze dates?)
  • Not ready to freeze (Freeze anyway)
  • Date picking, or pick a month? neilm to propose a month - June?
  • When? (Announcement and actual date for freeze?)
  • reminders
  • BTS tags should be used before freeze date
  • Try for one release only so far
 
Britney
  • This is the right time in the cycle to move to a new britney
  • Propose that we make b2 the reference migration engine (in compatable mode)
  • Keep b1 running
  • Stop b1 when we stop caring about diffs between b1 and b2, but don't deliberately break it. Change b2 to non-compatable mode.
  • adsb to look at running b2 in non-compatible mode, look for bugs etc
  • SAT solver sounds nice. adsb to follow-up post-sprint.
 
Arch (re)qualification
  • current release architectures
  • architectures in unstable but not currently release architectures
  • at least one buildd able to keep up with security for stable
  • "technology preview"
  • hardware
  • hurd
  • architectures not in unstable
  • e.g. sh4, powerpcspce, sparc64, armhf, s390x
  • new hardware available to buy without NDA
  • existing porters
  • stats for existing archive coverage and up-to-dateness, ideally using debian-style buildds although probably not DSA-maintained. luk suggests 75% of packages which "make sense" on the architecture. Must be able to keep up with unstable with no more than 2 buildds. Must have buildd redundancy.
  • porter box already available
  • d-i support for at least one popular machine / board for the architecture
  • upstream support, particularly toolchain / kernel
  • Vetos: DSA/Security/RM/SRM
 
Release goals
  • multiarch
  • $DEITY yes
  • kfreebsd
  • release arch status achieved. is a new goal to improve status for wheezy desired?
  • talk to -bsd
  • boot performance
  • done
  • maybe new goal for boot reliablity? (services started before network)
  • package quality
  • more measurable targets?
  • old libs
  • sanitize bdb list
  • ipv6
  • needs more advocates, testers, bug fixers, etc.
  • lfs
  • needs an advocate, review of tagged bugs
  • new source package format
  • done / dropped
  • .la files
  • need to talk to aba. luk suggests replacing with emptying dependency_libs, which is more targettable
 
Potential new goals
  • selinux
  • maulkin to talk to RC
  • DNSSEC
  • needs definition. maybe done?
  • grub2 by default
  • needs checking. very small number of issues
  • python2.7 by default
  • transition
  • stop using /dev/dsp
  • 7 bugs tagged oss-removal
  • poke broonie
  • v4l v1 removal
  • poke bwh
  • build time test suites
  • zack added, who's advocating?
  • run time test suites
  • zack added, who's advocating?
  • /run
  • in progress
  • fhs 3.0
  • needs review, advocate, blah, blah, pony
 
Next {old,}stable point release
  • Need to do squeeze first, then lenny
  • Find out from bwh what's happening with the squeeze kernel update for hardware support he mentioned on -release recently
  • Squeeze d-i reroll?
  • Earliest would be 18th June. If not, 25th?
  • We would need a FTPmaster, a Sledge and a press person
 
stable feedback process
  • ability to submit feedback via queue-viewer (release.d.o/proposed-updates/{old,}stable.xml)
  • ability to link bug reports and possibly to tick some boxes about basic testing of the package ("installation worked", "basic functionality worked", etc.); possibly with automated checking if a named bug is closed
  • pkern to look at patches to queue-viewer and a submit script
 
0-day NMU policy
  • s/0/2/ as a way forward?
 
#debian-release-private
  • Got rid of it, there's no point and is not-a-good-thing(tm) to have private channels. Can make a new one as/when needed.
 
Debian live et al
  • Problem: we didn't sucessfully release Debian Live CDs at the same time as a full release
  • Reasons: It wasn't working well as part of the release process
  • Option 1: Debian Live is integrated as part of Debian CD
  • Option 2: Continue using current live build system
  • Suggestion: All official CDs must be built using debian-cd (option 1)
  • Reasoning for picking this option: The process of building Debian Live is complicated by it not being 'close' to a mirror, and the time taken to build the images is long. This means that it would be much harder to actually release as it's not integrated with the release process. Integration with debian-cd would ensure that all images are available at the same time.
  • Should DL not want to pursue this route, we will try and support it on a best effort basis, but cannot guarantee holding up the release to ensure that live images are available. This should also apply for any other install images (not just live) should they appear at a future date.
 
NMU campaigns/BSPs
  • How to encourage these?
  • Release team need to coordinate these events.
  • NMU camapaign = ongoing effort (eg: translation campaign) for a final goal. Release goals could be good candidates
  • We need to describe what this is more
  • maybe create a new team?
  • BSP = traditional time limited RC bug squishyness
  • Put info in each bits mail?
  • Focus on upcoming / ongoing / recently completed campaigns or BSPs
  • Encourage RC bug hunters.
 
communication/cooperation maintainers
  • When asking sets of core teams to contribute, we should send this to -devel (for example) and if 'core teams' aren't responding, we need to prod them.
  • Tell people that ries is available for helping!
 
CUT/Trolling/making something more attractive for new development
  • What is testing for?
  • Original announcement said it is to make stable releases easier (It's for making stable ponies)
  • This has moved on, but shoudn't be used as a distribution that people expect to not be broken at all times. Critical bugs can still reach testing without being noticed much easier than stable, and at times it is not possible to transition packages to testing without breaking testing eg:
  • perl5.12 got entangled with eglibc (force hint broke libsvn on kfreebsd only)
  • CUT
  • We don't mind. Someone else is doing the work? We remain to be convinced that testing is actually broken all that often or all that badly anyway, see above.
  • d-i to install CUT would be good and help ensure that d-i is able to install testing
  • Rolling/Bob
  • Kate is short for... erm...  Bob.
  • Don't mind as long as there's no negative impact on stable releases / the freeze. "Negative impact" includes asking release team members to do the work.
  • Making 'wibble' more exciting to work on
  • Experimental should be easier to use (eg: move from experimental to unstable via dcut or something)
  • Experimental should be easier to have in your sources.list (see backports for example, lower pin value than unstable?)
  • Inform our users of breakage/removals/etc… (e.g. using an RSS feed?)
  • any DD should be able to add his own items there
  • maybe discuss this with the Press team
 
non-urgent removals from testing
  • tool to locate likely candidates
  • RC buggy (in testing and/or unstable)
  • mails to -devel and maintainers saying e.g. "we intend to remove package Y from testing in a week's time due to wibble, blah, foo, bar and monkey" - for both manual and automatic removals
  • new file containing e.g.
  • # ACTIVATEON: YYYYMMDD
  • # PACKAGE: gibbon
  • # REASON: too noisy
  • # BUGNUM: 123456,123457
  • which could then be parsed to
  • auto-generate mail
  • auto-generate a new "removals" hints file which can only contain "remove" hints
  • This is expected to be the usual way of removing problematic (eg: RC buggy) packages
 
Browsers/graphics drivers in stable (deferred)
  • Firefox 3.5 is in stable and unstable.  So there's not really a way to stuff a new upstream version into stable.  It's possible that Chromium might go there at some point because the upstream fixes cannot be backported anymore.  We should look if we could get a (maybe co-installable?) Iceweasel 4 into stable at that point, maybe.
  • 'And a half' releases most likely won't happen for squeeze.
  • Kernel to update during point releases anyway
  • What about graphics drivers?
 
udebs/tdebs/ddebs/xdebs
  • Release team would like not to deal with udebs in a special way anymore.
  • Does d-i currently maintain source for its binaries?
  • Not for lenny potentially, should do now (SRM check before a point release)
  • Can d-i be given a hint file?
  • Now that dependencies and conflicts fields in udebs are sorted, can't d-i go through the archive, so that magic auto migration happens?
  • pkern has some thoughts on how the d-i side could work
  • d-i binary packages with correct dependencies on the needed udebs
  • Other sorts of "special" packages should not require manual handling by the RT
 
Actions
  • check whether any additional functionality / views / filtering could be included in the udd views
  • compare to btz.tz functionality
  • documentation
  • glossary
  • update / improve britney / testing documentation
  • release notes maintenance
  • documentation of SRM stuff
  • ensure ongoing maintenance of documentation when policies are created, updated, etc
  • review of team website
  • internal and wider; what's wrong with it, what would people like to see on it?
  • how would people like documentation provided?
  • formats?
  • review / update RC policy
  • maulkin to investigate code review tools
  • mention that release.d.o is synced to ries
  • pkern looks at squeeze and lenny point release scheduling
  • mehdi to point Ralf/Zack to the SAT britney idea (done)
  • they'll reply soonish… (monday or tuesday)