Emilio Pozuelo Monfort wrote: > On 20/01/2025 13:24, Yavor Doganov wrote: > > gnustep-base > > Level 2: > > dbuskit > > gnustep-corebase > > gnustep-gui > > gnustep-netclasses > > gnustep-performance > > pantomime > > rsskit > > sbjson > > sope > > universal-detector > > Level 3: > > camera.app > > cenon.app > > charmap.app > > gnustep-sqlclient > > gomoku.app > > gorm.app > > grr.app > > lynkeos.app > > paje.app > > sogo > > systempreferences.app > > unar > > Level 4: > > gnustep-dl2 > > gworkspace > > Level 5: > > addresses-for-gnustep > > steptalk > > Level 6: > > adun.app > > agenda.app > > gnumail
> Since we're close to the freeze, what's the fallback plan if things > don't go as planned? I guess you ask what will happen if a problem arises *during* the transition? We'll fix it, and this will reset the clock with 2 days (a newly discovered bug will probably be in a core package and all of them have autopkgtests). But what is likely to slow down the transition is the large number of sourceful uploads. There is no plan to revert to the current (old) layout. Although that's technically possible without much hassle, we don't want it. > Also, of the many packages that FTBFS, how many can you upload > directly, e.g. due to team maintenance? All of the packages are maintained by our team except: - sbjson/sope/sogo: Their team is active and I believe they can make timeful uploads. - adun.app: I'm a member of debian-med and thus have commit/push access but would need a sponsor (usually the current DPL sponsors it without much delay, after a ping on their list). - paje.app: It's a concern because its maintainer is somewhat inactive. I can prepare a NMU and send a reqeuest to -mentors (our DD doesn't sponsor NMUs); the change is a one-liner.
