(warning, bit of rambling, plus I was interruped multiple times while
writing this and not fully awake yet either)
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.
>Would it be useful to start a Musescore team to divide the workload,
Unclear, probably not.
I’ve got somewhat concrete plans. The situation with MuseScore 3 is
as follows:
• we currently have 3.2.3 in Debian, which is suitable for almost all
workflows 3.6.2 (the current upstream release) is, with the notable
exceptions being playable chord symbols and the new Leland font (we
*do* have the new MScore font)
• our 3.2.3 is fully compatible with mu͒.com
• I personally have issues with the 3.3+ regressions as stated above
• upstream’s 3.6.2 is the last 3.x release they want to publish, they
are politically interested in mu͒4 being the next release, but that’s
nowhere near ready yet
‣ if a 4.x is released, we’ll have to keep 3.x anyway, for old scores,
just like we need to keep 2.x around
• upstream’s 3.6.2 is also fully compatible with mu͒.com, other than
some changes to mu͒.com’s backend code that sometimes also affect 3.2.3
• 3.6.2 is a rather old (2021-02-08) and *also* buggy release
• 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
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.
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.
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…
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 :~
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?). 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
• 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
• … 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.
