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