About forking Magic Lantern and the support that can be provided on this forum

[nanomad]

During the last 3 years, the development of Magic Lantern has shifted from an almost single-dev hobby project, into something more collaborative, with several people contributing to the project. We feel that the right development model for Magic Lantern is something similar to the Linux kernel.  A group of core contributors make changes that go directly into the “official” builds, and other users contribute by submitting pull requests.  Inevitably, forks of the project will be created for the purpose of adding features and fixing bugs.  We encourage these forks and recommend forking as the best method to submit patches to the main repository.

Recently, one actively popular fork began moving in a direction dangerously far away from the main repository, by adding experimental patches that weren’t pulled back to the main repository for collaboration.  As a result, these patches were relatively untested on some cameras and could not be confirmed as safe for all models.

Until recently, 3 ports (EOS-M, 6D, and 7D) were maintained almost completely on the Tragic Lantern fork and not in the main repository.  It has become increasingly harder to merge patches from Tragic Lantern into the Magic Lantern repository

We feel that the current situation only serves to create confusion among users, split the community, and duplicate development efforts. This makes merging harder than rewriting these features and fixes from scratch, and clutters the forum with duplicate requests, issues and development discussion.

Therefore, we have decided to drop any form of official support for these kind of forks.

Starting a week from this announcement, we will begin actively enforcing this decision by dissolving support of the Tragic Lantern fork, as well as any other fork, that fails to follow the guidelines presented here.


This decision is based solely on the forking of Magic Lantern, and ensuring that these forks do not interfere with the core values set forth by the Magic Lantern development team.  1%, the maintainer of Tragic Lantern, and other users, are free to fork and do whatever they wish with the project.  This decision should not be considered as a personal attack towards 1%, or other users, who maintain their forks in a manner that is suitable for themselves.  We respect the development by all members, including development that moves away from the direction of Magic Lantern.

However, in the end, only the main repository can be called Magic Lantern and be supported on this website for all of the reasons listed within.


I’m a user, what does this mean for me?
Tragic Lantern usage and discussion will no longer be accepted on this forum. Please continue discussion about the Magic Lantern ports in these threads: 50D, 7D, EOS-M, 6D, 600D.

But, I found a bug! What should I do now?
If you feel you have found a bug, please open a bug report on the Tragic Lantern bug tracker. If, after testing the latest nightly build of Magic Lantern for your camera you find that the bug applies to Magic Lantern too, please open a ticket here.

How can I help smooth the transition?
Users are more than welcome to point out the differences between Tragic Lantern and Magic Lantern on their cameras here, in order to assist developers in knowing exactly what to merge back to mainline.  It is strongly encouraged that users and developers take priority in getting the 3 ports (EOS-M, 6D, and 7D) to a stable state where they can be maintained by Magic Lantern.

It is hoped that this will solve a number of issues, including, getting these ports supported in Magic Lantern, and creating a situation whereby it is easier for fork maintainers to create pull requests.

What about existing threads and posts?
Any remaining threads about Tragic Lantern will be moved to this section. Next week they will be locked out and put in read-only mode

[l_d_allan]

My impression is that people do make monetary donations to the ML project. I have no idea how much this amounts to, if anything.

Would it be possible for the ML project to purchase a 6d for use by one of the core Devs? If so, they wouldn't be proceeding with "blind" development and support.

[Marsu42]

We feel that the right development model for Magic Lantern is something similar to the Linux kernel.

I'd wish for that because this includes a good system of merge window and point releases after bugfixing, the current "rolling release" model imho encourages newbies to use the rather untested nightly as stable and prevents expermiental patches/modules from being merged.

We encourage these forks and recommend forking as the best method to submit patches to the main repository.

... unless you're a core dev, in which case you just create a branch and implicitly hand it down to every other fork out there :-p as when a branch is merged/closed in the ML repo it isn't closed in forked repos :- \

Starting a week from this announcement, we will begin actively enforcing this decision by dissolving support of the Tragic Lantern fork, as well as any other fork, that fails to follow the guidelines presented here.

It's sad it has come to that, but as I wrote numerous times I understand the decision and hope 1% will continue to merge back some TL adaptions as I'm currently using 6D ML and don't want to switch to TL again.

[nanomad]

My impression is that people do make monetary donations to the ML project. I have no idea how much this amounts to, if anything.

Would it be possible for the ML project to purchase a 6d for use by one of the core Devs? If so, they wouldn't be proceeding with "blind" development and support.

I personally feel that 1% work has been ok so far. The issue is, we had a lack of contributions back to the main ML tree which prompted this decision (after long, long thinking and delaying)

I'd wish for that because this includes a good system of merge window and point releases after bugfixing, the current "rolling release" model imho encourages newbies to use the rather untested nightly as stable and prevents expermiental patches/modules from being merged.

Yeah, me too. The real issue is that it's a hobby project for many of us and no one wants to deal with managing "another" release cycle (the ones I'm doing at work are enough). Nothing forbids users from making a team and working toward a stable-ish release. As always, I can provide help and tools if needed. Jus ask nicely

... unless you're a core dev, in which case you just create a branch and implicitly hand it down to every other fork out there :-p as when a branch is merged/closed in the ML repo it isn't closed in forked repos :- \

That's interesting and something I'll have to investigate.

[ayshih]

... unless you're a core dev, in which case you just create a branch and implicitly hand it down to every other fork out there :-p as when a branch is merged/closed in the ML repo it isn't closed in forked repos :- \

That's weird; I'm pretty sure that branch closures are logged as commits in Mercurial, so closures on the main repo should propagate to forks, but maybe it depends on how you are merging in updates from the main repo.  I believe I've only closed branches in my fork when they have been merged in the main repo but not yet actually closed there.

Fortunately, assuming you keep a clean unified (which I'd highly recommend), Bitbucket does not consider such branches as "active" and will hide such branches by default.

[Audionut]

That's weird; I'm pretty sure that branch closures are logged as commits in Mercurial, so closures on the main repo should propagate to forks,

They should do.  They do here.


And you can close your own branches easily.

[dmilligan]

They should do.  They do here.

Nope. They don't.

Branches closures don't propagate to clones (forks) via the bitbucket interface. I think this is b/c the "sync" button in bitbucket only pulls changes on the main branch. Commits from branches that have been merged into the main obviously get propagated in (so new branches are created), but since 'close a branch' is a commit to that specific branch, the change isn't pulled over. It's quite annoying to have to be constantly closing a bunch of branches each time I 'sync' my fork, which currently I have to do.

Perhaps somebody (*cough* me) should submit a bug report to bitbucket. Really 'sync' should pull changes from all branches, or at least there should be an option too.

The work around is to pull changes to your local repo, directly from the main repo (add hudson/magic-lantern as a remote) and then push those changes to your bitbucket fork, thus circumventing the 'sync' button in bitbucket.

[ayshih]

The work around is to pull changes to your local repo, directly from the main repo (add hudson/magic-lantern as a remote) and then push those changes to your bitbucket fork, thus circumventing the 'sync' button in bitbucket.

Ah, okay, I do in fact pull from the main repo as a remote.  I wasn't clear what Bitbucket's "sync" actually did!  What you call a workaround is what I would call the proper way to work with Mercurial.

[Audionut]

I think this is b/c the "sync" button in bitbucket only pulls changes on the main branch.

This is the reason why I moved to controlling my repository locally.

Since you have to work locally to actually create a build, I would exactly call local management of your repository, a work around.
Why else would you need to control your repository online, except to keep a backup, and create pull requests?

[dmilligan]

b/c I have multiple computers that I work on (and thus multiple clones of my fork). I like for everything to flow one direction.

[Audionut]

Heh, I have enough trouble trying to maintain 1 local copy.

Here you go 
https://confluence.atlassian.com/display/BITBUCKET/Forking+a+Repository

See compare, under Using the Bitbucket GUI to sync your fork to the original repo.

Note:  You have to create the branch in you repository first.  Then you can merge a branch from mainline into the branch in your own repository.  You can only merge to an existing branch, I didn't see a way to create the branch while merging.

[gary2013]

I hope the major forum changes that were announced do not impede any development for the M, 6D and 7D. Splitting the community is not good. I don't know why such claims are made to scare people away from using TL when I have used the daily builds on my M since last July without having any problems. Nor have I seen anyone reporting any terrible problems from using TL. I am not taking sides and I have no disrespect for anyone here at ML.

[a1ex]

Who started the community split in the first place? Who took ML code, tweaked it a little and refused to give the changes back? Who took over the ML development threads and left the main codebase outdated?

FYI, more than 90% of what you are running is Magic Lantern code, and more than 70% of it was written with my own hands.

Please study the commit history and give credit where credit is due.

[gary2013]

Who started the community split in the first place? Who took ML code, tweaked it a little and refused to give the changes back? Who took over the ML development threads and left the main codebase outdated?

FYI, more than 90% of what you are running is Magic Lantern code, and more than 70% of it was written with my own hands.

Please study the commit history and give credit where credit is due.

I was not aware of a commit history. I am not taking sides and I have respect for everyone. I will edit my post. My concern is to not split the community. We all need each other. it would probably be good to also hear from 1% and to try and work things out. I know you all have tried in the past and it's obvious it will now take some more effort. We need everyone to work together.

I hope you, Alex, and some others realize that the rest of us out here do not know what is going on behind the scenes or the the real history, such as the development for the M and some other cameras.

[a1ex]

That's why we are trying to undo the community split, so everybody is invited to switch to Magic Lantern (where most of the innovation happens anyway). If there are still differences between ML and TL, these should be backported (but for EOS-M I can help mostly with advice, because I don't use one myself).

If any of you still wants to continue with the community split, you are free to do that on some other website, not here.

[gary2013]

Who took ML code, tweaked it a little and refused to give the changes back?

I agree. Why would anyone not share and give back to the parent? Can you take what is current in TL and see what is there and apply it to ML? I am sorry I am not a dev and understand the workings of it all. How will it all end up? I mean, will ML lack what TL has done or will it just take longer for ML to develop what was there? Or, will ML just not try to progress in those areas for certain cameras? What does TL have that ML does not have right now for say, my camera, the M? From what I have seen, on ML I do not see video hacks and RAW recording, just MLV. Probably more, I don't know.

[gary2013]

That's why we are trying to undo the community split, so everybody is invited to switch to Magic Lantern (where most of the innovation happens anyway). If there are still differences between ML and TL, these should be backported (but for EOS-M I can help mostly with advice, because I don't use one myself).

If any of you still wants to continue with the community split, you are free to do that on some other website, not here.

Is 1% the only dev who has an M? I remember way back that Max was willing to donate his M camera to ML to use but no one accepted his offer. I think he said he had two M cameras.

[a1ex]

Can you take what is current in TL and see what is there and apply it to ML?

Yes, the thread I've linked is pretty much about that, but this process is very difficult without cooperation from 1%. In the past, all of us ML devs have attempted to port many of the TL changes blindly (without a camera to test on) and we have also tried to ask for the help of other developers (with only partial success; the progress was not as fast as we would like, and these ports are not yet as robust as on 5D3 or 5D2, for example).

Fortunately, he did share some of his changes lately (mostly from 7D/6D). But this should be the normal development flow, just like all other code contributions to ML, not "backflow" as 1% calls it.

Nanomad also has an EOS-M and he did some good progress with TL backporting. But, since ML is a spare-time project for all of us, progress is not always as fast as we would like, so we prefer not to waste further development resources on private forks.

If you are not familiar with the how open source contributions should work, you can get an idea here:
http://programmers.stackexchange.com/questions/112458/forking-an-open-source-project-nicely
http://tirania.org/blog/archive/2010/Dec-31.html
http://jamesdixon.wordpress.com/forking-protocol-why-when-and-how-to-fork-an-open-source-project/
http://www.kaizou.org/2013/04/three-golden-rules-open-source/

[gary2013]

Yes, the thread I've linked is pretty much about that, but this process is very difficult without cooperation from 1%. In the past, all of us ML devs have attempted to port many of the TL changes blindly (without a camera to test on) and we have also tried to ask for the help of other developers (with only partial success; the progress was not as fast as we would like, and these ports are not yet as robust as on 5D3 or 5D2, for example).

Fortunately, he did share some of his changes lately (mostly from 7D/6D). But this should be the normal development flow, just like all other code contributions to ML, not "backflow" as 1% calls it.

Nanomad also has an EOS-M and he did some good progress with TL backporting. But, since ML is a spare-time project for all of us, progress is not always as fast as we would like, so we prefer not to waste further development resources on private forks.

If you are not familiar with the how open source contributions should work, you can get an idea here:
http://programmers.stackexchange.com/questions/112458/forking-an-open-source-project-nicely
http://tirania.org/blog/archive/2010/Dec-31.html
http://jamesdixon.wordpress.com/forking-protocol-why-when-and-how-to-fork-an-open-source-project/
http://www.kaizou.org/2013/04/three-golden-rules-open-source/

Alex,

Thank you for explaining these things. Hopefully, 1% will respond and tell us things from his point of view. Maybe it can all be worked out for the best.

Best regards,
Gary

[Audionut]

For clarity, the forking mentioned in the articles shared by a1ex, refer specifically to forks that become direct competition.

Taking the original codebase, and actively maintaining a separate codebase, in public, and without pushing the changes back to the original development project.

Open source is not a competition, it is collaboration.

Forking a project, for the purpose of actively developing your own features and fixes, and pushing those changes back into the original development project, is good etiquette, and helps to further improve the project.

[1%]

I don't really want to argue about this as its not helping anyone. My sole reason for having a separate code base was that certain things just don't get accepted into the main repository or are deemed as too something, be it "dangerous", useless, not spaced properly, not important enough, etc.

The kickoff was movie remap on 600D. It was the only camera I had, the modes are on opposite sides of the dial. The feature had been working for a long while and then it caused problems on 60D and was pulled from 600D. It really killed usability. People complained but yeah, what can they do. So I thought since I'm already compiling this to get the latest changes why don't I just put it back, I'm willing to take the risk. I posted an autoexec in the downloads of the repo in case anyone wanted to use it for themselves. Nobody really cared.

Then I wanted audio controls and better video so I worked on those, from knowing nothing to knowing a little. Tested and tried, got some help and we got something going. Still nobody cared so much. I saw other people try to code things, they languished in the pull requests section but I wanted to try it that day so I pulled the changes in and tried them. Sometimes it had to be done by hand + fixed. It was pretty addicting and I learned a bunch on coding and reverse engineering. I was having fun.

So at least a year or so goes by and there are many refactors, yada yada. Things become incompatible, there are major changes. Manual merges I have to spend hours on, etc. I figure its my problem oh well. I'm not the best coder or the neatest. I try to help reverse engineer and figure things out. Sometimes it gets into the main repo, sometimes not. More people are using the 600D builds. The video stuff is deemed useless/dangerous/etc.

Then I end up with a few more camera bodies. I see how hard it is to support this many. I find many things that just needed a little fixing and share my results. Some of it is ported back, some of it is not. At this point I don't know how to work pull requests yet so coutts ports the 6D stuff back to main and the nightly works. Some stuff gets turned off but hey, main is supposed to be stable. All is well, right?

Guess not, as more people just go for my downloads this drama develops. A1ex views it as competition and as his time isn't infinite doesn't want to go through and pull out the good code, or use stuff the doesn't agree with (esp. blindly). I'm having trouble at this point maintaining + testing 5 cameras, it takes a long time. I can only shoot with one at a time, I'm a shitty coder.  Users come in with questions and unreasonable demands about ML and TL and now people are downloading my builds instead of his so its even more of a thankless job. Most of the main code is his and naturally he gets pissed off.

So I learn how to push stuff back and at the same time ask users to help. EOSM gets ported back. After all, neither of us here can do all of it and still have any kind of life. The only thanks is really having happy users and maybe getting cool stuff happening in your own projects/uses. Yea, speaking of that, I have drama here. I pretty likely have to sell + move to another state or get involved in a legal battle where I win but really gain nothing besides more expenses and the same shitty life. I've been doing contract work for all the time I've been working on ML (see where all that free time came from?). But yes, all, this is not your problem. you just want camera software. On top of that the implication FEELS like throw out your work and cease to exist. I'm probably going to be late because I sat and typed this out and maybe it got a little shitily written towards the end.

Anyways, these are/were my motivations. I just don't feel good about any of the hostility or schism from what essentially is my first real coding project and mostly a thankless labor of love. At the same time I don't like letting ML down and pissing off A1ex to the point he wants to quit. So everything seems like its burning and I feel like shit and there you go.

[gary2013]

1%, I have always been happy with what you have done. As I have said a few times now, I have never had any problems with your TL on my M using every daily build since last July. I know how you feel. I have "been there and done that" a few times in my life. Thank you very much for all your hard work.

Best regards,
Gary

[Audionut]

A developers resume, is his code.

As projects extend towards large scale development, naturally, standards are raised.  With increased standards, comes improved coding abilities.  After all, Magic Lantern is a development project. 

This is a benefit to the greater community.  Both the developers, who increase their abilities, and end users, who get the fruits of that labor.

1%, your efforts have never been unrecognized, or unappreciated (that I am aware of).  However, the core development team has clearly set a constitution in the best interests of the development project, and surely you can understand, that if your own personal objectives do not fit within this constitution, for whatever reason, then inevitably, actions needed to be taken in the best interest of the Magic Lantern development project.

As I think I have mentioned previously, you are clearly having some personal issues.  This is fine, we all have them.  This is not an attack on you personally, in any shape or form.  Perhaps though, you might be better served by taking actions necessary to the well being of yourself.  Maybe you already do that, I don't know.  I do however, know that, you sir, as a person, are significantly more important then this development project.

I wish you all the best, in whatever direction you take.

[gary2013]

1%, I sent you a PM. Please let me know when you get it.
Thank you, Gary2013.

[cpreston]

I also want to thank !% for all of the work he did.  I have both a 6D and an EOSM along with a 60D and a C100.  Without ML/TL, I find the Canon DSLR's to be nearly useless for video work.  I absolutely love using ML and on my 60D and can't thank a1ex and the rest of the early team enough.  I consider it a reliable B-Cam for my C100.  Sometimes, though, the 6D or EOSM fit my needs more due to size or lowlight, and I wouldn't want to use those at all without the work that 1% put in.  Thank you.

 Also, I'm glad that this change to support for TL/ML is being made as I hope it will ultimately lead to more stable builds for all of the current Canons.  For those of us who are either new to ML and looking for reliable video camera and intervalometer features, or who use DSLR's on paying gigs, anything that improves stability and consistency is greatly appreciated.  Again, thank you to the entire team for basically creating a fully featured video and photo camera out of a consumer oriented camera.