Control: tags -1 confirmed
On 23/01/2025 01:47, Yavor Doganov wrote:
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.
Let's go ahead.
Cheers,
Emilio
