Re: gabt-core and minia - still updatable for bullseye?
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
Reply to: