t00fri wrote: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: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.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.
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 doesn't seem to me that Trac would be any worse than our current system of development in this regard. Having tickets for various parts of the texture work would help us track who is assigned to tasks, and the timeline view makes it clear at a glance what changes have actually been committed. I think the improved visibility would benefit the review process.
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?
This is a concern of mine as well; I don't want to be deluged by useless or nagging emails. Currently, I get checkin notifications from CVS and updates whenever a bug has been changed. With the current level of activity on Celestia, this isn't a problem for me, but should the project grow, I would want to be able to filter by branch.
And speaking of branches . . . It would be a *very* good thing to have a stable branch and a new feature development branch (or possibly a branch for each major new feature.) It's great to be able to use source control while developing a new feature without destabilizing the release branch. And when multiple developers are working on a major new feature, it's more than great, it's essential. However, Trac is not required for branching; moving from CVS to Subversion is all that's required.
--Chris
