Q: How can we (as in "non-developers and not going to change status") support you (as in "devs") to make this happen?
This is not directed at you Walter, but at the community in general (you are one of the most helpful folks on this forum, keep up the good work
):
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'.
If you notice a problem, figure out how to repeat it and try to isolate it to a specific build (or if you can compile, isolate it to a specific changeset). Looking at the change log on bitbucket is very helpful in doing this (look for commits related to the feature and check those builds first). This requires no coding ability at all, and can save devs a lot of time, b/c they will know exactly where in the code the problem lies. Even I can figure out bugs that would normally be way above my skill level if you tell me exactly the changeset that is causing it, in fact most of the very few patches I've submitted, I've found like this.
This has been reiterated by a1ex time after time, I'm sure he's tired of saying it. It's clear that very few people actually end up reading the 'how to report bugs' links he posts.
A good example of the lack of this being done is the 600D 'overheating' issue. Countless people have reported this issue. Not one has done anything to help resolve it. Simple scientific-like experimentation can easily help resolve the exact source of the problem without any coding skill at all (e.g. monitor the temp of the camera overtime, both the display temp and with an actual thermometer, try different builds, use the stable build as a control group, etc.). The nightly builds are for testing, nobody actually seems to be doing this, or their idea of 'testing' is: 'use in a production enviroment and complain when something goes wrong'
I think the general response to the troll question "when a stable build?" should not be a link to the faq, but something like: "As soon as
you provide us with clear and concise testing and bug reports for all ML features"
Indeed, and move towards a clean and documented API.
+1
My main stumbling block in terms of trying to help out with development is not lack of coding skill, but rather lack of specific knowlege of the ML code base. I have enough spare time to do some basic coding, fix minor bugs, and add little features here and there, what I don't have time to do is review and understand hundreds of thousands of lines of rather convoluted (understandable, it is a hack after all, and an embedded/RT system) and poorly documented (no excuse for this) code. For example the multilevel submenu thing, I feel confident that I have the coding skill required to implement it myself, the problem is I don't understand menu.c well enough (which I've tried, b/c I'd really like to get it done for my module, I usually just stare at menu.c for 30mins and then give up). At a glance, I have no idea what functions do, when they're called, etc. Sure I could probably eventually figure it out if I took the time, but I don't have that kind of time. A few simple comments before each function (even private functions) would be extremely helpful (like description, parameters, outputs, prereq's, where it's called from, task, etc., and put these comments in a standard format for automatic docs generation, e.g. doxygen).
It sounds to me like, at least to some extent, 1% has done this and that's what he is refering to when he talks about his "notes". If that is the case, then I actually would welcome 1%'s "notes" into the main repo (perhaps they just need to be cleaned up somewhat?). IMO, the more comments and documentation that's in the code, the better it is, as long as it's not 'incorrect' information or in 1%'s own language/shorthand. I haven't reviewed the TL fork code b/c I don't use any of those cams, so IDK, maybe I should. If I manage to get my hands on a 6D (which is very tempting now that it's only $1,500), I am more than willing to help merge the TL fork.
I've been trying to clean up my own repo and learn as much as I can about mercurial. I've learned some good practices and plan on sharing them (in a new thread). Following these tips I think will help everyone who maintains a fork manage their own personal tweaks as well as making it easy to get stuff merged back into the mainline.
