Changing to pull request model

[elieserdejesus]

@teamikl , @Ezeer , @jonjamcam, I'm changing this repository to "pull request only". If you have new contributions please create a pull request and we can discuss before integrate the contribution.

[Ezeer]

good . My next contribution could be on MidiControl :

console output :

Starting E:\JTBSTATIC\JomTobo\build-Jamtaba-Qt5-Release\Standalone\release\Jomtobo.exe... jt.Configurator.INFO: Reading settings from "C:/Documents and Settings/Salon/Local Settings/Application Data/Jomtobo!/Jamtaba.json" default.INFO: MidiController is online ! jt.Midi.INFO: Initializing rtmidi... jt.Midi.DEBUG: MIDI DEVICES FOUND idx: 2 in 0 jt.Midi.INFO: rtmidi initialized! jt.Midi.INFO: Starting MIDI in "Périphérique audio USB 0" jt.Midi.INFO: Starting MIDI in "Périphérique audio USB (2) 1" default.INFO: "Starting Jamtaba 1.0.0 Standalone (i386) running on Windows XP (i386)" jt.Midi.INFO: addChannelMap received : TRACKID= 1 Channel= 1 jt.Midi.INFO: addChannelMap received : TRACKID= 2 Channel= 7 E:\JTBSTATIC\JomTobo\build-Jamtaba-Qt5-Release\Standalone\release\Jomtobo.exe exited with code 0

but still a lot of work to do ...

[teamikl]

@elieserdejesus Ok, and you can write that contribution guideline to CONTRIBUTING doc. that where new comers who wants to contribute read first. if project had local rules, they should be documented.

About Pull Request model, there are two models "Fork and Pull" and "Shared" that differences are where make branch repo and collaborative or not. which your select or both?

• GitHub Guides
  • Understanding the GitHub Flow PR models
  • Contributing to Open Source on GitHub CONTRIBUTING file.

Other missing stuffs are the license, coding style, unit tests...

[elieserdejesus]

I added a Coding Style section in the github readme file. After the release v2.0.10 (in some days) I will run a huge code format task in the project. This will generate a big change in the repository because every file will be changed/formatted by the Beautifier plugin.

[teamikl]

GitHub prefers CONTRIBUTING (or CONTRIBUTING.md) file for such project policy. github will link to the file where let contributors to read.

• Contributing to Open Source on GitHub The Docs - contributing section
• contributing guidelines

[elieserdejesus]

Interesting Tea, I will create this contributing file soon.

[teamikl]

@elieserdejesus

How many refactoring tasks do you have ? I have a suggestion for the PR based work flow.

1. make a topic branch (short-lived branch) and open WIP Pull Request
   • owner also do it, to avoid the situation commit to master directly often
     • the commit was not reviewed, then master may be easily unstable.
   • even no reviewers then self review
2. write down task list to do in the PR topic comment
3. iteration
   • test and commit
   • push local work to remote branch (others can see what you working and can review early)
   • review
4. simplify commit history (optional .. if you want a clean commit history)
   • NOTE: have to learn git rebase -i
5. merge

current working model (no public regression tests and commit to master often directly) easy to make conflict situation. that made unnecessary tasks and contribution harder. if it was commit to a branch then can avoid by control merge timing.

[elieserdejesus]

@teamikl How many refactoring tasks do you have ? I'm finishing the refactoring in Standalone. I do some improvements in the OOP design (very time consuming task) and another minor refactoring like renaming, moving code, separate classes in different files. I need work to fix the VstPlugin refactoring issues too. I change the design in some places, so a lot of things are broked, but the result is better. Trust me, I would not waste my time if not to improve this code.

This work flow proposal is very good, but let's adopt this ONLY after the house is cleaned enough :)

[teamikl]

after the house is cleaned enough

ya, no problem. take your time

---

about topic branch

• https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows

I proposed WIP Pull Request, but "WIP" was an option for GitHub flow

When you need feedback or help, or you think the branch is ready for merging, open a pull request

[teamikl]

Branch naming convention can be next topic.

• descriptive name for the topic branch
• manage outdated branches because you will see a lot branches. so remove the branch after merged the pull request or git branch -l (branch list) became a large

Info about Git/GitHub work flow About the naming conventions, there are several types. notations/branch types/release type etc ...

• Git work flow had some naming convention rules, using prefix like feature/ release/ hotfix/ etc they are strict for release-based project management. which need to maintenance old versions
• GitHub work flow does not. so naming is a free (it's only important repo is 'master') its fit for web service, software which update often (like chrome, JamTaba1 was also this type)

---

This is a quick research result

http://www.guyroutledge.co.uk/blog/git-branch-naming-conventions/

I could not find standard naming convention for GitHub work flow specific. on the bottom of page, those prefix are the most common I see in other projects.

using the slash notation for struct idea is looks good if starting new clean repository. in real project, Qt core repo use wip/ prefix for work in progress repository.

GitHub work flow is more a light weight, no need strict rules for struct branch, flat struct dashed notation with simple branch type prefix is enough.

[elieserdejesus]

Tea, I like this: GitHub work flow is more a light weight, no need strict rules for struct branch I prefer avoid excessive rules. If a name is clear it's nice, no worries. If is not clear we can propose a change. Maybe I need clarify why I'm thinking in this way. Look at Wahjam repository and other ninjam related repositories. How many years? How many contributions? What you conclude? My opinion: this is a little project. The ninjam community is small, just a small group of this small comunity are interested in write contributions for open source project. Just a small number of these people are specifically interested in Jamtaba project. So, I'm not expecting tons of pull requests, and, just to be clear, it's not a problem for me. I'm shure we don't need rules for everything, this project is not big enough to justify a lot of rules. Let's keep some "head room" for jazzy decisions, let's do some improvisation in Pull Requests and branches names :)

[elieserdejesus]

@Ezeer and @teamikl , I finally finish the big refatoration of my life :) The main changes are:

1- Things are well separated between Standalone and VstPlugin. No more checkings "isRunninsAsPlugin()" or similar.

2- If you need something specific for Standalone check MainControllerStandalone and MainWindowStandalone. These are derived classes from MainController and MainWindow. Other derived classes are MainControllerVST and MainWindowVST. Off course the base classes contain JUST the common code. This was not the case in the old code structure. Now the class members pluginFinder, audioDriver, midiDriver, etc are in MainControllerStandalone only. I move this code (and all related signals/slots).

3 - I'm using a lot of polimorphism to create the right classes. The MainWindowStandalone class create instances of LocalTrackGroupStandalone, and this class creates instances of LocalTrackViewStandalone. The same thing in plugin is: The MainWindowVST class create instances of LocalTrackGroupVST, and this class creates instances of LocalTrackViewVST. I'm using the design pattern factory method. An example: In the LocalInputTrackView old code we are creating the widgets related with VST plugins. But vst plugins are a Standalone only feature. So, in VST plugin we are hidding this widgets. In the new design the plugin specific widgets are created only in the plugin classes, no more "hidding" non used widgets. Another example: in the old design the shortcuts are added directly in QtCreator GUI editor. But shortcuts are a Standalone only feature. Now the shortcuts are added (in the code) only in the MainWindowStandalone class.

4 - The files are renamed and moved. Now all the sources are inside "src".

I don't finish all refactoring job, I do just the "BIG" ones. I add comments for the minor "smells" in the code, we can work this in another moment.

I know these last changes in the repository was very drastic and I'm sorry if cause problems. Let me clarify why I decide start this crazy mission called "refactoring all the shit": we are not receiving money, so we need another forms of reward. Enjoyment and leaning come in my mind. The old code structure began to be a maintence nightmare and I was not enjoying anymore. Now the code AND the design is better, is not a nightmare. Actually now is very easy add specific features to Vst plugin or to Standalone. Now I can enjoy again, I hope you too.

Thanks for your contributions in 2015, and have a very happy new year!!

[jonjamcam]

@elieserdejesus @Ezeer @teamikl Happy new year to all too!

[elieserdejesus]

Hey @jonjamcam , I forgot to include you in the last post, sorry for this man, really sorry, my bad! A happy new year for you!

[jonjamcam]

lol No problem,

no need to apologize->bool (I'm not a coder) if (I'm not a coder) { qdebug ("But I do follow what's going on.....") }

:D

[teamikl]

Happy new year all

@elieserdejesus Cheers for those works those refactoring are very welcome. and thanks for the summary. it's many changes I did not follow all commits.

I prefer avoid excessive rules. If a name is clear it's nice, no worries. If is not clear we can propose a change.

my opinion is avoid project local rules (as possible), undocumented things are unclear for others. (of cos there is an exception for project specific situations)

I feel "rule" make a strict impression, here. the "rules" is like a "theory" in music term? then how about "guideline"

I agree the basic stance of your "avoid excessive rules, and we can propose a change". lower border for contributors, their interest are feature, not such project serviceability usually.

need to document is about the details: explicit what is "not clear" and "how change" they will need a guideline.(or you may need to explain same thing every time)

about ninjam community I know, there are many engineer/developers in the small NINJAM community.

I have an idea for make a project Enjoyable platform. My view point is an "Extendability" for this, can learn from success projects. Program which has a lot contributors are designed to be so, easy to make extensions for contributors.

@jonjamcam , did you have the development environment? there is an important role "Tester" if you could build JamTaba from source code. you can try new feature early and feedback before release would make application more stable.

I'm recently interest in Quality Assurance topics, it's my personal study. some functional tests are program can do, but usability need test by human. in other issue thread I proposed research deploy nightly development build for testers.

[jonjamcam]

Hi @teamikl .

did you have the development environment?

yes I do. @Ezeer helped me install qt and now I can build Jamtaba from source. I've been following the developments because I'm interested in understanding the code and what it does. I'm kind of student of c++ and qt and It's really fun to be able to see how well constructed it is. From my perspective, Jamtaba looks like a very complex machine, like a little swiss clock.

there is an important role "Tester" if you could build JamTaba from source code

I'll be glad to do beta testing before release, but my system only compiles the standalone win32 so my capability is limited. I've been testing the new features recently cloning the repository a couple of times and it's working fine.

Cheers!