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

Re: Bioconductor 3.19 transition



If there are no objections, I'd like to upload the new r-bioc-biocgenerics to experimental and continue on with the rest of bioconductor 3.19

More comments below, thanks!

On 10/07/2024 02.09, Charles Plessy wrote:
Le Tue, Jul 09, 2024 at 05:41:31PM +0200, Michael R. Crusoe a écrit :

However, in the mean time I would like to see the next version started. Would you object if I began to upload Bioc 3.19 packages to "experimental"?

Hi Michael,

on my side, I am leaning towards skipping the release entirely.  Next
Bioc release is in 4 months already.

I understand that. Did we have problems skipping releases before?

As it was, I had to do a local build of over 90 bioc packages to confirm that the newly needed packages for 3.19 worked.
So it would be about another 80 packages to update, which I don't mind doing now that I've gotten practive.


In any case, I wonder if we really need to go to experimental now that
the bulk of (or all of?) the r-bioc-* packages have been removed from
Testing.  Thanks to this, packages with minimal dependencies outside the
Bioconductor universe can now migrate independantly, isn't it?  The only
thing that remians to be careful of is the interaction with other
transitions.

If we still go for a massive upload to experimental, then I think that
it would be neat to add an --experimental option to routine-update.

That exists, yep!
I've been using

```
git checkout -b debian/experimental
routine-update --no-build --experimental --branch debian/experimental -t
```


Also, shall we exclude i386 systematically from now on?  I find that the
slow demise of this architecture is very taxing, as it causes us to
remove packages one after the other with no planification nor
automation.  As we do not have good tools to manage which architectures
we build and release on (everything has to go to uploads or bug reports
to over-busy teams), I think that we should just pull the plug entirely.

If they are 32-bit issues, then I'm fine with excluding them using `architecture-is-64-bits` and allowing the relevant autopkgtests to skip archs where the dependencies aren't available.


Have a nice day,

Charles

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


Reply to: