[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1107456: closed by Ivo De Decker <ivodd@debian.org> (Re: Bug#1107456: Acknowledgement (pre-unblock: uncertainties/3.2.3+really3.2.2-1))



reopen 1107456
thanks

Ivo De Decker wrote:
I'm going to close this bug, as there isn't really a question for the release
team here. Feel free to reopen it (or file a new one) if you need something
from the release team.

You are right and I apologize for my lack of clarity.

The question *would* have been: Would we have the support from the RT
to solve the uncertainties sudoku by uploading a revert?

However, after I sent the bug I realized this is not a good solution,
as we can still fix everything which is currently broken and
reduce the difference between testing and unstable.

The new plan will be as follows:

(CC to involved parties for their information)

I've uploaded fixed versions of lmfit-py and pymatgen. They
are compatible with both old and new uncertainties, but their
old autopkgtests are the reason why uncertainties can't migrate
to testing right now:

https://qa.debian.org/excuses.php?package=uncertainties

Because this is a chicken-and-egg problem, I will ask
(in a few days) for both lmfit-py and pymatgen to be
unblocked, and after they migrate to testing,
the autopkgtests for uncertainties will finally pass
and it can migrate to testing without help.


And there is indeed a question related to all this: If we
make a new upload of uncertainties which just adds a breaks
against old lmfit-py and old pymatgen, would that really
tell the testing migration machinery that they should not run
the old autopkgtests of lmfit-py and pymatgen with
the new uncertainties?

(i.e. Would those Breaks help the migration?)

(I think that was the original plan from Colin, which I now
believe it's the best path to follow)

Thanks.


Reply to: