suggestion - include a "latest problem free nightly build" sticky.

Started by mannfilm, March 31, 2014, 05:42:58 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

mannfilm

It would be very helpful if you had a sticky listing the most recent stable, problem free, nightly build. You can't trust the most recent build for serious work, and it is difficult to gather info on specific older nightly builds because issues and problems are reported in many different areas.

nanomad

And who will decide whether a build is stable or not?
It's a work load us developer can't take. Testing a build to make it stable requires long and boring tests.

I can only state once more that you community is free to come up with whatever idea to make a new stable build real.
I'll provide all the tech and backend help you guys will ask for (assuming it's reasonable)
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

dmilligan

Quote from: mannfilm on March 31, 2014, 05:42:58 PM
stable, problem free
Show me any piece of (non-trivial) software that is bug free and I'll give you a million dollars.

Midphase

He didn't say bug free. You know what he means.

He's asking for something akin to the Tragic Lantern thread where certain builds had been verified to not have introduced problems and were essentially stable. It's been discussed before and it wouldn't be a bad idea, unfortunately with nightly builds coming fast and furious, it's hard for any of us to stick with one build for too long before moving on to a newer build.

To answer the OP question, I think in general the nightlies are pretty stable by now. Your best bet is to download and install whichever the latest nightly is and run some thorough tests before you use it on a shoot.

engardeknave

I was thinking that there could be a stability rating on the on the nightly page next to each build, perhaps with a few different categories for different functionality (raw video/bracketing/whatever else seems likely to break). That seemed like a lot of trouble though.

However, maybe something like that could lead to an actual release. If enough people get on board with testing a certain nightly and report back, you'd have a release candidate.

I decided today to keep an older version on another card before moving to the latest build.

Audionut

For a stable build to be viable, it needs to be maintained, probably at least monthly.
Otherwise it simply encourages people to use outdated builds.  The stable release version 2.3, is nearly 2 years old  :o

First and foremost, sufficient documentation needs to be created.  Everything that still applies from 2.3 can be copied.
We should probably get this post up to date.

engardeknave

Maybe there shouldn't be a "stable" build. It doesn't seem like that paradigm is really effective in this environment. Maybe just builds of lesser and greater rated stability via an automated system. I think most people would use a build for longer to contribute to stability testing.

I don't see why documentation is that important. If someone wants to do it, great. If not, you didn't lose anything--you simply gained undocumented features.

Audionut

Quote from: engardeknave on April 01, 2014, 05:16:51 AM
I don't see why documentation is that important. If someone wants to do it, great. If not, you didn't lose anything--you simply gained undocumented features.

That would be a nightly build  :P

noix222

on my 5d mark 3 every build i tested after 08//03 i get green footage problem... both modules raw_rec and mlv_rec. Raw_rec 1x normal but green at 3x mode... mlv_rec with black fix ON i get pink footage at 1x mode, turning it off footage comes out normal but at 3x mode with black fix on i get pink footage and black fix off green footage..... so talking about filming using RAW_REC and MLV_REC i would stick with build 08/03. ;)

Marsu42

Quote from: engardeknave on April 01, 2014, 05:16:51 AM
Maybe there shouldn't be a "stable" build. It doesn't seem like that paradigm is really effective in this environment.

What *could* be done ...

1. pick some random nightly after merging some big branch, throw out all wip modules and disable (#undef) all newer core features. Update this "pick" build only when some real bugs or regressions are fixed in nightly, not the usual feature additions or other changes. This should stop some whining, though I don't think this is a good idea though because bug reporting against latest nightly is useful for the devs... people simply have to face the fact that ml now is a rolling release

2. compile two builds of nightly, one with full wip features, the other without everything that isn't rock stable and proven, core or modules (mlv, ...). A "tested on (insert platform here) also is there in the modules, there's simply no front end yet to dynamically disable everything else and newer core functions.

Quote from: engardeknave on April 01, 2014, 05:16:51 AM
I don't see why documentation is that important. If someone wants to do it, great. If not, you didn't lose anything--you simply gained undocumented features.

But even the dox from the v2.3 "stable don't work anymore", menu layout changed some yadayadayada....

Audionut

With the branch system.  We should be able to create a stable branch, and work from there.  During the time it takes to complete the project, we could still merge in new features, that are "known" to be stable.

And of course, being a branch system, for usage of ML, you can simply move from nightly, to stable branches, as needed, depending on your needs.

This won't be a small, or easy, project to undertake.

I can work on documentation, testing, and any forum needs.

engardeknave

How about a plugin that logs usage and user feedback about stability? This plugin would generate a text file saved to cf/sd with the version of ML, functions used, maybe crashes, and then responses to a few questions about what worked (via camera GUI). As far as GUI, all it would need is a list of functions with three radio buttons (worked/didn't work/no response).

This could then be submitted to the site to generate a rating system. As more people rate a nightly positively, more people will download and use it, creating a situation where one nightly is fairly well-tested. This version can then be placed at the top of a download page.

Maybe ideas like this are going a little overboard, but it seems like less work than creating a separate stable version of ML. And once it's done, it should put the issue to bed for the foreseeable future.

a1ex

Quote from: engardeknave on April 01, 2014, 08:34:27 AM
How about a plugin that logs usage and user feedback about stability? This plugin would generate a text file saved to cf/sd with the version of ML, functions used, maybe crashes, and then responses to a few questions about what worked (via camera GUI). As far as GUI, all it would need is a list of functions with three radio buttons (worked/didn't work/no response).

This could then be submitted to the site to generate a rating system. As more people rate a nightly positively, more people will download and use it, creating a situation where one nightly is fairly well-tested. This version can then be placed at the top of a download page.

I've already proposed it :P

mWaltari

If not going for stabile branch (nightly) way. Other way could be bug hunt periodically.  Like every two months week or two only bug fixes and regression fixes allowed. And maybe tested speed optimizations...

mWaltari

But the stabile branch would be the best way if someone starts to maintain it.

nanomad

Proposal:
Wait for the cleanup branch to be merged. I'm ironing out one critical bug then it's good to go.

Branch off ML, Tag the version as 2.4.Next in the nightly builds

Disable module that are known to be unstable: suggestions?

Wait for user feedback.

Only fixes are allowed. No new features can go in, but they can get removed as we see fit

Expected outcome: either we strip dual iso and raw video or we are just better off with nightly builds
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

Audionut

Implement a1ex's proposal above.  IMO, this should be first cab off the rank, so that we can start gathering data asap.

Polish off module-tags.
This way modules can be controlled separately.  No need to remove them, simply tag them as world destroying, and disabled by default.  Separate option in module debug menu, to enable access to unstable modules, with big fat warning.
It will generate questions on the forums, but shows a clear separation, of known problematic code, and stable functionality.

Focus on core functionality as a starting point.  This way we can get a stable build out the door, asap.

Second stage, focus on the modules themselves.
Since most of the experimental stuff is module based (these days), the core functionality should remain clean.  Conceivably, new stable builds could be pushed after only minor updates to this core functionality.

Some stage down the track, separate modules entirely into separate user downloads.  Or the problematic ones anyway?

Quote from: nanomad on April 01, 2014, 06:12:40 PM
Wait for the cleanup branch to be merged. I'm ironing out one critical bug then it's good to go.
Branch off ML, Tag the version as 2.4.Next in the nightly builds
Only fixes are allowed. No new features can go in, but they can get removed as we see fit

Good idea.

Looks like users can submit pull requests to a specific branch also.  edit:  Yes we can.


Marsu42

Quote from: nanomad on April 01, 2014, 06:12:40 PM
Disable module that are known to be unstable: suggestions?

The question is what the intention of a 2.4 "stable" is... for me, it would be the way for complete newbies to get into ML with max peace of mind. People who want newer features like raw video *and* stability at the same time won't be happy in any case w/o an actively maintained stable branch with frequent backporting like Linux does, and that's obviously out of ML's scope.

Reading the post from people concerned about the lack of a stable port I'd suggest disabling every module that has even a faint wip status or is known to be quirky in any small way. The same goes for core functions which are a bit half-baked like expo presets, maybe it's a good idea to add some FEATURE_ macros if missing.

Imho there is no need for v2.4 to be more feature-rich than v2.3 as long as it has some more platforms and includes the general ui enhancements since then. For these remaining functions, writing or updating the in-camera docs might be also quicker. A more elaborate stable scheme with module tags and so on could wait until ML v3.0.