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

Re: Bug#1023731: BioC Transition blocked by new dependencies



On 2022-11-21 16:39:26 +0100, Andreas Tille wrote:
> Hi Sebastian,
> 
> Am Mon, Nov 21, 2022 at 03:05:26PM +0100 schrieb Sebastian Ramacher:
> > On 2022-11-21 15:02:16 +0100, Andreas Tille wrote:
> > > Control: block -1 by 1024563
> > > Control: block -1 by 1024565
> > > Control: block -1 by 1024567
> > > 
> > > Some of the BioConductor packages need new dependencies.
> > > I have pushed these to new queue and set the ITP bugs as
> > > blocker.
> > 
> > As this is happening every r-bioc transition, could this be handled
> > before starting the transition the next time?
> 
> This is really hard to do, thought.  The new packages are needing those
> packages from the transition.  I actually injected two packages from
> higher levels manually to be able to build one of the new packages.  So
> we really need to upload the start of the transition and I do not see
> any sense in not documenting what we are doing without the transition
> tracker.

Others have already answered this part.

> 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.

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.

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.

Cheers
-- 
Sebastian Ramacher


Reply to: