bitbucket protocol

[dfort]

I've got a question for the developers who have write and administrative permissions on the Magic Lantern Trammell Hudson bitbucket account.

What is the protocol for getting something merged into the unified branch so that it will be pushed to the nightly builds?

The reason I'm asking is because lately there has been lots of updates on branches and when an important issue is resolved in one of these development branches when does it get merged into unified? We have a situation right now where an issue with the metadata for some cameras wasn't being saved properly in MLV files. That issue was resolved in the mlv_prop_data branch but it was not merged into unified.

Now we have MLV Lite available for testing which is in a development branch called new-raw-format which understandably shouldn't be merged into unified until it is well tested but anyone testing that module with cameras that show focus pixels in raw video cannot test MLV Lite with the focus pixel removal tools recently implimented in MLVFS and MLP without using a custom build from the mlv_prop_data branch. This negates the convenience of dropping in new modules into a nightly build for testing, especially for users that are not able to compile the ML source.

There are also a couple of development branches for the lua module, lua_fix and lua_touch, which are resolving issues with the lua module. At what point are these going to be merged into unified? It seems to me that lua is mainly for experimenters and having frequent updates would be welcome for users who are writing lua scripts.

I've been posting comments on bitbucket about some of these issues and I certainly don't want to continue posting and possibly annoy developers. I'm just asking what is the protocol for requesting that a branch be merged into unified?

https://bitbucket.org/hudson/magic-lantern/issues/2460/700d-t5i-mlv-idnt-metadata-incorrect
https://bitbucket.org/hudson/magic-lantern/commits/3a9c6deedafd66d093b60abc4cc31492f1d87d17#general-comments
https://bitbucket.org/hudson/magic-lantern/pull-requests/684/mlv_rec-eliminate-propad_getpropertydata/diff

[DeafEyeJedi]

I second this as well ... Would love to know the proper SOP for this and thanks for starting this thread @dfort!

[a1ex]

It was my fault, I was just busy with other stuff lately, but I'm slowly catching up.

[dfort]

No worries a1ex -- I should be busy on other stuff too but Magic Lantern can become an addiction. Is there a recovery group somewhere?

[Danne]

Haha, write me when you find this group 

[axelcine]

Hey, guys, while I have being trying to compose something very deep and existentialistic, you'all circumvented me - and with good reason. But I'll post this anyway, because there are a few very principal issues here.

@dfort - your questions touch on a very deep feeling in me. I am happily working with my gear, trying to test the span of my possibilities, always seeking the limits, always looking beyond the horizon. And just now you strike the core of what ML is all about.

New features have to be tested very thorougfully and with extreme care before merger. ML is our basis for adventure, so it's our home base and the place we return to, when we have succeded or failed in our ventures.

I try out my files with MLProducer, MLRawviewer, ML Lite, I test luts, AE, Davinci Resolve, different lenses, different settings, different everything. And I get some results with one combination, other results with another, and in certain situations I end up with native 108op, a little post without losing the virginity... And of course I some times end up with a profound frustration. Back on the horse. Try again.

Thank God my cam is always my trusted horse. Postprod software may change, new systems pop up... But my ML is my point of reference, so I understand, when a merged feature doesn't seem to work after all. But then again... back on the horse.

The many ways to good ML footage represent the ideas and research from many dedicated people. The hard work behind MLVFS represents an approach different from MLProducer, MLRawviewer and MLVConverter, which is completely in harmony with the whole purpose of the ML Universe: to create several sets of ways to improve our work with our cam to chose from, based on our "chemistry", temperament, objective and preferred choice of method.

I'm totally confident that the latest nightly is a common denominator. It is what's tested and proven. I load the new ML Lite module with confidence on top of a good ML, and of course I'm willing to have a crash or two - or twenty, because ML Lite is uncharted, but fascinating land.

And I'm totally looking forward to the possibilities in LUA; dmilligan is doing an awesome job just as he is doing with ML Lite. Terrific.

I am totally confident, that the devs put nightlies together, that are "watertight", and I really love to put new features on top of my trusted basic nightly. My cam3 is a trusted 700d/ML, so I follow intensely the research on focus pixels and pinks, you yourself represent. The other two are 5dFrees, and they beep for joy whenever I invoke ML.

But basically I love the fact, that the nightlies are extremely conservative, and that new features have to pass an extremely tough examination. The member basis of the ML society is something like 46.000 people. Of these, maybe a few thousands are really exploiting the "deeper" features of ML. And maybe only a few hundreds are actually testing focus dots, pinks, LUA scripting, ML Lite, etc. so the statistic basis of testing may not be that large - and consecutively the depth of testing before implementing in the nightlies.

Which is a darn pity.

What I'm really trying to say is, that as long as you guys keep presenting ud with new ideas and solutions, I promise you that we're going to lick it up, test it out, discuss virtues and flaws... We have seen on many occasions, that research in one area has led to breakthroughs in other areas. But we do it on top of a well known basis: the trusted nightly.