Stable build | Latest builds

[Audionut]

Are these one month old builds considered to have have been around for some time and unlikely to cause any major issues? So can these be trusted even though they are only 1 month old?

All of the experimental stuff gets tested in other builds (branches) first, before being pushed into the nightly (branch) builds.  So the nightly build might only be 1 day old, but the code has been tested for some period of time longer then that.

Hello I am also new to Magic Lantern and it's great features. I've installed ML on a 5d mark II and I am impressed. I would like to istall it also in my 6d but if some tests from the latest build are failed that means that I should wait to be fixed first?

Looks to be a false report, but I'm not sure.  One of (out of all) the older builds also shows the same error.  But the other builds appear fine.

[Walter Schulz]

It's not false reporting. See disclaimers
"Most of these builds are tested, to a limited extent, in QEMU. These tests are automated - if they fail, there might be either a real bug in the tested build, or a bug in the emulation. The only way to tell is by testing on real hardware and comparing the results - your feedback is welcome!"
and
"This build was tested, to a limited extent, in QEMU (a virtual machine modified to run Canon firmware).
Please take the results with a grain of salt - this is not the same as running on a physical camera."

[a1ex]

... older builds were untested, that's why they appear fine

Pretty sure this particular bug is real (not a major one, but it did cause a lot of headache with 100D). Fix is here (see also here) or on the Experiments page (all of them have it included). Does it work? (selftest.mo -> null pointer test). See also this call for testers.

That's the problem with blindly maintainted builds - users don't seem to be aware that we are unable to move forward unless they provide feedback. Valid for most other models (where the developers who did the initial port are no longer active), not just 6D.

[Gkos]

So, is there a problem if I install it to my 6d? Or it is more safe to find an older build rated as "successed"?
Will I have any problem?

[Walter Schulz]

We can't know the future. Read disclaimer (Top of page -> User Guide -> FAQ) and make up your mind if you want to take the risk or not. AFAIK worst case (= brick during install) didn't happen yet. Alas, there is no guarantee it won't happen to your cam.

And because newest build tends to have fewer bugs than the one before: Use the newest one.
You won't find an older build for 6D labeled "success" because such a build doesn't exist.

[Gkos]

Thank you Walter.... I understand that. But did the (recent) previous builds "pass" the Qemu test? Also build for 5d mark ii for example is somehow "better dicovered"? Cause it passes all the Qemu tests at this time.

[Walter Schulz]

But did the (recent) previous builds "pass" the Qemu test?

Take a look:
Top of page -> Downloads -> Download nightly builds
And reply #27 and other answers to you in this thread.

Also build for 5d mark ii for example is somehow "better dicovered"?
Cause it passes all the Qemu tests at this time.

Answered in reply #27. 5D2 was - before user reddeercity jumped in - considered to be "blindly maintained", too.
Term "blindly maintained" means that no developer owns the cam and hunting down a bug is more difficult and requires users to come up with proper issue reports.

[Gkos]

I see. Could I ask, what does null pointer means?

I would be very gratefull if you have the patience to tell me (briefly)

[a1ex]

https://en.wikipedia.org/wiki/Null_pointer

The null pointer test checks whether ML can detect this particular error and save a crash log (rather than ignoring it silently). These errors may come from both ML code (where they should be fixed), or from Canon code (these are harder to investigate, so we have chosen to ignore them for now; we used to whitelist them, but there were just too many of them, so we gave up).

Older builds marked as successful simply did not run the tests that are now failing (so they are not safer in any way, just less tested).

Please note the QEMU tests are just barely scratching the surface - less than 10 features out of several hundreds are actually tested like this. Things are improving, but manpower is an issue, so any help is welcome; however, most of the interesting features require emulating things like photo capture and LiveView (so the tests that can be run right now are pretty limited - menu navigation, DryOS internals and so on). (Don't know where to start? Right here; the tests are just bash scripts around QEMU).

BTW, here's an animation (5D3.gif - 10MB) that shows some script-driven ML menu navigation (it takes screenshots and compares their hashes to know where to stop). Just navigating each top-level menu option - without even trying to change the submenu settings - takes 15 minutes for the script, at 2 keystrokes per second. This does not test any functionality - it covers just plain menu navigation (top-level settings only). The linked animation is a WIP for this proposal.

[Gkos]

Thank you very much Alex for all information..  Maybe I would be "repeatable" if I say how gratefull I also am, with many many other people, for the work that are all doing?

I installed ML to my 6d today. I confirm also the flickering menu problem...

[spiceagent11]

Hi, have never installed ML yet, now's the time.  Please help me out by clarifying: The current Nightly Build for the EOS-M has "failed," I see.  Went back through the logs for the most recent build that was not labeled "failed," and that was: 2015-04-18 18:08:06 - 0400, change set e08c6c0.  My question is, should that version be all right