Discussion:
dcm2niix -- I have an intent to take over (still under Debian Med team), objections?
Yaroslav Halchenko
2018-12-03 20:36:19 UTC
Permalink
Dear Team Comrades,

Upon blessing from Ghislain Antony Vaillant (previous team maintainer)
and Chris Rorden (upstream, CCed) I would like to take over the
maintenance of dcm2niix. And I would like to do it largely by taking
the dcm2niix packaging setup we have in NeuroDebian.

bits of history

- we have initially packaged dcm2niix long ago (Sep 2015) but
forgot to file an ITP because there were a number of outstanding
license issues to be resolved before considering for "Debian
proper".

- Rightfully so, without seeing an ITP, Ghislain provided separate
packaging in Dec 2016.

- I don't remember at which stage licensing issues got resolved ;)
and that is when I realized that there is already a package in Debian.
so we started to talk with Ghislain in Jan 2017 about possibly merging
the effort, but never converged.

Chris asked me to take over maintenance in Debian as well, and Ghislain
blessed me as well. To minimize amount of work for myself, I would like
to continue with NeuroDebian packaging, just polishing it up (copyright
file and may be some cleanup). How NeuroDebian packaging is
different (dropping historical perspective) ATM it is at
http://github.com/neurodebian/dcm2niix

- main difference is our git repo sitting on top of the upstream so we
also can produce an .orig. tarball with dcm_qa submodule which
provides data for testing of correct operation. That increases the
tarball size but IMHO it is worth it!

- we run (build-time only ATM) tests using that dcm_qa/ data. That
already allowed to iron out differences in behavior between i386 and
amd64.

I expect though that testing for all the other platforms would open a
huge can of worms. But I think it would be beneficial in the long
run to name them all ;) I bet Chris (the upstream) would be
"thrilled" to help nailing them down

any objections on relying on gbp to produce orig source tarballs?

- in a rush toward "let's converge packaging" I have added needed then
epoch 1: to the versioning. It would need to "propagate" into
Debian. I hope that is ok

- we still use debhelper 9 for maximal ease of backportability.

any objections?

- we do carry a few patches
https://github.com/neurodebian/dcm2niix/tree/debian/debian/patches
including patches for the packaging backports on elderly jessie (and equally old ubuntus)
https://github.com/neurodebian/dcm2niix/blob/debian/debian/patches/jessie-dsc-patch
probably some symlinks for really old /EOLed ubuntus could be removed,
will do now

But any objections against carrying backport patches?

Please let me know what you think
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
Andreas Tille
2018-12-03 21:00:09 UTC
Permalink
Hi Yaroslav,
Post by Yaroslav Halchenko
Chris asked me to take over maintenance in Debian as well, and Ghislain
blessed me as well.
Fine for me.
Post by Yaroslav Halchenko
To minimize amount of work for myself, I would like
to continue with NeuroDebian packaging, just polishing it up (copyright
file and may be some cleanup). How NeuroDebian packaging is
different (dropping historical perspective) ATM it is at
http://github.com/neurodebian/dcm2niix
Please do not do this. The development platform for Debian packages is
salsa.debian.org and *lots* of QA tools are relying to find the packaging
code here. I do not mind about the team but I mind a lot about the host
any Blends package can be found.
Post by Yaroslav Halchenko
- main difference is our git repo sitting on top of the upstream so we
also can produce an .orig. tarball with dcm_qa submodule which
provides data for testing of correct operation. That increases the
tarball size but IMHO it is worth it!
I do not mind about the tarball size.
Post by Yaroslav Halchenko
- we run (build-time only ATM) tests using that dcm_qa/ data. That
already allowed to iron out differences in behavior between i386 and
amd64.
I expect though that testing for all the other platforms would open a
huge can of worms. But I think it would be beneficial in the long
run to name them all ;) I bet Chris (the upstream) would be
"thrilled" to help nailing them down
any objections on relying on gbp to produce orig source tarballs?
- in a rush toward "let's converge packaging" I have added needed then
epoch 1: to the versioning. It would need to "propagate" into
Debian. I hope that is ok
We all know epochs are ugly but sometimes needed.
Post by Yaroslav Halchenko
- we still use debhelper 9 for maximal ease of backportability.
any objections?
No.
Post by Yaroslav Halchenko
- we do carry a few patches
https://github.com/neurodebian/dcm2niix/tree/debian/debian/patches
including patches for the packaging backports on elderly jessie (and equally old ubuntus)
https://github.com/neurodebian/dcm2niix/blob/debian/debian/patches/jessie-dsc-patch
probably some symlinks for really old /EOLed ubuntus could be removed,
will do now
But any objections against carrying backport patches?
No.
Post by Yaroslav Halchenko
Please let me know what you think
All those packaging details sound sensible but please, pretty
please stick to salsa.d.o.

Thank you for your work on this package

Andreas.
--
http://fam-tille.de
Yaroslav Halchenko
2018-12-03 21:39:21 UTC
Permalink
Post by Andreas Tille
Hi Yaroslav,
Post by Yaroslav Halchenko
Chris asked me to take over maintenance in Debian as well, and Ghislain
blessed me as well.
Fine for me.
Post by Yaroslav Halchenko
To minimize amount of work for myself, I would like
to continue with NeuroDebian packaging, just polishing it up (copyright
file and may be some cleanup). How NeuroDebian packaging is
different (dropping historical perspective) ATM it is at
http://github.com/neurodebian/dcm2niix
Please do not do this. The development platform for Debian packages is
salsa.debian.org and *lots* of QA tools are relying to find the packaging
code here. I do not mind about the team but I mind a lot about the host
any Blends package can be found.
I would be happy to move it to salsa. I just pointed to it as the one
we currently use

I guess I would then move it to dcm2niix-epoch1 smth like that (on salsa
i.e.) so previous versions could be found from the original
dcm2niix repo (to which I would also add a commit obliterating
everything and stating to look into that -epoch1 repo)
Post by Andreas Tille
Post by Yaroslav Halchenko
- main difference is our git repo sitting on top of the upstream so we
also can produce an .orig. tarball with dcm_qa submodule which
provides data for testing of correct operation. That increases the
tarball size but IMHO it is worth it!
I do not mind about the tarball size.
I also didn't but current one (280MB) made me think... not sure yet what
thoughts it would give ;)
Post by Andreas Tille
Post by Yaroslav Halchenko
... removed all agreeed upon ...
Please let me know what you think
All those packaging details sound sensible but please, pretty
please stick to salsa.d.o.
sure
Post by Andreas Tille
Thank you for your work on this package
Cheers!
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
Ghislain Vaillant
2018-12-04 05:39:15 UTC
Permalink
Post by Yaroslav Halchenko
Post by Andreas Tille
Hi Yaroslav,
Post by Yaroslav Halchenko
Chris asked me to take over maintenance in Debian as well, and Ghislain
blessed me as well.
Fine for me.
Post by Yaroslav Halchenko
To minimize amount of work for myself, I would like
to continue with NeuroDebian packaging, just polishing it up (copyright
file and may be some cleanup). How NeuroDebian packaging is
different (dropping historical perspective) ATM it is at
http://github.com/neurodebian/dcm2niix
Please do not do this. The development platform for Debian packages is
salsa.debian.org and *lots* of QA tools are relying to find the
packaging
Post by Andreas Tille
code here. I do not mind about the team but I mind a lot about the host
any Blends package can be found.
I would be happy to move it to salsa. I just pointed to it as the one
we currently use
I guess I would then move it to dcm2niix-epoch1 smth like that (on salsa
i.e.) so previous versions could be found from the original
dcm2niix repo (to which I would also add a commit obliterating
everything and stating to look into that -epoch1 repo)
Please use the original packaging work on salsa and keep the history intact.

I don't see what would prevent you from rebasing the work done on
Neurodebian on top of mine. Epoch bumps don't justify history rewrites or
new repositories, imo.

Unless I misunderstood your intent. It's not 100% clear to me.
Post by Yaroslav Halchenko
Post by Andreas Tille
Post by Yaroslav Halchenko
- main difference is our git repo sitting on top of the upstream so we
also can produce an .orig. tarball with dcm_qa submodule which
provides data for testing of correct operation. That increases the
tarball size but IMHO it is worth it!
I do not mind about the tarball size.
I also didn't but current one (280MB) made me think... not sure yet what
thoughts it would give ;)
Post by Andreas Tille
Post by Yaroslav Halchenko
... removed all agreeed upon ...
Please let me know what you think
All those packaging details sound sensible but please, pretty
please stick to salsa.d.o.
sure
Post by Andreas Tille
Thank you for your work on this package
Cheers!
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
Andreas Tille
2018-12-04 06:49:43 UTC
Permalink
Post by Ghislain Vaillant
Post by Yaroslav Halchenko
I would be happy to move it to salsa. I just pointed to it as the one
we currently use
I guess I would then move it to dcm2niix-epoch1 smth like that (on salsa
i.e.) so previous versions could be found from the original
dcm2niix repo (to which I would also add a commit obliterating
everything and stating to look into that -epoch1 repo)
Please use the original packaging work on salsa and keep the history intact.
I don't see what would prevent you from rebasing the work done on
Neurodebian on top of mine. Epoch bumps don't justify history rewrites or
new repositories, imo.
I agree with Ghislain. Feel free to simply rebase your packaging but
please keep the same repository name. We have the policy that the
package resides in a repository with the same name as the source package
(and some of our tools are relying on this) and I do not see any reason
to diverge from it. There is also no point in keeping an unused
repository of the old packaging around.

Kind regards

Andreas.
--
http://fam-tille.de
Yaroslav Halchenko
2018-12-04 14:08:34 UTC
Permalink
Post by Andreas Tille
Post by Ghislain Vaillant
Post by Yaroslav Halchenko
I would be happy to move it to salsa. I just pointed to it as the one
we currently use
I guess I would then move it to dcm2niix-epoch1 smth like that (on salsa
i.e.) so previous versions could be found from the original
dcm2niix repo (to which I would also add a commit obliterating
everything and stating to look into that -epoch1 repo)
Please use the original packaging work on salsa and keep the history intact.
I don't see what would prevent you from rebasing the work done on
Neurodebian on top of mine. Epoch bumps don't justify history rewrites or
new repositories, imo.
I agree with Ghislain. Feel free to simply rebase your packaging but
please keep the same repository name. We have the policy that the
package resides in a repository with the same name as the source package
(and some of our tools are relying on this) and I do not see any reason
to diverge from it. There is also no point in keeping an unused
repository of the old packaging around.
I am still wondering what I should do about dcm_qa* submodules. I keep
thinking about making a dedicated package (dcm2niix-qa) shipping them.

Without that, I could of cause bring (merge) upstream git tree into your
packaging repo, with all the submodules, but that would "ruin" the clean
history it has now. I would not be able just to "rebase" my packaging
on top without a merge if I am to bring submodules.

Meanwhile, pushed my adjusted neurodebian packaging to
http://github.com/neurodebian/dcm2niix
debian branch, which AFAIK should be good to go as long as we figure
out dcm_qa* situation. Will do a full sweep of builds and if all is
good, upload to NeuroDebian interim
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
Loading...