Q Light Controller+

Hi all,

I've been playing with Git/GitHub and generated this for new fixtures:

https://github.com/boxy321/QLC_fixtures_repository.git

This is my first Git project so please check it out and let me know if I'm being stupid. There 2 are branches in place for 2 recent fixture submissions. I guess these need pull requests for people to review.

Once the framework is established we could use git so we don't have 2 people creating the same definition at once. ie. Tell creators to check if someone has already created a branch for said fixture.

Regards,

Boxy

Hi Robert,
thanks but, what's wrong with the QLC+ repository ?

If you agree, let's discuss and put in place a more efficient workflow to introduce new fixtures.

Right now the workflow is:
- users submit qxf files in this forum
- no action is taken
- when a QLC+ release is nearing, I make a list of the pending fixtures, divide by 3 and kindly ask Jano and David to help me to review and push them
- if a fixture is a chinese product, it goes into the QLC+ extras repo
- if manual is missing, fixture goes pending and we ask for more information
- if fixture is badly wrong, we ask the user to fix it
- if a fixture is OK or almost OK we fix it and push it to the QLC+ repo

This has worked so far, but it has a side effect which is that between releases, fixtures are not reviewed, so one file can lay on this forum for a couple of months and the submitting user will not even reply if we ask for more info, thus loosing the fixture completely.

I would like to change this workflow to this:
1- users submit qxf files in this forum
2- a number of trusted reviewers (you for a start ) download the file and check it against the product manual
3- if more info are needed, the reviewer replies to the submitting user and ask for what he needs
4- if the fixture is OK, the reviewer sends a pull request to the QLC+ repo for merging

Please note that on #4 the fixture should comply with all the other fixtures (modes OK, physical info OK, gobos paths OK, descriptions in english, correct heads, etc..)
Basically when receiving the final PR, who merges it should not even check it, cause the reviewer is trusted and take the responsibility for the final quality of the fixtures
Who merges the PR, should only update the fixtureMap file and update the changelog with the proper credits.

If you are willing to help us in this way, then you are more than welcome !
What do you think ?

Thanks Massimo,

Exactly what I expected to hear.

What is wrong with the QLC+ repository? Nothing. That's why I created my own version to play with which I couldn't break or broadcast pull requests to as I fumbled around using the Git 'language' and philosophy.

I will look again later on.

Thanks,

Boxy

Hi,

Pretty much all you need to know is in github help pages:

https://help.github.com/articles/using-pull-requests/

Ask here if you have an issue, but it's pretty straighforward, you shouldn't have any.

Your help is very welcome

Hi Robert,
no worries about wrong PRs. They do not harm the QLC+ repository and if they're wrong they can be closed or you can revert/improve them.
It's just a matter of learning the right process to submit them and if you have problems with Git we can help (Jano more than me )

Basically this is a little howto of the "new" workflow for you:
1- fork the QLC+ repository (you need to do this just once)
2- make sure you're up-to date with the GIT repo by doing "git pull" or if you're using a GitHub client by pressing the "Sync" button
3- download/review/fix a submitted fixture
4- place it in resources/fixtures of your forked repo
5- commit the change to your repo
6- go to the GitHub website, click on the commit you just made and then click on "Create a pull request". I think you can also do it with a GitHub client (there's a button for it)

To make the merge easier for us, please create a separate pull request for each fixture, so basically on your side: one commit = one PR.

Now, the pending fixtures are:
- Fixture Definitions forum: all those submitted since "Showtec Indigo 6500 (updated)", excluding "Ayra ComPar20"
- Fixtures request forum: all since "VENUE THINPAR 38"

Total: 22 + 12

Each PR should also be on its own branch.

plugz wrote:Each PR should also be on its own branch.

Ouch. Didn't know that but it actually makes sense. (I've never sent PRs myself...)
So, can we refine the howto also with the branching stuff ?
I guess it's something like:
3.1 - create a new branch with "git checkout -b newfixture" ("newfixture" is the branch name and must be changed for each fixture). If you're using a GitHub client see here: https://help.github.com/articles/creati ... epository/
...
7- switch back to the master branch with "git checkout master"