Last Monday I got the information from Quest, that TORA is definitely dead ! Til July 2004 Henrik explained in the open discussion forum that this is not truth.
So, what is up now ? What will be the future of TORA ?
I have moved on - there is no activity for TORa, unfortunately.
It's missing all of the nice Oracle specifics, such as the server side monitoring scripts and graphs (which I really liked), as well as a Stored Proc/Function editor (PLSQL Editor). However, it is a completely cross-platform (Java, and FAST believe it or not) SQL and DDL tool.
Bye bye TORa.
This seems to be quite promising piece of software. Although still not as good as Tora, developers are - at least - working on it. Thanks for the tip:)
but aquafold is not under GPL license... and it's not free... so this could not be a solution...
a team should go on tora !...
I'd like to help the projects but I'm just an Oracle DBA without C++ or java knowledge...
Who takes over tora? It's GPL!
Come on dont let it die!
I would spend some time, but I dont have experiences with QT.
For my is not problem Qt and Oracle..
but I working with QT over 1 year
and with Oracle over 5 years
problem is with my free time..
- i realy want to help continuing Tora
In case that there will be some opportunity to continue the developing I would support it
I would like to support tora as well. But due lack of time,
i can not do anything more than fix most annoying
bugs. I would like to add support for dmbs_jobs
and datatase link into tora. But these objects have
sligthly different security granularity in oracle
and it would not be simple to add support for theese.
O.K. who is specifically problem ?
I summarized mostly all patches since July 2004 for tora 22.214.171.124
You can download the summarized patch at http://debianer.org/~mawo/tora/tora-126.96.36.199/tora-188.8.131.52-patch.gz
or for the lazy once the full patched source http://debianer.org/~mawo/tora/tora-184.108.40.206/tora-alpha-220.127.116.11-patched.tar.gz
list of patches:
I got "green light" from the server owner to host tora source code temporary or even for longer time.
Hi, I sent to Hentik a patch to fix a little bug in PL/SQL debugger (909639 PL/SQL Debugger: creating a new procedure).
I don't think it was applied to Tora.
It's produced using diff -u, and I don't remember if it applies cleanly, but I don't have the compiler any more on my Sun.
It's a change to todebug.cpp.
*** todebug.cpp.old Fri Jul 16 18:53:22 2004
--- todebug.cpp Tue Jul 20 18:52:47 2004
*** 2173,2182 ****
--- 2173,2186 ----
toDebugText *text=new toDebugText(Breakpoints,Editors,this);
+ if (!Schema->currentText().isEmpty())
void toDebug::showSource(QListViewItem *item)
is admin of project going to support it anymore or not?
maybe there's someone willing to takeover?
tora is as far best tool for linux so far
hope there're some ppl willing to help
I'd hate to see tORA die.. its been my tool of choice for the last year or so.
I'm willing to help and take over/fork the project if necessary .. my management (I work for a remote dba company) has finally agreed to support me in my efforts so I should be able to spend more time on it.. definitely exciting, since we're committed to keeping it GPL'ed.
I'm excited about it, but I need to know what the proper way of proceeding from here would be, I haven't handled a sf project before.
Also, can we get a show of support for people willing to help - with coding/bugfixing/testing etc..
I've got a support ticket open with SF now asking about getting a copy of the cvs repository for Tora so we don't lose revision history. (Worst case scenario, it can be reconstructed from cvs checkouts.)
As soon as that is done, I think what needs to happen is this:
1) Come up with a new name if we think that is necessary
2) Get an initial list of developers for the project
3) Create the project (I've got several on SF already, so would be happy to take care of this)
4) Add the members
5) Import the old revision history if we get it
6) Merge in the various patches that people are hosting
I'm happy with 'TORA' if we can get it. If not, then lets aim for a generic name since t-ORA(cle) now supports MySQL and Postgres as well. Hopefully others too soon.
Count me in.
Please wait a few days before performing the fork. It just seems like unnecessary work. I have earlier asked if someone was willing to take over administration of the project and no one really stepped forward and said yes I'll take it. Please respond to this message if you are (I'm guessing the poster for this message would definately be one). Also I need to get approval from Quest before this (That's the few days).
I agree, since y'all aren't going to continue it, would solve a lot of trouble to just transfer the project. Obviously copyrights for existing code would remain with Quest, but that doesn't really impact the licensing.
I'll be happy to spearhead the admin for tora since I'm pretty dependent on it currently, and have a number of existing SF projects that I already maintain. (You can contact me externally if you want at firstname.lastname@example.org.)
Main issue to me to get approval from y'all on are:
Continuing to use the name 'tora' or do we need to pick a new name. If that is the case, probably need a new project anyway.
What do you need their permission for? The 'TOra' name?
I'd like to be able to keep the name, but we can choose another one, too. Otherwise, I'm not really sure what we need Quest to do.
Retaining the name of a project when forking is a nice little gray area... Better not to tangle with that unless Quest is ok with it. It sounds like they might be willing based on earlier messages in this thread, let's see what they have to say.