Git guidelines needed

#1

Hello,
yesterday I've started to get my hands dirty on UI development.
I have a few questions about how people contribute to the project so any advices is very welcome.

I gave me the smallest task possible: making the ObjectSearchFrame resizable (on linux there is a toolbar while on mac is not resizable).

So I pulled the master branch and modified it.
Where do you push your updates and who is checking new commits?
Is there also a list of tasks that need to be completed so I can choose one instead of figuring out what to do?

Thanks,
Daniele

#2

that sounds great :slight_smile:

the guidelines are much the same for any open source project.

before you start making changes, its advisable to contact the main developer (@johannes) , and 'discuss' what you plan/want to do... the reason are simple:
- they can tell you if someone is already work on it
- they can tell you what branch to work on
- they can tell you if there are plans already in this area, and what they might be, and if they might conflict
- they might be able to offer advice on how to implement the change, or possible consequences.

(obviously, some of this can be shortcut, to fix simple bugs... but even then its still often worth a quick PM to check)

in this particular case, you would be best doing any change on the 'experimental' branch, this is where all new development is being done... and its highly unlikely there will be a 1.0.13 based off master, as this development is pretty far along now.

the process for contributing changes is pretty simple:
- fork the axoloti repo
- make your changes on the correct branch
- create a pull request

note:before you issue the pull request, make sure you merge in the latest version from the branch you are working on, and

resolve any conflicts that may occur (and obviously test it thoroughly)

once you do this, either @johannes or I will review the pull request (PR) , and if it looks good we will merge it.
if there are improvements, or it conflicts in some way with proposed changes, then we will comment on the pull request.
(assuming its been discussed in advanced, then this should be a formality really)

there is an issue list on GitHub, though I'm not sure it covers everything esp. at this stage of development (on experimental) , but there is lots to do :slight_smile:

there has been huge number of changes on the experimental branch, so there are a few things missing to reach feature parity with 1.0.12, and also bugs etc to be squashed - this is the current priority , to get it into a release state.

probably a good way to get into it, is checkout the experimental branch, and start using it... finding bugs, and either reporting (in issues) and fixing them if possible. (its much too early for user testing, but a good time for developers to test/resolve) ... you could also look into resizing the obj frame if you wish on that branch too.

hope that is kind of clear... its not as formalised as perhaps it might be, but when its only a couple of developers, its best to do these things through clear communication, rather than procedures
(sure it doesn't scale to teams of 10's of developers, but we are a long way away from that :wink: )

#3

IMO ideally on GH issues, so it's not a 1-to-1 discussion and others can follow the discussion.

This could also be done using the GH Projects feature, meaning that the Github site becomes a single source of truth for development efforts. Which might imply some changes in ways of working from whatever the current is.

#4

sure if/when we have more active developers this would make sense.

#5

@lodevalm

Great to see more developer involvement on the patcher. I'm pretty familiar with the codebase, but will of course defer to Mark and Johannes for final decisions about mergability, roadmap, etc. Feel free to ping me if you have any specific code questions or need someone to take a look at proposed changes.

Your idea about an Electron-based UI is intriguing. Electron is a little heavy for my taste, but really I love the idea of having a low-level API that is independent of all UIs such that new and interesting UIs can be rapidly developed. As much as I find HTML/CSS/JS painful, it is probably a more inclusive technology than Java/Swing/etc in the sense that more people can contribute more rapidly. For example, I think Supercollider does this all pretty well having clean separation between the DSP server and the client language / UI processes; it seems to be very straightforward to generate language bindings and UIs that talk OSC to the sound server.

Best,
Nicolas

#6

thanks @thetechnobear for putting me on the right path.
I forked the project and checkout experimental branch (I've noticed that subpatches don't need to update manually anymore, pretty cool!)
(in the future, I will need some assistance to understand how pushes and merges work on a forked project against the main one, I've never forked a project before)

I'm becoming familiar with the code and Netbeans, I need some time because last project written in java I was involved was 5 years ago.
Then I've developed a couple of small android apps but it is a very different workflow.
Right now I'm a full-stack developer on a large web project on node/angular so I know pretty well the javascript pains and the lack of a decent editor (while atom is pretty good, netbeans and eclipse are uncomparable).

@urklang yes, I have some questions, not so specific right now but even if the code is very readable I need to understand better where things are and an overview of the packages will be more than welcome.

thanks,
Daniele

#7

Veering nicely off topic here... :slight_smile:

On github, the gist of it becomes that you update your own repository by default, and once you have a meaningful change to contribute you make a pull request from your own repository interface to update the one you have forked from. This pull request flow is not built into git (the tool) itself, rather something that github has created, they have decent enough FAQs and help pages if you google a bit. On your local development machine, I'd suggest that you use the built in git remote too to have a reference to the original repository, I usually do git remote add upstream <url of original>, where you can get the URL from github's interface, which allows you to update your own computer with changes from the remote quite smoothly. There is no way for the github web interface to stay in sync with the original repository, so you have to do that manually, eg

git pull upstream master
git push # this goes to your origin repository, which is the forked one

... and so forth.

Different strokes for different folks, but I'd suggest either Sublime Text 3 or VSCode for anyone looking for a reasonable js/script language IDE. At least with ST3 you need a bit of plugins to make everything work nicely, so similarly to the js ecosystem at large getting started is a bit of a pain. Also, in general you should set up the build tools to enable writing ES6 no matter what you're targeting, it makes a huge difference in DX.

#8

for general text editing, Id second Sublime Text or VI :slight_smile:

but for doing work on the patcher use Netbeans, because the dialogs are using netbeans forms which must be changed with its editor, otherwise you'll screw up future editing with it.

as for managing forks, the GitHub documentation is excellent, and is aimed at new users,
start with https://help.github.com/articles/fork-a-repo/