* Paul Gevers: " Bug#1089934: src:tryton-server: fails to migrate to testing for too long" (Mon, 16 Dec 2024 20:36:26 +0100):
Hi Paul,
> On 16-12-2024 08:08, Mathias Behrle wrote:
> > tryton-server is rdepends of all tryton-modules-*, and some of those modules
> > depend in the new series 7.0 from some of the new Tryton modules currently
> > stuck in NEW.
>
> Did you know this before you uploaded? Please try to avoid this
> situation in the future by uploading new things you need to experimental
> first and wait until they are processed by ftp-master before uploading
> existing things that depend on them.
Did that, been there, and exactly didn't get the information which pieces of
the whole suite wouldn't migrate. Running autopkgtests in salsa against
experimental is poorly (i.e. not in all test parts) supported.
Perhaps I did some things utterly wrong, but read below.
> By the way, pinging ftp-master on IRC often helps.
Well, I think ftp-masters have their own schedule to get their work done. I
don't feel it the right way to push ftp-masters for own packages. If everyone
does that, they just have to handle more input instead of doing the real work.
> > I don't think I can do anything about this but waiting for NEW being
> > processed.
>
> Well, we could remove the things that are depending on these new things
> from testing, then the things that are ready can migrate.
I should disable autopkgtests of quite basic modules? Its mostly in
autopkgtests that functionality of extras_depends are tested.
> > Please adjust this bug accordingly.
>
> What do you propose exactly? The Release Team does consider packages
> that are out-of-sync with testing for more than 30 days to be RC buggy.
If the definition of a missing dependency waiting in NEW for more than 30
days depending on the workload of ftp-masters fits your definition of
RC buggy then be it.
The assumption
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable.
is just wrong in this case. The bugs can be very well fixed via unstable, if
yes, the dependencies currently in NEW will be in unstable.
That's why I come back to you: the time frame of 30 days may not be appropriate
for the underlying case. And that is the choice of the release team, not mine.
> There is a solution for this bug in your control (you're not going to
> like it, I know) but you could revert to the previous versions of the
> packages that are now in testing.
At a second glance: I won't for sure revert in unstable to a version that will
lose support during the lifetime of trixie. And if the Tryton series 7.0 won't
make it into unstable/testing then better to not not ship trixie with Tryton
6.0 at all.
That said I should probably agree that removal of Tryton series 6.0 from
testing is the right way. I disagree that it is a bug in the packages, it is a
bug in the workload of our teams.
Cheers
Mathias
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
pgpCoGcPjapWf.pgp
Description: Digitale Signatur von OpenPGP
