avc81's picture

Opentk 1.1

when is scheduled the next opentk release?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
blackbee's picture

Nightly builds are being released. But there is no changelog in any of them. Well work is in progress and that is what counts.

golkeeper's picture

+1 to Robmaster post. Fiddler, please move OpenTK to github/bitbucket. Or at leasr explain please why you don't do it.
There are peoples that have ideas how to improve opentk and how to fix its bugs. Moving to DVCS makes them able to contribute in own branches and exchange commits even if you have no time to merge their changes with your ones.

AFAIK last news about new versoion was that you plan to release beta in november and last commit was posted at Dec 15. No updates?

Jase's picture

The other day I noticed that OpenTK was actually already on Github, under Mono: https://github.com/mono/opentk

Though the note at the top of the project explains why: "This is not the main repository, just a temporary import to allow Mono developers to make changes to this module"

Most recent change that I can see was on December 7th 2011, so it's behind the main SVN version by a little bit.

thorrablot's picture

Fiddler - Is there any update on the OpenTK 1.1 planned release?

It's +2 months from the prior release goal, and the last SVN activity I see was on 12/15. There are still 18 items showing up in the default issues list, although it looks like a number of these are old/not assigned.

There are bug-fixes in this release that fix issues when running production-level applications on the latest NVidia Quadro boards and drivers (CreateContextAttribsARB errors.) I'd prefer to pick these up in a stable release instead of using a nightly build, however if it is likely to be another 2+ months before this happens, I'll go that route.

flopoloco's picture

Why not provide a GIT repo in sourceforge?

Scribus also uses GIT as well as an SVN repos, it's the fastest way let the community commit fixes asap.


c2woody's picture

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.

Robmaister's picture

There are some patches from several months ago that haven't been commited yet, despite being fairly straightforward additions to the math structs. Switching to a DCVS and a host centered on being collaborative (github/bitbucket) will allow people to aggregate all the old patches (as well as several new ones) and test them before sending a pull request to Fiddler.

The process of integrating people's changes would be a few mouse clicks and maybe looking over the diffs/running a test or two. The best part of it is that contributors can share their changes among themselves in the same way, making collaboration and testing much easier.

The current bottleneck is that we are relying on the Fiddler to maintain the version of the source code we all work off, this would effectively remove that bottleneck and increase the quality of patches. Contributors can collaboratively work on the bigger features/issues separately in the time that the Fiddler can't, allowing the project to progress more quickly. According to a blog post from over a year ago, the Fiddler supports this idea. He complains of two things with git:

1) Steep learning curve. Things have come a long way since a year ago. There are several online tutorials for git, sites like Github provide step-by-step instructions for everything you have to do, and there are now several nice GUIs - mainly TortoiseGit on Windows, which have come a long way since a year ago. Github holding your hand through the entire process makes the learning curve way less steep.

2) git-svn takes forever. I tried to run git-svn straight from SourceForge, and connecting to the servers for each commit took most of the time, so I mirrored the server on my computer and converted OpenTK to git that way. It still took several hours to convert to a git repository with full history (3,121 commits) but now I've already done it. It's 82.9MB and compresses down to 31.4MB as a zip. I can easily upload this to a file sharing site or use a better compression algorithm and maybe be able to just send it as an email attachment (Gmail's maximum is 25MB last I checked). Once we've moved to another system there's no reason to use git-svn again. This wouldn't be an issue.

Github has it's own issue tracking system that integrates very well with the rest of the site.

Regardless of whether we use git or not, I think switching to any DCVS would really help OpenTK.

c2woody's picture

Since he obviously doesn't have the time at the moment that all is just theory, just because "pull requests" may be easier than "applying patches" doesn't mean he can afford the time to actually check things out. But honestly if you are really interested in keeping your local tree up to date you can easily apply these few patches either way on your own, and maybe in half a year or whenever The Fiddler finds time again to be more active things will progress more smooth again. But all the whining is absolutely not helpful.

And yes git has several drawbacks as well when compared to other DVCS systems so please don't put the "everything must be git" discussions on these forums here.

Robmaister's picture

I'm not saying "everything must be git" - the first two sentences and last sentence of my post say that I'd just like any DCVS, as it becomes much easier to share changes than passing around patches in the form of diffs.

I'd be perfectly fine with the Fiddler going through with the switch to Bazaar/Launchpad he was planning a year ago, I was just suggesting github/bitbucket as an alternative to Launchpad and providing solutions to the two issues he considered "deal-breaking deficiencies" with git.

mOfl's picture
Robmaister wrote:

this would effectively remove that bottleneck and increase the quality of patches

Can you give me an example where this ever was the case? Without rating you guys' programming qualities, I have never experienced a collaborative project where "more contributors" meant "higher quality". Never. It is quite easy to add fixes or modifications to OpenTK yourself with a local source copy, there is often no need to share these modifications with others because they are project-dependent. I doubt that all contributions of everybody would be valuable for the OpenTK project as such. Having issue tickets and centralized code control of an experienced programmer is not a "bottleneck", but quality assurance.

If there is a chance to vote for or against a GIT repository where everyone can contribute, I vote against. Twice, also with my fake account which I will make.