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.

deletedAcc.0021

I haven't had any issues with lack of documentation, even with the newer features of the nightlys.  Read and understand the current 2.3 documentation so you have a basic understanding of how ML is layed out and works (understanding what controls do what), then apply it to the newer features.

If all else fails, ask on the forums.  Wealth of information available here, and I've found the developers are more than willing to help.


l_d_allan

Quote from: dslrrookie on April 26, 2013, 01:39:20 AM
Does it look like the rolling release idea is going to take off?

Perhaps a "Weekly Build" that could be expected to get "extra attention" compared to a "Nightly Build"? It would be understood to be less than an "Alpha".

So far, I've been impressed by the stability of the two "Nightly Builds" I've used on my 5dm2 and T3i. Still, my concern is that a "Nightly Build" can be not much more than "compiled semi-cleanly with an acceptable number of warnings from the compiler".

My perception is that one of the great strengths of ML is that the developers are passionate about what they are working on, and, perhaps even more important ... "eat their own dog-food". I'd feel more confident about trying out features if there was a sense that something like a "Weekly Build" had been served to several of the "developer dog's" with acceptable taste ... no developer's camera was poisoned / bricked.


scrax

Not totally OT, so will ask here:

What about using HG Flow in the source? From what I get it can help somehow to have a bit of more clear repo with master, releases, hotfixes, new features and development branches, no?
I'm using ML2.3 for photography with:
EOS 600DML | EOS 400Dplus | EOS 5D MLbeta5- EF 100mm f/2.8 USM Macro  - EF-S 17-85mm f4-5.6 IS USM - EF 70-200mm f/4 L USM - 580EXII - OsX, PS, LR, RawTherapee, LightZone -no video experience-

Audionut

I'd like to revisit this. 

Quote from: scrax on May 13, 2013, 10:15:37 PM
What about using HG Flow in the source? From what I get it can help somehow to have a bit of more clear repo with master, releases, hotfixes, new features and development branches, no?

This sounds like a great idea.  We could pick a nightly build to become the new stable, branch it off so it makes it easier to backport specific fixes.
I need to learn the HG system better.

g3gg0

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!

SDX

hg flow and then pick a nightly sounds ok to me. But lets first off wait 'till mlv is done - that's what most people are waiting for. I actually liked the procedure in which the 2.3 was released. First let the supporters have a go for a month, then a well produced trailer and to finish it: call it version 3. IMO too many things have changed since 2.3 to call it 2.4.

l_d_allan

Quote from: SDX on August 27, 2013, 01:26:31 PM
I actually liked the procedure in which the 2.3 was released. First let the supporters have a go for a month, then a well produced trailer and to finish it:

Agree.

Quotecall it version 3. IMO too many things have changed since 2.3 to call it 2.4.

Very much agree. The 2.3 documentation is almost too "stale" to be useful. There have been absolutely amazing improvements since 2.3.

I'm more of a "casual user" of ML ... perhaps install a latest/greatest "nightly build" every other week or so. I'm regularly baffled by what is new, and how to get it to work. Amazing features show up in the Menu, but it's unclear to me what they do, and what is "best practice".

Also, what might be risky to explore? That troubles me, and makes me reluctant to stray from what I feel I understand, or to help with testing.

Sorry for the whining. I am a HUGE FAN of ML. I try to look at the "change log", and the "Feature Requests", but I'm still often fuzzy on the "best practices".

l_d_allan

Quote from: l_d_allan on May 13, 2013, 09:54:34 AM
Perhaps a "Weekly Build" that could be expected to get "extra attention" compared to a "Nightly Build"? It would be understood to be less than an "Alpha".

Perhaps ML could have some "division" on Builds that focused on Bug fixes, and another for New Features.

Perhaps once a week (Sat?), there might be a "New Features Build", and other releases would be "Bug Fixes".

In such a scenario, I think I would be inclined to download and install the Friday Bug Fix build, figuring that it would tend to be the most stable. Let the "early adapters" and "pioneers on the bleeding edge with arrows in their back" wrestle with the latest/greatest, but least tested.

It's not that the Devs would only work on new features once a week, but that they would defer making them visible until Saturday.

However, I'd mention that the "rolling release" model does seem to be working reasonably well. New features are showing up at an astonishing rate, and stability has been more than acceptable.

Marsu42

Quote from: l_d_allan on December 16, 2013, 03:36:02 PM
Perhaps once a week (Sat?), there might be a "New Features Build", and other releases would be "Bug Fixes".

Imho the time period is way too short... though I like the direction.

As I mentioned earlier and like to repeat here, the Linux model sounds good to me and is proven to work - an expectable "merge window" for new features followed by a period of bugfixing until all new features work ok enough to call it a "release", then repeat. For the Linux kernel this period usually comes down to two months, for ML it might be longer or shorter depending how "stable" the new features merged prove to be.

Des219

I am new to ML and have not looked at the code, however I would think a good direction would be to move all of the camera firmware code to class.  Then have a standard class for the menu.  The menu functions would call wrapper functions that would call the camera specific functions.

When one of the developers starts to work on a new camera, (s)he would first start with determining the firmware verification test function.  Once established the system would boot with pass or fail and if failure then prompt to continue or not.

At that point the developer would start on each function.  For example dual ISO.  So the menu class function for dual ISO might look like this:

function menu_iso_dual()
{
try
{
camera_iso_dual();
}
catch(err)
{
Msg("this function is not available");
};
};

It has been too many years since C++ so example is in C# but the basics are there.

With the above structure you could quickly release versions for new cameras with functions as they come available.  I would also add a function stability option too. Something like:
Alpha = red menu
Beta = blue menu
RC = green menu
Final = white menu letters.

That way people are aware of the progress on each menu item.

dmilligan

Quote from: Des219 on January 31, 2014, 04:40:07 AM
I am new to ML and have not looked at the code
Then you should not render judgements about the code, b/c you clearly have no idea what you are talking about.

Des219

Possibly you do not understand what I am saying.  From the forum messages and my own experience as a software developer, my recommendation was to possibly help move the project forward to more end users in less time.  I am quite impressed by the developers and what they have accomplished.  Not so much by you and your comment.

Quote from: dmilligan on January 31, 2014, 01:13:58 PM
Then you should not render judgements about the code, b/c you clearly have no idea what you are talking about.

SDX

An idea would be to let the devs who aren't interested continue their work on the project, whilst another team sets out to create a stable version of ML as it is by now.
However, that would require that a few things that are in progress right now, to be finished (such as merging TL back, for 6D, M and 7D support).
On the other side: There will always be a new and exciting feature under development, so there is no point in waiting 'till everything is in a quite state (since it won't happen).

A new and stable version is, IMO, rather important for the health of the project.

romainmenke

Daily reader but not a dev, so just ignore me if you like.

In my opinion it is "time" for a new release. Been quite a while since 2.3
But the very big new feature that Raw is, doesn't feel quite ready yet.
MLV has only recently been conceived.

So personally I do not mind waiting many more months for a new release.
I know it is going to be awesome when we finally get it.

dmilligan

Quote from: Des219 on February 01, 2014, 12:49:38 AM
Possibly you do not understand what I am saying.  From the forum messages and my own experience as a software developer, my recommendation was to possibly help move the project forward to more end users in less time.  I am quite impressed by the developers and what they have accomplished.  Not so much by you and your comment.
I understand exactly what you are saying. Why don't you have a look at the code? Maybe you'll see why using classes and try/catch blocks is not some simple solution to the problem (for starters, neither is available in C, which is what ML is written in).

Quote from: Des219 on February 01, 2014, 12:49:38 AM
I am quite impressed by the developers and what they have accomplished.  Not so much by you and your comment.
Do you think I don't know what I'm talking about?

engardeknave

Quote from: Des219 on January 31, 2014, 04:40:07 AM
I am new to ML and have not looked at the code, however I would think a good direction would be to move all of the camera firmware code to class.

I for one think your ideas are just fantastic. Let us know when it's done. Thanks for joining the project!

Midphase

Quote from: romainmenke on February 01, 2014, 02:21:05 AM
But the very big new feature that Raw is, doesn't feel quite ready yet.
MLV has only recently been conceived.

How so?

And by "recently" you mean since last July?


Des219

Quote from: dmilligan on February 01, 2014, 04:58:45 AM
Maybe you'll see why using classes and try/catch blocks is not some simple solution to the problem...
I looked at the links you provided.  I thought I read that ML was written in C++, hence the classes recommendation.  Structs are available and used in the project.  As you know structs were a pre-form of classes.  They were the basis of object oriented programming.  From the provided example the project references menu.h.  Again if menu.h were converted to wrapper functions it could work.

I do not remember saying that it would be a simple solution, just that it would help to advance the project.  Also, I said the code example was C# and I was only demonstrating an example.  I haven't programmed in C++ for 9 years or more and C for 12 years or more so I am rusty with it.  I do know that it is possible to replicate my example in C, because I have done it.  I am sure the devs could accomplish it if they wanted to and agreed with the direction.

engardeknave


Audionut

This is the development section guys, fight with code, not with quips.

Des219

Audionut, thanks.

Dmilligan, your second post was much more helpful than your first worthless comment.  The GUI.c is interesting. I was surprised to see the supported list.

Here is a link to a try/catch option... http://en.wikipedia.org/wiki/Setjmp.h

Audionut

It wasn't an open invitation to antagonize a respected member.

Quote from: Des219 on February 02, 2014, 04:56:10 PM
your first worthless comment.

g3gg0

we need support with programming, not with flaming.
so follow audionuts advise and stop that.
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!

engardeknave

Quote from: Des219 on February 02, 2014, 05:28:36 AMI am sure the devs could accomplish it if they wanted to and agreed with the direction.

Here's the problem with this feature: nobody cares about it. Not even you do. You even seem to have the ability to help implement this, yet you have made no attempt to get it started yourself. You weren't even motivated enough by this idea to look at the code.

Changes to ML don't simply manifest themselves out of nowhere. What you're doing is volunteering hours of someone else's time and energy for a feature in which neither they nor you have any significant interest. It's exactly like proposing some huge government program somebody else has to pay for because you uncritically feel that it might be a good idea.

This is serious point: do you see why it is a problem to propose complicated features on a whim, with no thought as to the cost and benefits of it to the people who actually have to perform the work? Because this is why you have immediately drawn such ire.