Celestia Forums

Hi all,

As I can see on that forum, there are few problems with the Celestia development team. Many proposals such as wikis have been made.

I wrote something about Trac and Subversion on an other topic, but I'd like to make it easy to try.

So, I started a free hosted Trac page for Celestia. Since this post is a proposal, this Trac page is only a demo. I don't want to change the way the dev team is working. My aim is just to present a tool that fit your requirement .

So, just go to this address :
http://trac2.assembla.com/celestia-test
to see what I'm talking about.

Anonymous user can only see ticket and browse source.
Register users can edit or create tickets and wiki.
You can login with celestiaDev1 or celestiaDev2, both with celestia as password.

Those accounts can also commit with subversion. Try TortoiseSVN if you want to do that on Windows.

For now, I got all the admin permissions, but I can grant any account for testing.

Please note the very strong link between tickets and svn commits.

Hope you'll enjoy.

Mathieu

Mathieu,

Trac looks very promising--the tighter coupling of version control, bug tracking, and feature development is an improvement of what we have now. The big question that I have is how this integrates with SourceForge? Am I mistaken or would using Trac require moving from SourceForge?

Moving from CVS to Subversion is definitely something I want to do after 1.5.0, regardless of other decisions.

--Chris

chris wrote:Mathieu,

Trac looks very promising--the tighter coupling of version control, bug tracking, and feature development is an improvement of what we have now. The big question that I have is how this integrates with SourceForge? Am I mistaken or would using Trac require moving from SourceForge?

Moving from CVS to Subversion is definitely something I want to do after 1.5.0, regardless of other decisions.

--Chris

This is all very nice, but it just SCREWED my Vista Firefox display when I
tried to logout.

Just FYI...

By the way, Selden has the final version of the start.cel for you.
As always, THANKS.

BobHegwood wrote:This is all very nice, but it just SCREWED my Vista Firefox display when I tried to logout.

Sorry about that BobHegWood.

I googled "trac free hosting" quickly to present this tool. I don't know anything about Assembla, including its stability.

Chris, I'm looking if the code has to be moved from SF.

Mathieu

Further elucidation...

I could NOT logout no matter what I did. Again, just FYI... Could not view
my first Firefox tab, could do nothing but close Firefox.

Bob wrote:By the way, Selden has the final version of the start.cel for you.

Do you mean you want me to forward it to Chris?
Sorry, I must have overlooked that.

selden wrote:

Bob wrote:By the way, Selden has the final version of the start.cel for you.

Do you mean you want me to forward it to Chris?
Sorry, I must have overlooked that.

Well, I just figured that if YOU were happy with it, then it was finished.
It now works well on my machine, and it worked hardly at all prior to
my uneducated machinations.

Bob,

no sweat. I've forwarded it.

Please stay on the focus of my post.

So, I'd like to have a word about TRAC from those who proposed or did some development.

I got these IDs :

* hank
* cham
* el christou
* yeus
* rassilon
* chris
* toofri
* phoenix
* selden
* dirkpitt
* rthorvald
* hungry4info
* bobhegwood
* fenerit
* scaddenp

Sorry if I forgot someone.

I can help, but I need your opinion.

Mathieu (Spacebel/CNES)

The official developers are listed in SF.
In alphabetical order:

• Alex Burton alexibu Developer
• Vincent Gian vincent_gian Developer
• Don Goyette dgoyette Support Manager
• Grant Hutchison granthutchison Developer, Author
• Bob Ippolito etrepum Developer, Author
• Da-Woon Jung dirkpitt2050 Developer, Author
• Chris Laurel cjlaurel Project Admin, Author
• Hank Ramsey hramsey Developer , Author
• Harald Schmidt harry312 Developer
• Dr. Fridger Schrempp t00fri Developer, Author
• Pat Suwalski suwalski Developer, Author
• Christophe Teyssier christey Developer, Author
• Toti toti1258 Developer, Author
• Clint Weisbrod cweisbrod Developer, Author

A number of them has not been active recently.

Bye Fridger

Thank you for this list t00fri.

I'll check who still active in SF and forum.

Mathieu

From my list, you should include all Celestia co-Authors, apart from Chris Weisbrod and Bob Ippolito. Moreover, of course, Vincent Gian.

Bye Fridger

mjoubert wrote:Thank you for this list t00fri.

I'll check who still active in SF and forum.

Mathieu

As far as I know, Don Goyette is dead. I have e-mailed him, tried to get
him on the phone, etc. No luck, and sad 'cause he was/is a good friend.

BobHegwood wrote:

mjoubert wrote:Thank you for this list t00fri.

I'll check who still active in SF and forum.

Mathieu

As far as I know, Don Goyette is dead. I have e-mailed him, tried to get
him on the phone, etc. No luck, and sad 'cause he was/is a good friend.

Bob,

fortunately, you seem to be not right here. See my Purgatory thread
http://www.celestiaproject.net/forum/viewtopic.php?t=10441
and notably the end!

Cheers,
Fridger

Appreciate the references Fridger... I really did try to get to him though, and
had NO luck whatsoever. Of course, he could be in the hospital now too.



At any rate, thanks.

Fridger,

as far as you still here and alive, I'd like to know what you think of the use of TRAC and Subversion after 1.5.

Mathieu

mjoubert wrote:Fridger,

as far as you still here and alive, I'd like to know what you think of the use of TRAC and Subversion after 1.5.

Mathieu

Mathieu,

I am a bit surprised about the first half of your above sentence... Being one of the most longstanding active developers besides Chris, there has never been a statement from my side that I will quit Celestia development. I am just involved in some other projects as well, like Chris is also involved in other projects, I suppose.

And I was upset about the long indefinite dev stagnation without being informed whatsoever...

As to TRAC and Subversion after 1.5.0, I know too few details about TRAC really for making a competent statement at this time. First of all, we must know whether it is compatible with SF. There are certainly a number of attractive features as Chris already noticed.

What does not appeal to me in the context of a volunteering venture like Celestia is the apparently tight ticket philosophy with attached deadlines. Also for my personal taste this all looks too "impersonal"

It looks a bit like the ideal system for professional developers whose services get paid by the hour . Not quite my glass of beer as a scientist ...

On the other hand, if we go for such a tighter AND enlarged dev framework, it seems the far better solution compared to Hank's "open" Wiki initiative.

Nevertheless, there are first of all a number of further obvious questions.

Since Celestia development involves complex astrophysics/astromechanics beyond mere coding tasks, the clarification of physics issues AND code reviewing are BOTH essential before core code is committed. Given our quite compact group of active devs in the past, these two requirements could mostly be fulfilled in an informal manner.

As soon as one contemplates a much enlarged group including lots of "pseudo"-developers, mostly with little or no proven C++ code reliability, the aspect of reviewing code becomes an enormous increase in work load for the "peers". There are simply NOT enough experienced people in sight with BOTH solid knowledge in C++ coding AND in astrophysics.

But also beyond pure coding, I can see problems with a group of volunteers without specific know-how. Let's take e.g. the overdue task of producing (at last) an official pack of high-quality, hires textures for Celestia. Further problems I can see with the scientifically correct way we want to see Celestia's data base being handled AND documented. For quite a number of Celestia users it's all fine, as long as things LOOK nice! So it is a quite non-trivial task to assert the desired high scientific-level standards from the onset in case of such work-sharing among a large group of untrained helpers.

In a more familiar dev atmosphere, one might more easily take such facts (i.e. personal abilities) into account, by only assigning adequate tasks or in form of small collaborative tasks together with more experienced devs. But in a much more anonymous "ticket" system it is not obvious at all.

I am sure you have some solid answers to such worries.

Bye Fridger

t00fri wrote:I am a bit surprised about the first half of your above sentence...

Fridger,

That was only a link to previous posts about dead people : I wanted to say that I'd like to talk about FUTURE work with PRESENT persons. I want to help the project with this topic by proposing new working methods, I don't want this topic to become a memorial subject.

About TRAC now. That was a mistake to present deadlines. You are not obliged to set a date for each milestone (see the example http://trac2.assembla.com/celestia-test/roadmap, no date are set). TRAC is using milestones to group tickets. This problem has to be solved for the 1.5.0 release so it is linked to the 1.5.0 milestone. Than, you can see easily what you have to do before the 1.5.0 release. If a ticket cannot be solve, you can move it to 1.5.1.

More difficult or extra features can be set to 2.0. If we had TRAC right now, we can see what we have to do to prepare release. No date involved. See TRAC's TRAC as an example (http://trac.edgewall.org/roadmap).

Reviewing code : yes, difficult scientific section of code should be reviewed by people who knows about that (i.e. you). Two ways : people can make branches. Branches are copy of the whole source code where you can try new features that make the project unstable. Once it's done and verify, you merge. Branches can commit, revert, link to ticket etc.

Another positive point is how easy it's to see difference between to source code, relatively to a ticket (see this ticket http://trac.edgewall.org/ticket/5295 and this revision http://trac.edgewall.org/changeset/4242). I think this can help you to verify what people did with source code.

For your textures example, I'm not sure I understand. I understand that you want to generate two different package, like one with real world compliant data and one with "beautiful" textures. This can be handle by introducing package generative scripts. It is even recommanded to make the release process easier.

Anonymous tickets. TRAC administration can provide an entry point for anonymous posting, and a more complete system for devs. So, once the ticket is written by a Celestia users in a special component (like bugs or users), devs can attribute the ticket to the one that can do this work. None of ticket properties are definitive, you can even not attribute a ticket.

Mathieu

Mathieu,

thanks for your explanations and examples. I got to let them sink in a bit...

As to my above hires texture pack example, you misunderstood it completely:

For your textures example, I'm not sure I understand. I understand that you want to generate two different package, like one with real world compliant data and one with "beautiful" textures. This can be handle by introducing package generative scripts. It is even recommanded to make the release process easier.

Let me just try and explain a bit better below. However, since the specifics of this subject are only marginally related to TRAC, let me not expand further on this issue here.

If we release an OFFICIAL Celestia hires texture pack (which we really should do), then it should be of scientific and high graphics standards. The former requirement means also using only proper published image material along with a documentation of the sources and ALL major image manipulations performed. It also requires a considerable familiarity with reprojection software and the careful use of data about the viewing parameters of a given photographic image (distance from bodies and angles,...). Any mistakes here will lead to false cylindrical maps i.e distortions.

So if such work is shared among people without proven image manipulation expertise and without basic training in scientific working methods, there are considerable chances for problems that are hard to discover and/or repair later, after submission of the work for peer-review.

So again the question arises, how to fit in a "mixed competence" group of texture contributors within a TRAC framework...

It was also not clear to me, from your explanations, among which developers in a group the mails related to a given ticket are supposed to circulate!? Will everyone be on the list for everything? That would be prone of generation of lots of "hot air" mails... How are the corresponding restrictions handled and how flexible is the system there?

Bye Fridger

Fridger,

I don't know a lot about email notifications since I'm working in a local area. People often check the timeline (http://trac.edgewall.org/timeline), to see what happened. With Assembla, you can set a daily notification by email.

It's also possible to create custom TRAC report for the "view ticket" tab : there you can display what you are interested in only.

Mathieu