Lets work our way to a new stable release.

Started by Audionut, April 20, 2013, 03:32:40 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Audionut

The devs seem keen to get a new stable release out that includes all current models.  They can't do that without knowing what's working, and more importantly, what doesn't.

This is a thread for you to list what camera you are using, what features are working, and which ones aren't.
Options that aren't listed haven't yet been confirmed by users to be working.

Please do not make feature requests in this thread.

Canon 5D Mark III

Audio
Working

Not Working


Expo
Working
All white balance options
ML digital ISO

Not Working


Overlay
Working
Zebras
Spotmeter
Histogram
Waveform
Vectorscope

Not Working

Movie
Working
All image finetuning options


Not Working
Load H264.ini  -  See the bottom of this page http://www.magiclantern.fm/forum/index.php?topic=4124.25

Shoot
Working
Advanced bracket
Mirror lockup

Not Working

Focus
Working
DotTune AFMA

Not Working

Display
Working
Advanced settings - Screenlayout, UpsideDown mode, UniWB correct

Not Working

Prefs
Working

Not Working

Scripts
Working
Tried a couple of scripts and they're working fine

Not Working

Debug
Working
Screenshot


Not Working


Didn't realize there were so many options until I had to start typing them out :)  I dare say the formatting of this post will change as more results are added.

Please feel free to list your camera and the options you have tried.

deletedAcc.0021

I like the idea.  I'm testing the 4.20 build on a 600d at a shoot this weekend and will report back.

Preliminary testing:  (stuff I use most and tested before the shoot)

MZ
WB & ISO shortcuts
3x zoom
cropmarks

all working as expected.

a1ex

Some of my plans (just what came to my mind right now):

- PicoC will be replaced with TCC. For now, it's still there because it does the job.

- RAW discovery. I don't feel like polishing the old hacks for a stable release (e.g. current bulb ramping method, or UniWB), now that we have the real thing.

- Backend stuff: we are pretty close to the limit of how much RAM we can use (how many things we can cram inside). Module system (under development) will improve this. This can be for 2.5 if you ask me, but g3gg0 would like it earlier.

- I'd like a boot process that supports all cameras with a single download (like the unified 2.3 zip). The current approach does not scale to the new models (it requires a huge fat binary containing the code for all cameras). I'd like a small platform-independent bootloader, the camera-specific modules (ML core), and user modules (functions that are only loaded on demand; usually platform-independent code).

So at this point I don't feel we are ready for a feature freeze.

I'm even thinking to switch to the rolling release model (just nightly), as it seems to fit better a hobby project maintained in our spare time.

P.S. This shouldn't stop you from running these tests. Good bug reports are always welcome, and in most cases, the bugs are fixed very quickly - once we know how to reproduce them.

1%


Francis

I know I don't contribute to the development but I am also for a rolling release. Maybe if something changes dramatically like the need to update files other than autoexec.bin. Like when the dir structure changed or when the boot process will change to use modules then change the version number to denote incompatibility with older builds.

That is how I discovered how great ML is, through the new builds in the google group. I didn't pay attention to the version number, and wasn't waiting for the next.

The big issue with rolling release is staying on top of the documentation. Menu structure has changed a few times since 2.3 it seems. Wish I had more time on my hands to update the user guide.

deletedAcc.0021

this might sound stupid, but what is a rolling release?

Btw,  shot for 4 1/2 hrs today using the 4-20 build.  Absolutely no problems at all.  Very stable.



Edit: nevermind, looked up rolling release on Wikipedia.

g3gg0

Quote from: a1ex on April 20, 2013, 05:51:31 PM
- Backend stuff: we are pretty close to the limit of how much RAM we can use (how many things we can cram inside). Module system (under development) will improve this. This can be for 2.5 if you ask me, but g3gg0 would like it earlier.

we can use the free RscMgr RAM on models that have it. (60D, 7D)
others must wait until we e.g. load ML from a object file like a module or have some other method.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

1%

Can we pinch memory from used areas? Like reset start and end?

Audionut

It's been 10 months since the last stable.  Time flies.  :)

I think it's important to get some new releases out to satisfy those who cannot build their own.  Especially for the new ports that aren't included in the nightlies.

It's a difficult situation as this isn't just some piece of software that can just be uninstalled if it all goes south.

I've finally managed to build my own 5D3 releases.  I'll stick my hand up to build releases of the new ports on say a weekly basis with their own dedicated release threads with a layout similar to this.

edit:  I'll need forum permissions for the nightly section if you're happy for me to do this.

nanomad

Building a nightly for unsupported cameras is actually quite easy (it's a matter of editing a script), so that's not really an issue. Before doing that I need permission from the port's developer though
EOS 1100D | EOS 650 (No, I didn't forget the D) | Ye Olde Canon EF Lenses ('87): 50 f/1.8 - 28 f/2.8 - 70-210 f/4 | EF-S 18-55 f/3.5-5.6 | Metz 36 AF-5

a1ex

Weekly builds probably make sense for those who don't like to be early adopters. Scenario: say we build the weekly on each Monday morning at 5 AM, early adopters can try it and post some feedback in the first half of the week, and if no major problems are found, the more conservative users can grab it for shooting in the weekend. But there isn't really any difference from just downloading only monday nightlies, so it's probably just a matter of taste.

We will need a separate zip for each new port, because these autoexec's are not cross-platform. We could squeeze everything inside, but the fat binary is getting a bit too big and may cause slow loading times.

Docs can be built automatically; they are only outdated. Here's some work in this direction: http://www.magiclantern.fm/forum/index.php?topic=3820

Maybe we can also revisit this:

http://www.magiclantern.fm/forum/index.php?topic=4318
http://nanomad.magiclantern.fm/feats.html

What about adding a thumbs up/down for each feature/camera pair in the feature table (each checkbox)? Example: a user clicks "thumbs up" for "zebra / 5D3", which means that feature works fine on his 5D3. Or, "thumbs down" on "bulb ramping / 50D", which means he had trouble with it. With this we can have some clue about what things are widely used, what things work well, what needs more attention and so on. For more detailed feedback, we can just add a link to the forum.

Download counters should be also helpful.

I also have some experiments which can analyze the code changes and identify which features were affected by code changes. E.g. if one edits the cropmarks code (inside #ifdef FEATURE_CROPMARKS), the "cropmarks" feature can be highlighted somehow in the automatic change log, so users can expect something different when using them.

Audionut

The weekly-monthly builds back on google groups were good, as you say, it was easy to wait and keep an eye on the post for a few days to read the feedback.

7-zip reduces the 5D3 binary from 413,536 bytes to 171,993 bytes and the current nightly zip from 2,784,803 bytes to 1,360,937 bytes.

The thumbs up/down is a good idea as long as the spam from trolls/accidents (wrong button or whatever) don't affect the results and create more work.

An email update when changes are made to a specific build would be pretty cool.  Sounds like a lot of work though.

coutts

I think we can adopt a release system similar to Cyanogenmod:

Quote
NIGHTLY BUILDS

Are HIGHLY experimental. Do not post issues to the issue tracker. Chances are the CM team already knows about the issue and are working to fix it. Be patient flash the next nightly. Complaning about battery life or any number of issues will not change a thing as to that these are EXPERIMENTAL builds!!!

M-Series

Something we have learned over the past few months is that if you don't release, someone else will do it for you. Since we are open-source, we absolutely encourage it! Unfortunately, the quality of unofficial builds can vary, and we are serious about quality. Of course nightlies are always available, but we realized that having something that is a bit more stable on a more frequent basis is important. Starting now, we are rolling out our M-Series releases. M-Series builds will be done at the beginning of every month. We did a soft freeze of the codebase for the last week, blocking new features in order to stabilize. Our plan is to continue this (assuming that the response is good) up until stable release, and onward.

We aren't exactly sure what M stands for. "Monthly", "milestone", or perhaps "MINE ALL MINE!". Whatever it is, I hope that we are meeting the needs of community.

M-Series builds will be available under the EXPERIMENTAL tag. The filename will include the date stamp as well as the M version. These builds should be stable enough for daily use, and we encourage feedback and bug reports.

RELEASE CANDIDATE

Everything is believed to be working at the time of release.

1%

Milestone Builds  are a good idea. That way they have a "stable' build for the month/week and a nightly for those who can't wait on a new feature.


menoc

Weekly would be ok, but here's the problem . . . updates will probably also take longer and feature sets will also have longer wait times.

I think we should have both, a weekly stable, and a bleeding edge nightly - I like living on the edge. That way, people can have more frequent feature sets, and those who would like to test can get the nightlies.

nanomad

The point is, we cannot guarantee a weekly stable build (or at least I can't). That's why I was proposing to create a "testers" team that picks a build, tests it properly on multiple bodies and properly reports back any issues found. This way devs can very quickly fix the bug (if they already didn't). Once the "testers" think that the build is polished enough we can tag it as "Milestone" for a broader audience to test it. In the meanwhile we'll keep publishing nightly builds as we always did.
I did something similar with the 650D and it worked out pretty well given my limited time.
EOS 1100D | EOS 650 (No, I didn't forget the D) | Ye Olde Canon EF Lenses ('87): 50 f/1.8 - 28 f/2.8 - 70-210 f/4 | EF-S 18-55 f/3.5-5.6 | Metz 36 AF-5

deletedAcc.0021

I would be willing to be a tester ... sign me up.

blade

For me as a tester, i would welcome a more structured way for testing an feedback. A thumps up/down method, with the ability to provide additional info and ore links would be very nice. I now find myself struggling in providing good feedback ( and that includes what does work, what doesn't work, and what i have not tested) in a readable setup.

Additional if a new build is available it would be nice to have an overview of what has changed. This would enable me to focus on stuff that was changed, and not the whole thing.  This would also enable the developers to asks the testers to focus on a particular item.

This is the first time I am participating in a project as this, but the method used now with Nanomad works really well for me.

I would welcome a testers build!

A weekly update would be nice, and even if there are no changes, at least we would now that the bugs present are not jet fixed and we can focus on finding new bugs.

eos400D :: eos650D  :: Sigma 18-200 :: Canon 100mm macro

Datadogie

T3i and Kiss X4 (550d (T2i)) Tamron 18-200mm, Sigma 28-70mm f2.8 (need firmware upgrade) Olympus 50mm f1.8  Olympus 28mm f2.8 and Olympus 24mm f2.8
Fancier 370 tripod and LCD hinged loupe. DIY Slider and crane.

deletedAcc.0021

Does it look like the rolling release idea is going to take off?

1%

I've been doing it the whole time for 600D/6D and I guess M now. 6D kinda took the front seat but its evening out.

l_d_allan

Quote from: Francis on April 20, 2013, 09:23:02 PM
The big issue with rolling release is staying on top of the documentation.

Agree, reluctantly.

As an overwhelmed-by-the-wonderful-vastness newbie of ML, I'm finding the 2.3 documentation to be less and less useful. When I first started using ML 2.3 not that long ago, I was impressed by the documentation. Now it is getting more frustrating. It can be Very Disconcerting for a newbie to try to figure out something, and have the doc's conflict with "ground truth" on the camera LCD.

Also, I'm really eager to try nightly builds for Auto-Dot-Tune and RAW-histograms, but reluctant to expose my camera to what I perceive to be a risky, trial-and-error, potentially costly pre-alpha nightly build.

Perhaps there could be something like a "skin" that exposes less capabilities to beginners (what is documented in stable release?), more to intermediates, more to advanced, and everything to developers?

I recall from my days of active FOSS participation, that there is a real tendency for devs to lose track of how intimidating the learning curve can be. With something like the Audacity audio editor, at least there was very low risk of damaging your computer with a hang. My perception is that even an experienced ML user has a very real chance to brick their DSLR with a nightly build.

Yet, if ML really wants to be have wide acceptance, it needs to retain some level of user friendliness and making newbies feel somewhat welcome. The reality can be that feedback from newbies can be as, or more, valuable than from experts. Unless ML is ok with being increasingly "experts only"?  I don't think ML is likely to ever be for beginning photographers, but there are a LOT more intermediates than experts/pros.

It does bring up the question: what assumptions about the experience/expertise level does ML want to make of its "audience"? So far? In the future?

nanomad

Well I find the UI quite user friendly after the last set of changes, and if you don't know what a feature does you can either
- ignore it
- read the documentation if available
- Google it
- ask on the forum
EOS 1100D | EOS 650 (No, I didn't forget the D) | Ye Olde Canon EF Lenses ('87): 50 f/1.8 - 28 f/2.8 - 70-210 f/4 | EF-S 18-55 f/3.5-5.6 | Metz 36 AF-5

1%

Had feature shock at first too but then I got over it... there was feature shock from 400D -> 600D. Everything new has a learning curve.


blade

Quote from: l_d_allan on April 26, 2013, 08:00:16 PM
It does bring up the question: what assumptions about the experience/expertise level does ML want to make of its "audience"? So far? In the future?

Well lets asume you deep enough into photography to:
- spend 600+ euro on equipment.
- feel like the hardware could do a better job
- have the guts to download and install ML lantern on your expensive hardware.

Then i would also asume you would be willing to spend the time to figure things out on your own/documentation/forum.

I think the documentation we get with ML are already far superior to what we get from canon ( as there is no real in camera documentation).
eos400D :: eos650D  :: Sigma 18-200 :: Canon 100mm macro