Hi Thorsten, Sorry for the extremely belated reply. I did read your reply soon after you sent it :)
Thorsten Glaser <[email protected]> writes: > (warning, bit of rambling, plus I was interruped multiple times while > writing this and not fully awake yet either) > No worries, and I appreciate your detailed explanation! > Nicholas D Steeves dixit: > >>In an earlier update you mentioned that there were numerous regressions >>and problems with these new releases. Are these limited to non-dfsg > > No, they are core UX, such as note input mode. > Oh, wow, yeah, that sounds like this would need a lot of work. [snip rationale for sticking with 3.2.3] > • 3.6.2 is a rather old (2021-02-08) and *also* buggy release > Oh my. > • there’s a community 3.7 effort that’s already got no less than 323 > commits with bugfixes relative to 3.6.2 > ‣ this is what I’d probably work on if not for… > ‣ this is completely unsupported on mu͒.com *and* by upstream formally > ‣ it has no releases, only git snapshots, with occasional rebases, > and occasionally introduces regressions on itself > Ah, now I see what you mean about 4.x being upstream focus. > At this point in time, I believe that keeping the 3.2.3 we have and > backporting bugfixes to that, in the musescore3 package, and packaging > musescore4 once it’s out, is (given effort/gain) the best thing to do. > Agreed! > You *can* help in identifying commits that have gone into 3.3+ that > correct issues, I’m aware of at least the frame vs. pagebreak one. > However, we *cannot* backport some changes because they alter the > file format and the mu͒.com (and 3.3+) importers will see it’s a 3.2 > file and therefore expect certain issues to be present. I’m aware > there’s at least one change we cannot do. > If I run into a bug then I'll dig for new commits. > Note that our 3.2 package already has about a hundred backported > fixes already, too… and also note that 3.3+ use QML much more, which > involves qtweb* stuff more… > Wow, that's amazing. Thank you again for your work :) > We *can* package *either* 3.6.2 *or* the 3.7 community effort, but > almost certainly(?) not both, in addition to the aforementioned plan. > However: > • until the UX regressions are addressed (and we’re sure that there > are no other regressions against the very stable 3.2 codebase we > currently use), I’d prefer this to not replace the 3.2 package > ‣ we do have musescore-snapshot, which we can use, even with sid > ⇒ this name would fit the 3.7 community effort better ☻ > • ftpmasters might eventually protest the addition of even more > musescoreXXX packages; we have justifyable reason for at least > musescore{2,3,4} and probably -snapshot > • losing mu͒.com support is certainly a disservice to users, but so > is updating to a >1-year-old known-buggy version :~ > Agreed, it sounds like we'd be worse off with 3.6.2 or 3.7 at this time. > We could, on the other hand, package git master (“to be 4.x”) now > already, to get a feeling for it. I’d treat it as almost completely > new packaging project; certainly for d/copyright at least (much of > the old code was removed, almost all of it was moved path‑ and file‐ > name-wise, and all was reindented). We could do it as m-snapshot in > experimental, or even as musescore4, going through ftpmaster review > for it (but maybe not this early yet?). Agreed, from what you're saying it sounds like it's still too early. > Things to watch out: > • qtweb* stuff (not portable to all architectures, disable) > ‣ also: phones home, e.g. I disabled the Start Centre in 3.x > because it loads from yandex.ru and lately also Google Analytics Oh my... > • phoning home in general (update checker, etc.) > • parts of the playback functionality is now a “freeware” binary > add-on plugin only available from their in-program download store Wow, that plugin doesn't sound very nice... I wonder why it can't be released under a dfsg-compatible license? > • … maybe more > > If you have interest in *that*, it might be more long-term beneficial. > They just (end of March 2022) released the first alpha of it. And I’ll > be available for help and review, too, of course. My current focus is > on backporting fixes to our known-good 3.2.3 version, though. > > Hmm. I seem to have lost my mental thread here. Eh, anyway, written > a lot already — tell me what you think. This is a perfect conclusion. Thank you very much for taking the time to explain all of the outstanding issues, and once again I'm sorry for taking so long to reply. Yes, I completely agree; This sounds like a case where the Debian model of a stable base plus backported fixes results in a more reliable tool than running the latest available release. Also, it sounds like it will be best to wait for the future-4.x series' first beta before starting to work on a musecore4 package. Would you please consider keeping this bug open in case other people wonder why things are the way they are with Musescore in Debian? Regards, Nicholas
signature.asc
Description: PGP signature
