On Mon, Nov 21, 2022 at 06:11:41PM +0100, Andreas Tille wrote: > Hi Adrian and others, > > Am Mon, Nov 21, 2022 at 06:33:52PM +0200 schrieb Adrian Bunk: > > > 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. > > >... > > > > Your transition is special because you are manually uploading every > > single package involved in the transition. > > > > You could upload everything to experimental, run a local ben tracker > > against experimental, and when the transition is complete in > > experimental contact the release team for the transition in unstable. > > > > The actual transition is then a batch of "Upload to unstable". > > Thanks for all helpful hints. I understand that with some effort over > the current workflow it is possible to do the transition differently. > The only thing which I did not yet understood is the actual drawback of > the current workflow. I do not think that it takes specifically longer > than other transition - we just have a different set of showstoppers to > get it done in 24 hours.
Personal experience+opinion: I have been involved with quite a few bioc transitions and often times you and me were the _only_ people who did the entire transition. I have noticed several times that the NEW processing takes quite sometime, and the way forward (for me) has been to manually patch the DESCRIPTION file to patch it to be compatible with new r-bioc api until the dependency from new is accepted. The new processing time tends to create delay with respect to bioc packages migrating to testing and this creats a terrible amount of noise. And then what comes next is a bunch of workarounds to get things moving, and this takes a quite a lot of energy at my end which I'd like to spend somewhere else. I have not been entirely happy with the way it happens, and would like if we can do the transition differently with less friction, less days of wide-uninstallability. The advantage with a reprepo thing that Sebastian suggests is that everything (possibly) will migrate as soon as it is uploaded. Once you have stored the sources into a reprepo, all you need to do is run a script to do all the uploads. > In the past we got support by ftpmaster when > pinging them and explaining the transition issue. Which takes time as well, and at least my experience regarding transition new processing has not been quite same as you. Lastly I also want to higlight that: while bioc transition is in theory a transition (I agree) but to my understanding, there is no _real_ API change. It is just the tool taking the API field from DESCRIPTION file into consideration, and causing FTBFS if it does not match. In principle, building a package that has an older API value in DESCRIPTION file with the newer one does not break anything, it rather looks as updates of various packages disguised as an API change, and at least in debian land, to me it just appears as a broken tool config and not a real transition (like library transition, for example the recent onetbb one). -- Best, Nilesh
signature.asc
Description: PGP signature
