Bug#1023731: BioC Transition blocked by new dependencies

[Andreas Tille <tille@debian.org>]

Control: block -1 by 1024582

Am Mon, Nov 21, 2022 at 07:16:14PM +0100 schrieb Sebastian Ramacher:
> > However, to make us understand your suggestion better:  Is there any
> > drawback on your side if the transition of a closed set of packages if
> > the transition is delayed by new processing?
> 
> Some packages are also involved in other transitions. For example,
> currently a hdf5 transition is prepared in experimental. While we could
> now also start the hdf5 transition, completing hdf5 would not be
> possible until this one is done.

Thanks a lot for making me understand the problem.
 
> Now replace the hdf5 transition with another lock-step transition such
> as this one. Then we suddenly have two set of packages that can only
> migrate together. Especially for lock-step transition a quick turn
> around is thus greatly appreciated.

If I understood that BioConductor packages should not block other
transitions.  I've just pinged ftpmaster on IRC to check packages
r-bioc-bsseq, r-bioc-dss, r-bioc-biocbaseutils and r-cran-ggrastr.
The following packages are blocked by the packages in new:

   r-bioc-bitseq - should be removed from testing immediately bug just filed)
   r-bioc-multiassayexperiment
   r-bioc-demixt (bug #1024597 was just filed)
   r-bioc-scater
   r-bioc-mofa (just due dependencies)

Do you want me to file RC bugs against r-bioc-multiassayexperiment,
r-bioc-scater and r-bioc-mofa.

> I will remember for the next time that I'll ask you to stage everything
> in experimental or to give me a list of packages that require NEW
> dependencies so that we can get those removed early in the transition to
> not hold of the transition by NEW delay.

I agree that the BioC transition should not habe a negative effect
on other transitions.  If RC bugs against the blockers are a valid
solution to prevent this I'd fully support this.

Kind regards
   Andreas.

-- 
http://fam-tille.de