> - do the new version in experimental so if urgent fix is needed in unstable can be done in master, when will be released to unstable a merge will be done Yeah, I saw that once I pushed to menus. I hope it doesn’t mess anything up, but I’ll make sure for the rest as I move on the work is done is in experimental.
> - missed push of upstream/<version> tag for latest cinnamon-menus > - add ~ on version can help for testing packages and can do "faster" upgrade both with other test (like ~1...~2 ecc) and upgrade when definitive package will be released, and when will be released new build on debian will be removed I don’t understand the point of this. Every team I’m apart of expects different things and has different expectations. Do I have to do this? I didn’t have to with the packages Norbert uploaded I changed. > lintian controls) that need to be tested is still correctly needed, correctly working, or to be improved but I don't have enought time - try to "fix" all lintian tags up to pedantic not always can be good, some should/must be override (if marked error or warning) or simply ignored, in some cases try to "fix" things spotted by lintian (even of things
not really necessary ) can also cause bugs/unexpected cases (and not only "waste" time). I don't > say this because you caused problems, it doesn't seem to me, but only because I have seen over the years that it is often the cause of bugs/unexpected
events (in general), I had made the same mistake too, now instead I try more to avoid change things if I don't know enough about it and/or I don't test > changes done in practice >- about build options and flags years ago there was some bugs/unexpected cases in some components (I didn't remember what), probably with meson ports are fixed/improved (I mean on software itsself and not packaging) upstream but probably if something will
be changed is better check always build logs if configure/use right (if not already done) I’ve already fixed similar issues in the past, and I haven’t seen any regressions as a part of it so I’m not concerned. Overall, @Norbert: What should I do? I understand the part with pushing to experimental, that was my bad, I forgot but about the ~ after the version and standards-version, what do you prefer? -Josh From: Fabio Fantoni Il 17/11/2021 19:06, Joshua Peisach ha scritto:
@Joshua: Thanks for your works, I saw your latest commits, only small advices: - do the new version in experimental so if urgent fix is needed in unstable can be done in master, when will be released to unstable a merge will be done - push debian/<version> should be done only when package will be uploaded to debian repo - missed push of upstream/<version> tag for latest cinnamon-menus - add ~ on version can help for testing packages and can do "faster" upgrade both with other test (like ~1...~2 ecc) and upgrade when definitive package will be released, and when will be released new build on debian will be removed - bump standard version (mainly about other components more "big") I waited because is more important do deep check with https://www.debian.org/doc/debian-policy/upgrading-checklist.html and some components have some things (not easy/fast like some common and maybe even included in lintian controls) that need to be tested is still correctly needed, correctly working, or to be improved but I don't have enought time - try to "fix" all lintian tags up to pedantic not always can be good, some should/must be override (if marked error or warning) or simply ignored, in some cases try to "fix" things spotted by lintian (even of things not really necessary ) can also cause bugs/unexpected cases (and not only "waste" time). I don't say this because you caused problems, it doesn't seem to me, but only because I have seen over the years that it is often the cause of bugs/unexpected events (in general), I had made the same mistake too, now instead I try more to avoid change things if I don't know enough about it and/or I don't test changes done in practice - about build options and flags years ago there was some bugs/unexpected cases in some components (I didn't remember what), probably with meson ports are fixed/improved (I mean on software itsself and not packaging) upstream but probably if something will
be changed is better check always build logs if configure/use right (if not already done)
|