when is scheduled the next opentk release?
Code can be reviewed by other contributors and not just the Fiddler. Generally when you have more people looking at the same bit of code, you'll find more of it's bugs in a shorter amount of time. If the Fiddler is not thorough with his testing, low quality code can be committed to the server or bugs can be missed. As for the bottleneck, I'm talking about the fact that there are many small patches to the math structs that haven't been committed to the server in over a year and a half, nothing to do with quality.
There are many modifications that would be very helpful if merged with the trunk. For example, I'm currently optimizing the Matrix4 class and have managed to speed up all the methods, some of them 2-3x faster than the SVN trunk. I'm also implementing Matrix3/2. I would imagine that this would be helpful to most people who use OpenTK's math structs. Right now I'm just holding on to this code to finish it and make sure it outputs the same values as the current methods, then eventually submit an issue, but under a DCVS I could be sharing incremental versions of my changes where other people can help with the optimizing and testing, then after it's all done, I request our changes to be merged in to the Fiddler's repository.
Issue tickets still exist under a DCVS, and not all contributions have to be merged in or even shared with other contributors. People make requests for the Fiddler to merge their changes in, project-specific changes won't request to be merged in. If they do, the Fiddler can still choose to deny the request. A DCVS doesn't remove either of these things.
And I've already linked to this, but the Fiddler has already said he wants to move to a DCVS: http://www.opentk.com/blog/1/moving-to-bazaar-part1-planning
I would personally prefer Git, but all I really want is the switch to Bazaar/Launchpad to happen. I've already stated my opinion, I'm not going to clog up this thread any further as arguments over version control software can go on forever.
It's +2 months from the prior release goal, and the last SVN activity I see was on 12/15.
Do you people really think that constant nagging makes things progress faster?
Also if somebody wants to provide fixes there's always the possibility to post diffs against svn trunk, simply to avoid all the religious discussions about whether git is the holy grail or not.
If you read that post in context, you'll see I'm not requesting 1.1 be done faster. I'm requesting an updated ETA for project planning purposes. If the release is on hold indefinitely, that's perfectly understandable (and is what I'll assume if I don't see any update by the end of Feb.)
I do agree that style of repository (distributed or non) does not appear to be the gating issue for this project - progress seems to be gated Fiddler's availability, as he indicates in his own posts. I hope that this changes in the near future, but it seems unlikely.
I have never experienced a collaborative project where "more contributors" meant "higher quality". Never.
If there's a fork of OpenTK in the future called OpenTKExtended then you will know why it was created. It's no ones fault, it's the way to be.
Aha! at last a fateful word "Fork" has sounded...
If somebody deiced to start a fork of OpenTK, I hope it would be for the right reasons, not for political decisions. (FFMpeg vs libAV for example)
But if OpenTK isn't accepting contributions, and the project managers are too busy with AFK things to maintain the package, I think a fork with a goal of eventual repatriation with the original project isn't completely insane. I'm not endorsing or proposing one. Fork is a scary word, but sometimes a necessary one.
If somebody deiced to start a fork of OpenTK, I hope it would be for the right reasons, not for political decisions.
Correct. This happened to Java, like Oracle/Sun JDK and OpenJDK. But I also hate the "divide and conquer" mindset, if it's for the common good then you can name this "Fork" a "Community Branch", not a different repository.
But in any case, in one hand there is OpenTK that is rock-stable and safe as the founders want it, but on the other hand there is OpenTKCommunity that is more experimental and is always gets pressure from the community. The OpenTK project afterwards can merge parts that are proven to be successful.
Just to follow-up, I switched to the dev nightly as of last week, and the CreateContextAttribsARB error that occurred periodically when using a Quadro 4000 has not occurred since the switch. Further, no regressions were found in our automated testing. Nice work! It appears my concerns about pulling a development branch for production were unfounded.
Site design by Stefanos A. Icons courtesy of gnome-colors.