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 <rossgammon@debian.org> writes: > On 30/12/2020 00:55, Nicholas D Steeves wrote: >> Ross Gammon <rossgammon@debian.org> writes: <snip> > 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
Attachment:
signature.asc
Description: PGP signature