Hi Steffen, On Tue, Feb 16, 2021 at 07:56:06PM +0100, Steffen Möller wrote: > > I realised new upstream versions of gatb-core and minia even in January > > - but it was to late for the transition freeze. I think upgrading > > gatb-core is definitely a transition and affects several packages while > > we learned in the past (the hard way) that gatb-core upstream does not > > mind about ABI compatibility. > This at some point is worth a rant - how the ease of using git > subprojects destroys good ole software development practices. And - if > the scientific development is so fast that an old API holds no > scientific value then they have a point.
I personally see scientific purpose and technical implementation as somehow orthogonal. Flagging an API change by proper versioning is a technical detail. I trust upstream that a change in the scientific purpose might be implemented most sensibly by changing the ABI. That's fine but not declaring this fact is not. > > So IMHO it is not OK in unstable (but > > for sure it is fine in experimental). > Hm. I just pushed to salsa as unreleased. These uploads to experimental > I never liked since this should have dual semantics. I don't like it either and my solution is to wait after the next stable release with the next version upload. I do not believe that there is a relevant number of users who obtain packages targeting at scientific research from experimental. Thus IMHO experimental is just our technical playground for library migrations, testing simde patches or something like this. Consequently I do not use experimental for plain version bumps. Besides this I consider my personal time not well spent for version-bump uploads to experimental in times of freeze. I've recently heard the argument that for fast changing upstreams this could save some time. But I do not buy this argument since if some changes in upstream enforce packaging changes in addition to routine-update I can do those changes once inside the next development cycle. To my experience this is less time consuming than several version bumps. > > IMHO there is no optimal timing for a sprint since there is always > > sufficient work to do. I hope my definitely incomplete list of tasks > > for the sprint[1] will prove me right. ;-) > No worries. Definitely not. I was just mentioning it. > > [1] > > https://salsa.debian.org/med-team/community/sprints/-/wikis/202102_debian-med_sprint_online#tasks-for-the-sprint > > > > Referenced from https://wiki.debian.org/Sprints/2021/DebianMed Thanks for watching me - I intended to do so after creating the page ... and than forgot. ;-) Kind regards Andreas. -- http://fam-tille.de
