Bug#976113: Bug#954823: Sponsorship of hydrogen
Hi Ross, Updated package upload to mentors, and pushed to the WIP branch called rfs-976113-rebase. I've of course merged this to master locally, so that the debian release tag will exist on the correct branch. Let me know if there's anything else you'd like to see. Other than that, reply follows inline: Ross Gammon writes: > On 30/12/2020 00:55, Nicholas D Steeves wrote: >> Ross Gammon writes: > OK - I think we are a bit too close to the next Debian release to be > making things complicated. Maintaining a library complicates upgrades to > new versions if transitions are required, and can be problematic if the > the ABI is not stable. I don't know how stable the hydrogen library is. > Why don't we just stick to how it was structured before it was removed? > That way users of Hydrogen in making music (like me) can just use the > application like they used to. > Done. > We have to go through the NEW queue to get hydrogen into the next > release, so making the ftp-master review as simple as possible (with a > rock solid copyright file) is the least risky approach. > Copyright should be good. I did at least three full reviews in 2020, including one just now. > I think the main reason for splitting stuff out into a *-data package is > to split the architecture dependent files from the architecture > independent files. When looking at the contents of the old hydrogen > package, you could question some of the decisions between the -data and > -doc packages. > Ah, yes that makes sense :-) > Maybe after the release we can think about helping developers of > potential plugins, and moving files around between packages? That is > unless the previous structural decisions contributed to any bugs! > > We can always backport new versions for users of Debian stable after the > release if there is a demand. > Agreed, and I like your plan for this case. Thank you, Nicholas signature.asc Description: PGP signature
Bug#976113: Bug#954823: Sponsorship of hydrogen
Hi Nicholas, Dropped one of the bugs from "To:" (leaving only the RFS copied in). On 30/12/2020 00:55, Nicholas D Steeves wrote: > Hi Ross, > > Ross Gammon writes: > >> I have spent some time going through the commit messages. There has >> been a lot of work done! > Yes :-) If I remember correctly, cdbs -> dh, and upstream churn between > prereleases was the worst of it. > > > Will do! The WIP branch is called "rfs-976113-rebase" and I pushed it > just now; it doesn't contain much yet. I will update mentors as soon as > we have an upload candidate (still too many outstanding big issues at > this time). >> I was wondering why the library packages suddenly appeared. I think if >> it is possible, it is best to stick to the old packages. What >> applications would want to use hydrogen as a library? >> > Hypothetical 3rd party plugins, I think? Unfortunately even with > -DWANT_SHARED=OFF we still end up with libhydrogen-core-1.0.1.a, which > appears to have not been installed in the 0.9.7 series of Debian > packages. I can whitelist and ignore it, but for comparison to other > distributions, OpenSUSE chose to ship the lib: > > https://software.opensuse.org/package/libhydrogen-core0 (for 0.9.7) > https://software.opensuse.org/package/libhydrogen-core1 (for 1.0.1) > > Also, I'm also not sure if there is any practical benefit to > hydrogen-dev (hypothetical plugin development), so I'm wondering if the > headers should not be installed; they weren't installed in the last > release (0.9.7-6). Hydrogen-dev_1.0.1-1_all.deb is only 84KB, so could > be merged into libhydrogen-core-1.0.1. Sebastinas says the -dev package > is arch-specific, and if that's the case it seems like merging the -dev > package into bin:libhydrogen-core-1.0.1 would be reasonable. > > There is something to be said the principle of least surprise when > moving between distributions, but I don't have a position on way or the > other. > > At this time we can also reassess the hydrogen and hydrogen-data split. > If I was packaging Hydrogen from scratch I'm not sure that I would split > them... > > Finally, if we maintain the split, what is your position on .desktop and > appdata files? Should they go in bin:hydrogen-data, or in bin:hydrogen? OK - I think we are a bit too close to the next Debian release to be making things complicated. Maintaining a library complicates upgrades to new versions if transitions are required, and can be problematic if the the ABI is not stable. I don't know how stable the hydrogen library is. Why don't we just stick to how it was structured before it was removed? That way users of Hydrogen in making music (like me) can just use the application like they used to. We have to go through the NEW queue to get hydrogen into the next release, so making the ftp-master review as simple as possible (with a rock solid copyright file) is the least risky approach. I think the main reason for splitting stuff out into a *-data package is to split the architecture dependent files from the architecture independent files. When looking at the contents of the old hydrogen package, you could question some of the decisions between the -data and -doc packages. Maybe after the release we can think about helping developers of potential plugins, and moving files around between packages? That is unless the previous structural decisions contributed to any bugs! We can always backport new versions for users of Debian stable after the release if there is a demand. > > I've reopened this list of bugs. > >> Let me know when the new version is available on mentors. >> > Will do! I'd just want to take care of the major design decisions > first. > > Cheers, > Nicholas Cheers, Ross signature.asc Description: OpenPGP digital signature
Bug#976113: Bug#954823: Sponsorship of hydrogen
Hi Ross, Ross Gammon writes: > I have spent some time going through the commit messages. There has > been a lot of work done! Yes :-) If I remember correctly, cdbs -> dh, and upstream churn between prereleases was the worst of it. >> Will you be sponsoring from git or mentors? How would you like me to >> work during the WIP cycles of the review? The git history will look a >> bit silly and confusing with too many "refinalise for release to >> unstable" commits ;-) > > I can do either. But I think in this case, I would prefer to work from > mentors (mainly because I have problems with my gbp setup on this > computer). But please also keep the git repository in sync (even if it > is on a different branch that we can merge later). > Will do! The WIP branch is called "rfs-976113-rebase" and I pushed it just now; it doesn't contain much yet. I will update mentors as soon as we have an upload candidate (still too many outstanding big issues at this time). > Actually, I would like to compliment you on your commit messages. It was > pleasing to see a verbose reason for the change, instead of some short > cryptic message that just generates more questions. > Thank you you, I appreciate that you noticed! It really helps with making sense of work from months ago that I've now forgotten the details and reasoning. And for other team members, of course. 'wish all new contributors were mentored to value this ;-) (I was) >> On #debian-multimedia, Sebastinas did a preliminary review, and two big >> issues were: >> >> 1. override_dh_auto_build had a typo! "override_override_dh_auto_build" >>* I've fixed this locally >> 2. I was missing an override_dh_auto_configure to make use of >>$DEB_CMAKE_EXTRA_FLAGS >>* I believe that is why the extra lib and dev packages became >> necessary. Now that I know what was causing the problem I can >> restore something closer to the old packaging. >>* Changing this in the future will require another trip through NEW, >> so what do you think the correct split of the package is? > > I was wondering why the library packages suddenly appeared. I think if > it is possible, it is best to stick to the old packages. What > applications would want to use hydrogen as a library? > Hypothetical 3rd party plugins, I think? Unfortunately even with -DWANT_SHARED=OFF we still end up with libhydrogen-core-1.0.1.a, which appears to have not been installed in the 0.9.7 series of Debian packages. I can whitelist and ignore it, but for comparison to other distributions, OpenSUSE chose to ship the lib: https://software.opensuse.org/package/libhydrogen-core0 (for 0.9.7) https://software.opensuse.org/package/libhydrogen-core1 (for 1.0.1) Also, I'm also not sure if there is any practical benefit to hydrogen-dev (hypothetical plugin development), so I'm wondering if the headers should not be installed; they weren't installed in the last release (0.9.7-6). Hydrogen-dev_1.0.1-1_all.deb is only 84KB, so could be merged into libhydrogen-core-1.0.1. Sebastinas says the -dev package is arch-specific, and if that's the case it seems like merging the -dev package into bin:libhydrogen-core-1.0.1 would be reasonable. There is something to be said the principle of least surprise when moving between distributions, but I don't have a position on way or the other. At this time we can also reassess the hydrogen and hydrogen-data split. If I was packaging Hydrogen from scratch I'm not sure that I would split them... Finally, if we maintain the split, what is your position on .desktop and appdata files? Should they go in bin:hydrogen-data, or in bin:hydrogen? >> I have not yet reopened any bugs. The list of -rm bugs is: >> 945042 642014 629105 870395 794042 586087 874907 347279 945042 >> [snip] > > I think the best thing is to reopen the bug and then close them in the > changelog once it is confirmed that they are closed. That way they are > closed with the right version information. The most important thing is > to ensure that bugs that are not fixed in the new version remain open. > I've reopened this list of bugs. > Let me know when the new version is available on mentors. > Will do! I'd just want to take care of the major design decisions first. Cheers, Nicholas signature.asc Description: PGP signature
Bug#954823: Sponsorship of hydrogen
Hi Nicholas, I have spent some time going through the commit messages. There has been a lot of work done! On 29/12/2020 17:29, Nicholas D Steeves wrote: > Hi Ross! > > Ross Gammon writes: > >> owner 954823 rossgam...@debian.org >> thanks >> >> Hi Nicholas, >> >> I am happy to take a look at hydrogen, and sponsor it. I have some spare >> time over the next few days. >> > Thank you, I really appreciate this! :-D Here are some notes and > questions: > > Will you be sponsoring from git or mentors? How would you like me to > work during the WIP cycles of the review? The git history will look a > bit silly and confusing with too many "refinalise for release to > unstable" commits ;-) I can do either. But I think in this case, I would prefer to work from mentors (mainly because I have problems with my gbp setup on this computer). But please also keep the git repository in sync (even if it is on a different branch that we can merge later). Actually, I would like to compliment you on your commit messages. It was pleasing to see a verbose reason for the change, instead of some short cryptic message that just generates more questions. I think it is best to keep a record of the review in the RFS bug. So I have cc'd the RFS bug (sorry - I did not spot it when I started), and we can continue the discussion there. > > On #debian-multimedia, Sebastinas did a preliminary review, and two big > issues were: > > 1. override_dh_auto_build had a typo! "override_override_dh_auto_build" >* I've fixed this locally > 2. I was missing an override_dh_auto_configure to make use of >$DEB_CMAKE_EXTRA_FLAGS >* I believe that is why the extra lib and dev packages became > necessary. Now that I know what was causing the problem I can > restore something closer to the old packaging. >* Changing this in the future will require another trip through NEW, > so what do you think the correct split of the package is? I was wondering why the library packages suddenly appeared. I think if it is possible, it is best to stick to the old packages. What applications would want to use hydrogen as a library? > 3. override_dh_auto_clean failed to run "dh_auto_clean". Oops :-/ This might explain why I found that the package failed to build twice in a row for me. > I've already make local fixes for these and other issues, but will delay > pushing until I receive your preference regarding the shared lib and dev > packages. I'm of course open to fixing other issues and removing > anything you consider vestigial to the old cdbs packaging (I chose the > more labour-intensive approach rather than clean packaging)! > >> Have you reopened any bugs that were closed when the package was removed? >> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-packages >> > I have not yet reopened any bugs. The list of -rm bugs is: > 945042 642014 629105 870395 794042 586087 874907 347279 945042 > > There seem to be differences in perspective about when/if these bugs > should be reopened. My preference is to maintain a strong link between > the changelog and BTS, for future reference, and for future > maintainers. Given "changelog closes bugs in wrong way", I feel like > reopening the bugs that will be closed by the yet-to-be-uploaded > changelog entry is the correct approach, because it creates a strong > link between the changelog and BTS. I think the best thing is to reopen the bug and then close them in the changelog once it is confirmed that they are closed. That way they are closed with the right version information. The most important thing is to ensure that bugs that are not fixed in the new version remain open. Let me know when the new version is available on mentors. Ross signature.asc Description: OpenPGP digital signature
Bug#954823: Sponsorship of hydrogen
Hi Ross! Ross Gammon writes: > owner 954823 rossgam...@debian.org > thanks > > Hi Nicholas, > > I am happy to take a look at hydrogen, and sponsor it. I have some spare > time over the next few days. > Thank you, I really appreciate this! :-D Here are some notes and questions: Will you be sponsoring from git or mentors? How would you like me to work during the WIP cycles of the review? The git history will look a bit silly and confusing with too many "refinalise for release to unstable" commits ;-) On #debian-multimedia, Sebastinas did a preliminary review, and two big issues were: 1. override_dh_auto_build had a typo! "override_override_dh_auto_build" * I've fixed this locally 2. I was missing an override_dh_auto_configure to make use of $DEB_CMAKE_EXTRA_FLAGS * I believe that is why the extra lib and dev packages became necessary. Now that I know what was causing the problem I can restore something closer to the old packaging. * Changing this in the future will require another trip through NEW, so what do you think the correct split of the package is? 3. override_dh_auto_clean failed to run "dh_auto_clean". Oops :-/ I've already make local fixes for these and other issues, but will delay pushing until I receive your preference regarding the shared lib and dev packages. I'm of course open to fixing other issues and removing anything you consider vestigial to the old cdbs packaging (I chose the more labour-intensive approach rather than clean packaging)! > Have you reopened any bugs that were closed when the package was removed? > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-packages > I have not yet reopened any bugs. The list of -rm bugs is: 945042 642014 629105 870395 794042 586087 874907 347279 945042 There seem to be differences in perspective about when/if these bugs should be reopened. My preference is to maintain a strong link between the changelog and BTS, for future reference, and for future maintainers. Given "changelog closes bugs in wrong way", I feel like reopening the bugs that will be closed by the yet-to-be-uploaded changelog entry is the correct approach, because it creates a strong link between the changelog and BTS. Best, Nicholas signature.asc Description: PGP signature
Bug#954823: Sponsorship of hydrogen
owner 954823 rossgam...@debian.org thanks Hi Nicholas, I am happy to take a look at hydrogen, and sponsor it. I have some spare time over the next few days. Have you reopened any bugs that were closed when the package was removed? https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-packages Regards, Ross signature.asc Description: OpenPGP digital signature
