Awesome Video Kwatters !  Great to see someone else use the webgui (and how they do it)
Just making a quick list of stuffs left to do for release :

  • 2 other videos - one for Arduino, one for Arduino + Servo, one general purpose ? How to start mrl + Java requirements (32 bit vs 64)
  • The Python WebGui editor is a shambles ... I have some ideas on how to fixup, but should this hold the release ?
  • Still haven't fixed the 2nd set Arduino (write) buttons
  • List of items preventing the release

I've tried MaVo's awesome git-Fu commands he left in the pull request .. works great !  - but haven't replaced master with develop (yet)

Any reason not to replace master now ?  ... seems like it will get us one step closer .. any additional changes can be pull requested in the appropriate way after ...

MaVo

7 years 7 months ago

I can only agree with you GroG, this video is magnificent. Good job, kwatters !!!

 

I started working on a video for Downloading&Starting MRL two days ago, will probably take another few or more days. I can only encourage to not rely on me for this one as my audio will have it's own little surprises ...

 

@grog: I didn't said that everything has to be in pull-requests ... (I also don't think it would be good.), but I think a specifc plan for further development-organisation would be needed before replacing master with develop content (for example like in the link ( -> http://nvie.com/posts/a-successful-git-branching-model/ ) I shared already).

I didn't say everything has to be in a pull-request - 

But my intention is this :

2 major branches (develop & master) - could be many more, it depends on the purpose

develop the group directly commits to

master is managed from pull requests from develop ..  which is basically the same as the diagram

(Sorry, sounded like you were trying to say that)

In rough, I agree with you,

but I want to correct a small detail:

There is a major difference between pull-requests and the different versions of a merge. Not only a technological one, but it's a completly different concept as well. In "most projects" pull-requests are just used for submitting work / contributions to a project you don't have write-access to. Or more general - for introducing new content (Note: in some projects they may always be used to merge feature branches into developing branches as it makes an easy discussion BEFORE the merge possible (you can compare this to what I did with the webgui restructuring thingy) ). Here is another important aspect about pull-requests: Unlike normal commits, pull-requests can be accepted or rejected BEFORE they ever reach the offical codebase. Therefor they usually aren't used for internal branch-managing, why create the pull-request, accept it in the next step and then deal with the ugly pull-request-merge-message in your git log, when you could just create a clean git history by merging it with fast-forward disabled.

Note: This is only my opinion - and what I've learned by working together with people that use git longer than I do. I started to really love the general idea of a git-flow like system, especially the one I linked earlier. For me it made development and colloboration much easier (and cleaner) as soon as I got the hang of it (less conflicting code, easier merges, stable next to development with a technique to add hotfixes, work to a release, etc., ...) (and I love the resulting git history graph : ) ). - Again it doesn't has to be done that way, it only needs to be described very well, how it should be done.

I can only suggest printing out the pdf. After a few days (when you start to fully understand it), you'll begin to admire it's beauty.