Difference between Tragic Lantern and Magic Lantern

[l_d_allan]

I think the project would attract a larger userbase if it was possible to make the ML releases into something that separates the more stable functions and the "in development" functions:

+1

[Afterimages]

+1

[a1ex]

This requires thorough feedback from you about what works well and what not. See the posts from dmilligan from this thread.

[evero]

This requires thorough feedback from you about what works well and what not. See the posts from dmilligan from this thread.

I totally understand you and dmilligan. And this is the classic egg/chicken problem, because the reality for me (and I guess a lot others) is that I don't dare testing ML at this point. It's not clear which release (is safe enough) to use for the 5d3, and using nightly builds sounds to dangerous for a guy who's nervous to harm the camera.

So even though I want to help, how can I give any testing/feedback, when I don't even dare to install it... Because of this I'm probably not in the target group for ML for now (and I totally understand that). But knowing the positive vibe around the ML project, and the already long and impressing track record, my idea was this approach with labeling a few basic features "beta reliable" in a release. By doing that a new user base would dear to engage in the project, providing feedback etc. (but again, this is just from a user perspective - from what I now read, I understand this is easier said then done ofcourse)

[thehadgi]

Hm.... People are talking about this API/documentation thing

I'm a business analyst  (and getting my feet wet as a QA analyst for experience sake) in IT for a major retail chain. Pretty much my entire job is documentation. While I'm not familiar with actual coding (yet!), I do have a good amount of experience under me in documentation of features, specs, etc. Wondering if maybe I can at least hash out the overall doc and get it flowing, and then some if the devs can provide all the detail where necessary?

Maybe it'd make sense to start with 2.3? Then for every stable release I can have the changelog in the doc, documenting everything?

I don't know; just something I'm throwing out there. If no one still has 'formerly' documented all the bits of code, if be more than willing to help might even get started right now. (Unless any objections?)

[a1ex]

http://www.magiclantern.fm/forum/index.php?topic=6594
http://www.magiclantern.fm/forum/index.php?topic=3820

I prefer having it edited on the repository, because from this format I can generate PDF, HTML, wiki and in-camera BMP versions.

[thehadgi]

http://www.magiclantern.fm/forum/index.php?topic=6594
http://www.magiclantern.fm/forum/index.php?topic=3820

I prefer having it edited on the repository, because from this format I can generate PDF, HTML, wiki and in-camera BMP versions.

Ahhh, nice I see. Cool!

[macker]

These are my personal opinions, nothing more.

First, for end-users: No firmware modification can be guaranteed to be safe.  That said, ML is probably as safe as it can be.  TL isn't as aggressive in trying to be safe.  That's not to say it will irreversibly brick your camera; hasn't happened (reported) to anyone yet, but past performance is no guarantee of future results.

You may have read about the possibility of a merge.  Do understand, this isn't a simple process.  If two people start with the same book, and they proceed to rewrite certain sentences, paragraphs, add chapters, tables, diagrams, and so forth, the books will look similar, but you can't just swap pages between them.  That's what the merge would be; trying to bring some of the pages from the second book, into the current revision of the first.  And making sure there's no missing references, e.g. "see explanation in the next chapter" wont work, if that chapter isn't also merged.

Deciding whether to run ML, TL, or anything else, is about risk acceptance; decide what your level of risk tolerance is, and whether the features are worth it to you.  If you run either, you can help yourself (and everyone else) by reading the guidelines for bug reports.  Bug reports are like a meal; fresh food, good flavor, adequate portions, and some dessert will help keep them going, and remind them you care.


Second, to the devs.  Open source projects are typically a labor of love, and heartache is inevitable.  Watching a project grow beyond your personal use, especially over significant time, expansion, and contribution of others, it carries a lot of rewards, and frustrations.  Hindsight is a cruel mistress, and everyone's a critic.  Reading this thread, I found significant insights into some of the frustrations that are at play; the statement of them felt particularly candid, and I believe that's an important and useful thing.

As developers, you're giving time, but it's backed by critical knowledge.  We, as the community, can't afford to lose you; it's unlikely you'd ever be replaced.  Most users want to help, but are untrained in how to do so; often, they'd rather be quiet, than be unhelpful.  Of course, there's those who are unaware or ignorant of the realities of a project of this scale.  The single most important thing I can suggest, is an open and ongoing dialog; candid and forthcoming.  And remember, many more would try to help, if they knew their efforts wouldn't be counter-productive.

tl;dr: Thank you, good luck, stay strong, and don't be shy; communication is crucial to success of any project that has more than one person involved, be it collaborators or users.

[globalphotobank]

Well said 

[PhilK]

Test, as in really test. As if you were QC working for a software company. Don't just use ML in normal situations and submit problems when things go wrong (and don't just do another ML RAW vs. H264 test, there are more than plenty of those out there). Try to break a feature. Think of as many possible scenarios as you can. Throw everything you can think of at a feature to break it. Try every value of every setting. Try it in extremely unusual scenes or lighting. Write down your results like a scientist doing an expirement. Then share your results, even if nothing went wrong. It's also helpful for devs to know when something actually works. Test for the sake of testing, with specific intention, not for the sake of making your 'budget short film'.

What could be better for the Devs and easier for people to contribute to is producing test scripts.  A simple and clearly documented set of steps with the results easily quantifiable.

Something like this (a very basic example).

• Enable the raw.rec module [pass|fail]
• Enter the Movie menu and then enable Raw Video (when in Live View mode - pick resolution suitable for you card) [pass|fail]
• Render video and inspect it to check for bad frames [pass|fail]

While you sometimes can't go wrong with free-form testing, a more structured approach means you can measure the test coverage and split this activity up so many people can contribute and still have some control.

As new features are added, or defects found, new tests should be created - essentially moving to a Test Driven Development model.

As the website is PHP based there will be off the shelf applications that could be deployed to the site to automate this easily, or just use Goggle Docs and track it in a spreadsheet.