How to collaborate?

[keinstein]

At first I'd like to suggest to enable issues in CtrlrX, so that it is possible to discuss any problems that arise.

In general I don't understand exactly how you want to organise development.

Do you want to provide documentation in CrtrX and keep the development in RomanKubiak/Ctrlr? Then you should follow that rule and keep development and documentation in separated branches.

Do you want to provide a testbed for the next major release of Ctrlr? Then it should be communicated clearly.

Do you want to provide a testbed to integrate all efforts while Roman is busy with other things? Also this should be communicated clearly.

I think the latter two points do not satisfy the renaming to CtrlrX. It is even worse that it looks like you want to fork the project.

At last: you can take the pull request serious if you want. I'd like to discuss this issue in the issue forum. And I'm willing to merge my branch into whatever is feasible, whenever it helps to join development, testing and usage.

[damiensellier]

Hi Tobias, thanks for your comments, they are really relevant and we really need to think about a way to work all together for the best outcome. At first I was thinking about only publishing code snippets, wiki and documentation links on this repository, and nothing else, since it's impossible to do so on the Ctrlr github. Then I started working on my fork as anyone would do, to fix bugs and improve the official Ctrlr version. I did not publish any "official announcement" on the Ctrlr discussion about this Fork for some reason, I am still thinking about how I can do my best not to "compete" with Roman's Ctrlr repo. So, for the moment, I encourage anyone from the ctrlr board to post some wiki articles, that are very welcome. For the developement part, since I never pulled requests to Ctrlr I am not aware about the limitations you probably met already since you are a very commited developer for this software.

What would you suggest Tobias? What's your insight and what would be the most efficient way to combine everybody's work to make Ctrlr really go ahead?

Thanks Damien

PS: I just enabled "issues" and "discussions".

[keinstein]

Currently, I see 4 big branches which can have subbranches:

1. Documentation about CtrlrX
2. Your private development branch(es) (maybe it would be better to have a repository named Crtlr for that).
3. Features provided for the next major release (e.g. patches that add new properties or change their systax or samantics).
4. Bugfixes and improvements that are bidirectionally backward compatible on the panel file level. This includes changed default values that are always stored in the panel files, as long as they don't introduce new options.

I'm undecided regarding your shading patch: Does it activate a feature which has been in the panel files for a long time and did not work so far (option 4)? Or did you inroduce a new option to make it possible (option 3)?

Actually, when I make pull requests, I want to have them collected and used by as many people as possible.

For me it is important that the fixes get accepted by the broad audience as soon as possible, because I don't have time for real development. It seems to me that I'm using some tools that have not been applied in a broad range so far:

1. I'm trained to constantly question myself. And I've learned that it may be impossible to find certain bugs when you got used to the workarounds. So they should be reported and solved as long as they are fresh.
2. I'm doing normal work in the debugger. The easy way to get debug information is to build the binary in Debug mode. So I get many quick responses about inconsistencies. They are annoying, so they force you to find a way to fix them.
3. I'm using a memory debugger. Memory corruption is often the reason for occasional crashes. Unfortunately the crash appears a long time after the error has been made. A memory debugger can detect many false accesses and crash the program immediately. So it is a lot easier to spot the error in the source code.

Except the build system changes my fixes affect all architectures. I think you would benefit from them, too. And testing them on Apple systems probably help Roman to accept the patches. Maybe I will set up nigthtly builds with github actions. Maybe I will set up some workflow to use some kind of vulnerability check or source code analysis.

[damiensellier]

@keinstein thanks, that's excellent ideas. I'll work on my own bug fixes and improvement on another branch. It makes sense, you are right! Let's make this fork an agregation of 100% working updates from the different Ctrlr forks, like if we could easily do it on the Ctrlr repo'. This will allow to release updates of Ctrlr on a regular basis prior pulling them to Romans' Ctrlr. This way CtrlrX could be a good place to work as a testbed before requesting a major pull to the Original Ctrlr repository.

In this optic, we will first merge your pull request to this branch. I need to check exactly what you did, because I remember that none of the pre-release (5.6 and 5.6.0) worked on mac (midi drivers failed to open). Are your updates based on the current Ctrlr master 5.5.9 f452347 Do you want me to allow automatic pull requests?

But first we have to think about a solid unified version pattern. I propose renaming the .projucer project to CtrlrX (to build CtrlrX apps, vsts etc to coexist with the Original Ctrlr) and start with version 0.9.0, (the current master on the CtrlrX) Your patches would be 0.9.1 and so on.

What do you think about that?

Thanks Tobias, have a nice day.

Damien

[keinstein]

I'm working against the master branch of Ctrlr.

I'd suggest to add a branch upstream+fixes and a branch upstream+new_features to make clear what is meant. Regarding the versioning: we should keep it in sync with Ctrlr

The scheme for the upstream+fixes branch would be (Ctrlr version)+(Commit date)-(commit hash) e.g. 5.6.0+20220129-a2e52a6 for the nightlies. For the new feature version nightlies I'd use (Ctrlr version)+X-(Commit date)-(commit hash) When you want to make special releases we replace (Commit date)-(commit hash) by that number, starting with 0.1 or simply 1, e.g. 5.6.0+X-0.1 or 5.6.0+X-1.

I think we should use a continuous delivery mode. Version based delivery only makes sense when you want to provide support for older versions, which means that you must archive them, keep build old build systems, binaries and debug symbols, and manage all that stuff. I have no time to do that. I can't do that for the software that I managed so far and certainly not for the new software.

We can also setup github actions so that they archive the release whenever you create a tag. Nightlies will be built as a moving release.

[damiensellier]

Hi Tobias, So, I added 2 branches : upstream+fixes upstream+new_features

The upstream is Roman's Ctrlr Master

Now I have 4 branches on my repo : Master CtrlX upstream+fixes upstream+new_features

My previous fixes were in the Master so, how do I merge those fixes definitely to "upstream+fixes"? I also want to merge your pull requests on this "upstream+fixes" but don't know how to do that, it's very confusing?

Another question, when I select the branch "upstream+fixes" (coming from Roman's Master), the Github app popup messages says:

Switch Branch You have changes in this branch. What would you like to do with them?

1. Leave my changes on Master
2. Bring my changes to upstream+fixes

What changes they are talking about? The one from my Master? But if I click "Bring my changes to upstream+fixes, they don't follow, and the history is stuck to Roman's latest update.

At first I wanted to do something easy, but the technicalities of Github is holding me down to be honnest.

Have a nice weekend Damien

[keinstein]

Now you are confusing me: Are you using some desktop app? On GitHub these branches are not visible. When you push the upstream+fixes branch (without any additional commits) it should appear and I can create a pull request against it. It should be easy to accept it.

Regarding stashing changes and so on: When you switch branches and you have locally edited files they are not registered anywhere in git. That's why the app complains. Now you have several options: Create a temporary commit in the git repository. This is called stash changes. A stash is never pushed to an upstream branch. This has the benefit that you still have your edits, but you can work with cleanly checked out branch. The next option would be to delete all changes. Obviously the app didn't offer this option as it is dangerous. It could kill hours of hard work. The next option would be to handle changes in the same way a merge or a rebase is handled except hat it is not registered. All changes are applied to your local files and your edits occur as edits on top of the new branch. A fourth option is to switch the branch only for git and don't touch the local files. This option is not offered. It may be very confusing when your actual state and the state git assumes differ too much. This could easily lead to all kinds of misunderstandings.

Now, once you have accepted my linux build branch, you could cherry-pick your fixes into the upstream+fixes branch. Or – even better – rebase your master branch on my fix-linux... branch. Then you could do an interactive rebase on the freshly pulled upstream+fixes branch. During this interactive rebase you can resort your commits: The two-way compatible changes should be the first ones. Then you can create a branch on the last two-way compatible commit, merge that branch, and delete it afterwards. And – don't forget to push your changes upstream.

Now I used the git vocabulary. I'm not shure that this wording is still valid in the GitHub desktop app.

I have never used it, but maybe I should give it a try.

[keinstein]

I modified the pull request to be based on upstream+fixes. Now you can merge it (please don't squash the commits).

You can choose freely by clicking on the triangle: rebase and merge or merge normally. It's whether you want a linear history or see how development moved on.

[keinstein]

Ah I forgot: I installed GitHub desktop yesterday. There is a tab named “History” (it is tagged as new, so maybe you have to upgrade the app). In the history you see all commits that belong to a branch (not as nicely organised as in gitk --all or any other tool that can show branches and merges as line segments). You can right click on a commit and select cherry-pick if you want to copy the changes of this single commit to another branch.

[damiensellier]

Hi Tobias, thanks for all the explanations. It's very clear to me now I also watched a youtube tutorial about the different procedures for the git administration. Now we have 3 branches at our disposal, upstream+fixes and upstream+new_features are testbeds before commiting to an approved release in the master branch. I checked how to give you credentials to manage the repo but it's only for organisations and enterprise accounts. Thanks for everything!