On 2022-11-29 07:33:53 Richard Bown wrote:
> So this will still get upstream changes to merge?
Yes, it's my intention to merge upstream commits from master as time and
motivation permit. (See the "no warranty" disclaimers in the "COPYING"
license file.) Or at least until the code divergence makes doing so
impossible. And of course I won't be merging any conflicting
designs/implementations of the same feature (e.g. looping).
Right now I'm waiting to see how 22.12 shakes out, as the MIDI file
merge patches seem to address longstanding, non-critical issues.
On 2022-11-30 03:54:14 Ted Felix wrote:
> I'm planning on having a look in January after the 22.12 release
> and the holidays. It's 21,000 lines of changes, though, so it's
> going to take years for me to review and test all of it. Until that
> process begins, I can't provide useful or helpful feedback.
Thanks, Ted. If and whenever you get to it, I'd be very interested in
your feedback, regardless whether you merge any of the code or not.
As I've said many time before, I completely respect that Rosegarden is
yours to steer in whatever direction you see fit. Just for the record, I
will note that I didn't dump 21K+ lines of code on you all at once --
that figure represents the cumulative count of pending merge requests
I've been submitting since March of this year
(https://sourceforge.net/p/rosegarden/git/merge-requests/). And as for
"years ... to review and test", that's all the more reason for the fork
to exist as an alternate/experimental release. Maybe if it gets some use
and testing (and fixes!) that will aid your eventual review of it.
On 2022-11-30 12:09:32 Philip Leishman wrote:
> That sound good. But 21k lines makes things difficult.
> ...
> It seems that Mark put all his changes in one branch. I think this is
> part of the problem. As an example see feature request 508 for the
> marker ruler - I think these are valuable changes which should be
> merged into rosegarden but the feature is combined with a lot of
> code in the matrix editor which may (or may not) be good!
Two points: First, the branch's history and the merge requests are
somewhat linear, although not completely so (fixes/changes to earlier
commits appear in later ones). So it would be at least theoretically
possible to review and merge them one at a time without tackling the
entire 21K LOC at once. Note also that the branch's commit messages
contain very complete documentation about what is included in each one.
Second, Ted -- if not actually encouraging me -- seemed to be OK with
the single/cumulative branch:
On 2022-04-07 12:52:07 Ted Felix wrote:
> And that's fine. Since you are working this way, you should
> probably drop the multiple branches and merge requests and just
> work in a "mark" branch. I can follow along with that and bring
> it over into the official rosegarden repo to make it easier
> for everyone to test as well.
> The bug/feature request numbers in the commit messages tell
> the whole story. A single branch seems like it's more your style, so
> that should be more productive for you. It's up to you. I can
> handle whatever is thrown at me git-wise.
(https://sourceforge.net/p/rosegarden/mailman/message/37636847/)
Maybe he's changed his mind. Possibly because he didn't anticipate me
taking things this far. ;)
Regardless, I can't break out the individual features/merges into
independent, standalone commits. For a long time I tried to make as few
changes to the codebase (my original plan was to touch nothing outside
of the src/gui/matrix/editor directory) as I could while implementing
the features. Eventually that became impossible -- there's just too much
in the core code that needs refactoring/redesign (I'm being critical,
sorry) for which I've made minor/incremental fixes. Each new commit
built on the previous one(s) because creating (and testing) an MxN
matrix of commits -- features rows vs internal utilities columns -- was
out of the question. Again, my expectation was that each merge request
would be evaluated/accepted/rejected/modified before the next one, which
in turn would factor in the outcome of the previous.
On 2022-11-30 12:09:32 Philip Leishman wrote:
> Rosegarden has a large user base so taking in new code is always
> difficult - checking that the user is not going to get surprised by
> something.
This post is getting too long (as is usual with me) and I'm now going
slightly off-topic, but I dispute both points. First, the "large user
base" (my criterion is serious users, those who spend multiple hours per
week using the software), but more importantly that a large percentage
if not the majority of them will always categorically reject any changes
whatsoever to the UI or the workflows, regardless if those changes are
improvements.
I'm willing to defend these statements to anyone who's interested, but
since that's probably nobody and it doesn't matter anyway -- there's
"real" Rosegarden and my fork, it's all good -- I'll stop here. I have a
commit with a very minor new GUI element (and, yes, there's no
preference to disable it) and a few tweaks to one of the existing new
features to push to my repos.
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
