QCubed and QCodo
As you all probably know, Mike Ho updated QCodo website. I'm a big QCubed/QCodo fan and use it heavily.
I haven't found people on IRC. That's probably because I'm in Europe and all of you are sleeping when I'm online and vice versa.
I thought we should discuss, what might happen if Mike Ho really will be more active. I really like what you have done with QCubed and I really would like to help. But as I'm not a core developer, I thought that may-be some of you have a vision about the future? Or we just continue and will see about that in few months (while we know, what really happens to qcodo)?
As it is stated in QCodo forums, for a newcomer (and even for old users) it might be better to have just one Q* framework. Now it might get somewhat confusing if you compare QCodo and QCubed (well, until now it was pretty clear). One is official framework developed by original author. Another is a fork, which was started because the lead original author was absent. Now, may-be Ho is back. Is there a reason for a fork? (I know, we don't know yet about Ho's activity). Or may-be we should state, what is our vision (differenct) compared to QCodo.
This topic is not meant to be offensive in anyway. I'm sorry, if some of my questions is not reasonable and might sound somewhat direct.
(I have been away from qcubed for few months. I've just returned recently. Need to get back on track with new plugin system etc. But I'm working on it.)
Dear Agsel, I'm not core either but I feel like we should not stress this topic too early - we don't know anything yet. :)
Allow Mike some time to sattle content and finish the API for contributions he has hooked to Github.
I realise Mike has worked hard during all this time and feel a lot of respect for that.
He has actually never given up on us and went away completely but has worked on the community requests we gave him on that forum topic some time ago.
->But he did it _his way_, writting it all from scratch with qcodo and not installing other software.
Bugtracker, Wiki, Website, Community, Pluginmanager is all written from scratch and open sourced in github.
Apart from the actual use on the qcodo website, these are medium sized example applications we may have sought after (at least I love to look at nice architectured apps that show the power of a framework directly).
We are on a great way here with qcubed and we have achieved a lot.
It is lots of fun to spend time with you guys.
So let this evolve naturally the next months, let us be open and not block ourselves on either direction.
We simply do not have to decide anything as of now.
And most importantly we are currently on the amazing trip to release 1.1 which is the main focus now and will be a big step forward.
Regards,
tronics
Any discussion of resolving the QCodo/QCubed schism is probably a bit premature until we have seen more of where QCodo is heading, and how the work done on QCubed would fit in. Definitely an interesting development though, it's good to see Mike Ho active again.
Did lots of posting on the qcodo forum today to make this a more lively experience from day one over there too.
I went a little crazy about it because these were many hours.
However Authentification System was completed today, so a lot happened already.
I do believe some action on both sides lead to enhancing visibility and interest from additional developers that may join which is good for any us.
All the best,
tronics
Folks - thanks so much for opening this discussion. We've discussed recent QCodo developments on the core contributors mailing list extensively.
We're most certainly excited about Mike Ho coming out of hibernation and putting out some great code out there. Things like the home-brew bug tracker and forums are all great stuff, and we're particularly impressed by the QPM idea (finally, a reasonable way to create QCodo extensions!).
That said, the main reason why we forked QCubed remains. Mike Ho does not believe in the idea of community ownership of the core codebase. We tried talking to him multiple times about it; sadly, we can't come to an agreement.
At QCubed, we firmly believe in having more than one person responsible for the future of the framework. We know that things happen (weddings, family events, work busyness, etc) and folks who were deeply involved in a project may not have the time to invest any longer. In a case when multiple people own a project, a departure of a single owner is not an issue. You all know what happens when there's only one owner: the framework goes quiet for almost two years.
So merging the QCubed project back into QCodo is out of the question for now.
That said, QCubed and QCodo share lots of code at this point; we've carefully migrated all Mike Ho's 0.4.0 fixes into QCubed 1.0.1 (let us know if we missed something!), and will continue applying relevant QCodo patches in the future. So basically, we'll make sure that QCubed is always a superset of QCodo in terms of functionality.
I'd like to echo everything Alex said. Merging Qcodo and QCubed is out of the question.
My involvement in the past few months has severely dropped off, for several personal reasons. First, our second child arrived. Second, a family member came down with a terminal illness. Third, I've been working very hard to build my company, which has hired a QCubed core contributor, Jon Kirkpatrick. Open Source works that way, I love this project, but for the reasons stated, I've had other things going on.
Yet, progress on QCubed has steadily moved forward. We even had a release! That's impressive in my opinion and is a clear example of the differences between the two projects as they exist.
I have an enormous amount of respect for Mike Ho, as I've stated several times. However, we have different philosophies on how to build the community around the project. That's it. I wish them the best.
Lets do the community building and maintaining our way, but do not overlook the potential when staying in touch with the other codebase:
Think about the following possiblity...
*Both projects next to each other on Github
*Both having the same filefolder layout.
I know we had some reasons why we changed the filestructure but however the power
when this stuff stays the same is sooo much greater.
In my optinion going back the filefolder changes is not so much of a problem.
Our pluginmanager might suffer but better do it now before additional plugins are made and we can never go back.
Advantages:
-> All patches are compatible!
-> We could compare codebases via Github and just merge any tickets.
-> Qcodo Package Manager compatible for Qcubed
-> Qcubed plugins compatible for Qcodo
-> Git is the future and very trendy. We will have a lot of folks jumping on the wagon.
-> Also the applications Mike built for qcodo.com are very cool and could run with qcubed as well. I'm talking about the forum, wiki, comments, package manager.
-> Improved CLI tool working for Qcubed
-> We instantly double our community.
In Github a fork is free and only one click on fork away.
It is much saver then having your own SVN server and very popular now.
This would make each community profiting from each other for a long while.
We did these filefolder changes, but in fact there is 99% of codebase and architecture still shared.
Best Regards,
tronics
I'm with Alex and Mike on this. In my opinion the changes between QCodo and QCubed 1.0.1 are immense, and that is due to the fact of all the help from the community fixing bugs and moving it forward. I see a total of 111 tickets that have either been fixed or looked at from QCubed 1.0 RC1.
There is no way the two could possibly "merge", unless one stopped and went with the other. The only thing that can happen is we keep close together and feed ideas off each other, after all thats what open source is about.
Jon
Yes, regarding tickets we are certainly far ahead of the game!
Our community is going strong no doubt on that too.
It is the underlying architecture that has not changed much, and makes it possible to weigh advantages and disadvantages in these 2 points, that would move ourselves much closer without merging:
* adapt filestructure to be compatible
* adapt version control system to be able to also use the package manager.
That's basically all I'm saying.
Tronics - I'm afraid staying side-by-side is really not an option, as Jon said. Yes, codebases are 99% compatible. Some things, however, were changed significantly enough (plugin manager, installation configurator, etc) that it would take a huge step *backwards* to make us compatible with QCodo.
QCubed plugins will never be compatible with QCodo because we added hooks to the core that QCodo simply does NOT have. This means that installing QCubed plugins will not be possible on QCubed.
That said, I'm all for porting fixes - it really isn't that difficult today.
Github vs SVN is really not an issue. It simply doesn't matter much.
Alex - Sure thing it has to be a compromise, and we won't like to give up anything we have achieved so far.
Close enough as I mean it is not to be understood as full backwards compatibility which I understand will not work.
Close enough is more having the same filefolder layout plus additional files. And being package manager compatibile.
The package manager is one thing that only works with Git for example.
We could easily have a Qcubed compatibility package for Qcodo with all the hooks ;)
The package manager is all about changing core files and packaging examples, other frameworks.
I'm very excited about the provided qcodo.com website source. Especially about the real life 'sample' applications it contains.
This is something we are still lacking. There is useful architecture in there that shows how to build these kind of applications.
Those would be cool to run on qcubed too, which should be not too much of a problem since that is single direction qcodo -> qcubed.
Ok no one knows how many packages will be submitted.
But imagine being possible to use both would help a lot to not loose potential developers that are starting out.
Cheers,
tronics