Looks like this fork is still downstream of the 'master' github repo from ted. So this will still get upstream changes to merge? If so then that's good. I've also forked Ted's repo to work on mac and windows ports (a bit, occasionally) and not have it all gumming up the main github repo. Perhaps one day I'll get something working which can be PR'd back to 'main' but then perhaps not..
While any project would rather not see forks, it's also a sign of health in some ways. I would prefer if we could 'all work together' of course but I also get that if PRs are floating about and don't get merged or rejected or even considered then it gets frustrating pretty quickly! So I can see both sides and, for one, would like to congratulate all of those who still do the good work on Rosegarden. Very proud that it still continues to thrive. Best, Richard On Mon, 28 Nov 2022 at 08:12, MST <babar...@gmx.at> wrote: > Hi there! > > Just out of curiosity, why doesn't here any discussion or reaction take > place. Apparently mark got frustrated being given no feedback on his > contributions. Can anybody enlighten me please? > > Greetings, > Michael > > > *Gesendet:* Mittwoch, 16. November 2022 um 10:31 Uhr > *Von:* "mark_at_yahoo via Rosegarden-devel" < > rosegarden-devel@lists.sourceforge.net> > *An:* rosegarden-devel@lists.sourceforge.net > *Betreff:* [Rosegarden-devel] So long and thanks for all the FOSS > This post is intended as a courtesy notification to any who may be > interested. If not or nobody, I apologize for the waste of time and > bandwidth. > > I have released an independent fork of Rosegarden at > https://github.com/thanks4opensource/rosegarden-fork/. This is compliant > with Rosegarden's license ("COPYING"). > > Note that forking the project was not my first (or Nth) preference. I > believe that forks are in general bad for open source software as they > increase the FUD factor put forth by proprietary/closed-source vendors. > ("You use Rosegarden? Which version? See, that's why you don't want to > get locked into open source software!") > > The fork is also bad for me personally. When I first considered working > on the Rosegarden sources I was elated to find that the project was > actively being maintained and developed. (Also surprised, given the > prevalence of open source "abandonware", and then even more so when I > learned how far back Rosegarden's history goes.) My hope, and frankly > expectation, was that my contributions -- initially small, but which > grew in size and scope -- would be incorporated into the codebase, > hopefully with collaborative back-and-forth improvements. And that > eventually, as the release schedule progressed and distributions picked > up the latest version, I could delete my own development branches and > simply use distro binaries. > > But it has become increasingly clear that my merge requests aren't going > to be accepted into the Rosegarden mainstream, at least not in any > timely fashion and probably not ever. I have invested far too much time > and effort (currently 20x my original estimate) (and Rosegarden is very > much a sideline to my main open source work) to relegate it solely to my > own private use. I believe the fixes and new features I've added > represent worthwhile improvements that others could benefit from. Time > may or may not tell. > > On an even more personal note, in retrospect I regret having chosen this > development path. I had thought I could "hack in" two minor changes: The > one bug and one feature I originally posted about, i.e. MIDI input > playing the current editor's active segment's instrument, and key-aware > matrix editor highlighting. But at each step in a long chain of > development I ran into further missing features that I needed for my own > Rosegarden use, and even more so internal architectural failings and > omissions that made implementing anything far more difficult than it > should have been. > > I also realized in retrospect that I could have implemented a > matrix-editor-only application from scratch in far less time. As I once > posted to a bug report, I had previously written a primitive non-GUI > application with the basic algorithms and an ALSA MIDI back end. I > wouldn't have ended up with the myriad of other capabilities Rosegarden > provides, including the much more difficult to implement notation > editor, but as I personally only use notation for communicating with > tradition-bound friends, and could have always exported MIDI to > Rosegarden (or Musescore) for producing offline output, that wouldn't > have presented an insurmountable problem. "Live and learn", as the > saying goes. Or maybe more appropriately given Rosegarden's original > developers, "In for a penny, in for a pound". > > I hope this explains my motivations for forking Rosegarden (again, if > anyone is interested in them). As of now the fork still isolates its new > code in the separate thanks4opensrc_devel branch (with the exception of > a modified README.md file in master that clearly indicates the repo is a > non-official fork) although that may change in the future. I have one > more major feature planned, plus a raft of smaller ones, but currently > hope to slow my development on the project in order to return to the > other work mentioned above. I'm describing the branch structure on the > off-chance that there's any future interest in looking at parts of the > fork for potential inclusion in the official repository, either as code > or merely as ideas for independent/separate implementation. But note > that the branches have already diverged significantly (my last merge > with master [833ea5] was very difficult) and will likely continue to do > so. Of course my recommendation is that the forked branch be merged > wholly, as-is (git-merge "theirs), but I don't anticipate that happening. > ;) > > Finally, and as publicly stated in the fork's README.md, please accept > my appreciation for Rosegarden and acknowledgement of the man-decades of > work that have gone into it. As much as I think there are significant > architectural issues (not surprising considering the long development > history) and that a deep refactoring/re-implementation (far beyond the > recent "lint"/const-correctness merges, as valid as those are) should be > undertaken (not something I'm likely to undertake on my own) I still > believe the basic code design is sound and that the program's features > and workflows are exceptional. My best wishes for the future of > Rosegarden, in any and all of its forms. > > -- > MARK aka "thanks4opensrc" > > > _______________________________________________ > Rosegarden-devel mailing list > Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel > _______________________________________________ > Rosegarden-devel mailing list > Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
_______________________________________________ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
