Bugtracker for the project - ryzom.org forum archive

An archived topic, merged from 6 captures made between 12 July 2007 and 7 November 2007. ryzom.org · Forum index · All captures

Author

Message

< Ryzom.org General - English ~ Bugtracker for the project

Xavier Antoviaque

Posted: Wed Dec 20, 2006 1:11 am

Joined: 15 Nov 2006 Posts: 390

Hello,

I've just installed a bugtracker for ryzom.org, at the followinf URL:

http://www.ryzom.org/bugzilla/

Feel free to play with it and even use it for real.

_________________
Xavier.

yster

Posted: Wed Dec 20, 2006 9:26 am

Joined: 20 Dec 2006 Posts: 2 Location: Minneapolis, MN - USA

Hi there--

Just making sure you're aware of TRAC, which integrates itself with SVN if that's a route you were planning to or want to entertain:

http://trac.edgewall.org/

I've found it a bit more intuitive than bugzilla for many things, though bugz is still my familiar ground. It's worth a look.

Mostly I'm just tossing it out there in the event that you do think TRAC is appealing before the Bugz database gets overly populated! :)

Agone

Posted: Wed Dec 20, 2006 9:32 am

Joined: 29 Nov 2006 Posts: 181 Location: près de Lyon

Kervala also wrote about TRAC on the french forum

imho TRAC seems more adapted to our project than Bugzilla

_________________
--Agone--

jason.stover

Posted: Wed Dec 20, 2006 9:48 am

Joined: 01 Dec 2006 Posts: 5

Agone wrote:

Kervala also wrote about TRAC on the french forum

imho TRAC seems more adapted to our project than Bugzilla

Trac is all nice and good *if* you have the code in SVN. Since the code is most probably currently in CVS, and from the little bit of testing I've done on converting a large CVS tree (over 10 gig; don't know how big Ryzom's is) to SVN (full logs, etc...), it just didn't work that good. [1]

If, at a point, it's decided that a new branch for the .org should be created, I'd say leave the current CVS as the archive and import into a new SVN repo, then setup a trac system... Of course, if ya know python well enough to write a CVS hook for trac to use.... ;)

Another issue with trac, may have just been the setup I had (can't remember off the top my head), the accounts were based upon an 'htaccess' system. Also, any rights for any accounts had to be put in for an account manually (the trac-admin util).

-J

[1] - This was with an older version of SVN. The newer version may be better.

Xavier Antoviaque

Posted: Wed Dec 20, 2006 10:00 am

Joined: 15 Nov 2006 Posts: 390

jason.stover wrote:

Yup, same experience here... Currently I've setup the bugtracker just to have one. We can always give it more thinking later on, when we start settling everything up.

_________________
Xavier.

Kervala

Posted: Wed Dec 20, 2006 10:34 am

Joined: 24 Nov 2006 Posts: 210

It exists a lot of plugins for Trac including an account manager :)

But I think also it's too early to propose a complete project management system :)

If we migrate to SVN + Trac, we will be able to convert CVS into SVN and Bugzilla tickets to Trac ones :)

_________________
Cédric OCHS / Kervala / Xiombarg

Jetto

Posted: Wed Dec 20, 2006 10:53 am

Joined: 01 Dec 2006 Posts: 59 Location: France

Are you sure we will stick on SVN ?

I really dislike this tool because of traceability lose between change in trunk and branch. When you do change in branch if you look in the change done to this file from an other branch you won't see these changes. This the same for label.

Second this is a centralized tool It would be better to work in decentralized one.

I think Git would be more interesting.

Kervala

Posted: Wed Dec 20, 2006 10:57 am

Joined: 24 Nov 2006 Posts: 210

I just proposed Trac because I'm using it, but I think our project leaders would choose themself the tools they want to use :)

_________________
Cédric OCHS / Kervala / Xiombarg

Jetto

Posted: Wed Dec 20, 2006 11:30 am

Joined: 01 Dec 2006 Posts: 59 Location: France

maybe trac + svn > git - Linus :?:

Aprak

Posted: Wed Dec 20, 2006 12:57 pm

Joined: 02 Dec 2006 Posts: 60 Location: Stockholm, Sweden

This is a rather important and crucial decision to get right.

However, AFAIK NeL (and Ryzom?) use CVS today and changing a SCM must be held against benefits/risks and priorities (do we even need to change?).

If we lack a good tracker fine, lets put one up. Can we make that choice non-dependant of what ever SCM we'll use, even better.

Personally I really don't have any preferences and I'll be happy to use whatever the community comes up with. Two thoughts that I believe are relevant though:

1) When making a choice, look at the project's that use the ones in question - and include that in the discussion. Always throw an eye on what "others" do (and why), it saves a lot of time and research. This approach applies not only to SCM's btw.

2) If someone knows of any good reading that's comparing or discussing this issue in a objective manner, please post them here. We don't know each other yet, so what each of us say in regard to experience's is really hard to judge. Perhaps somebody is an SCM expert that's taken part in several of the tools development, perhaps somebody is a noob that just had an urge to post (no one mentioned, and no one should feel targeted, I'm honestly just saying this strictly objectively).

To round this topic off a bit, and in regard to the big projects out there:

- Many GNU project's seem to move towards SVN. GCC did last summer, and I'd expect others to follow shortly. IMO GNU is always a good reference when it comes to choices. Those people aren't stupid and I think a lot of thought has been made before changing the SCM for a colossus like GCC.

- The linux kernel community (note *kernel*, not the whole system) seems to have chosen another path. They're using Git, and it would be really interesting to investigate their reasons. Two things differ between the linux kernel community and a traditional (or typical) gnu community imo: Linux guys are often much more divergent. I.e. people are much more distributed and fragmented. Often lone-wolfs sitting in a cottage somewhere in the Finnish forests ;) They might not because of that always be on-line to a centralized SCM and they need a good tool that can work well while being fully distributed.

my 2 cents...

Here's a HowTo link to Git btw

http://linux.yyz.us/git-howto.html

_________________
FREEEEEEEEEEEDOM!

/Aprak
http://cea-history.blogspot.com/
http://kato.homelinux.org/~aprak/

Jetto

Posted: Wed Dec 20, 2006 2:42 pm

Joined: 01 Dec 2006 Posts: 59 Location: France

I'm working for a big French telco company in a methods & tools team as an SCM administrator and scm responsible for some project. Here we use Clearcase (base).
What I can say is the tool we use is very less important than the way we use its. Every time the key problem is the process.

I ever had to do some SCM/VCM tools benchmark to think on how to replace ClearCase. I look at Bazaar, Darcs, Monotone, Subversion and Git. Unfortunately I don't find the killer argument to switch from ClearCase to one of these tool.

The most important feature to have in an SCM tool when we don't plan to put in place a strong process is the change-set isolation.

Here is a well know place for Version Control System Comparison. But this not replace practice.

I see in the Asso CV that Vianney Lecroast the TCO is a on software development process expert. So we may trust him to do good choice.

sfb

Posted: Wed Dec 20, 2006 2:51 pm

Joined: 28 Nov 2006 Posts: 46 Location: Minnesota, USA

Nothing says that the tool you use will dictate your CM environment. We use Atlassian's Confluence (Wiki,) JIRA (issue tracker and project planner,) Crowd (sign-on integration,) and we also use Cenqua FishEye (source manager, like ViewVC and CVSmonitor plus more features.) The nice thing about this is that JIRA and FishEye both support multiple CM environments (Perforce, CVS, SVN are the most popular implementations.) JIRA also supports FishEye integration on issues as well as direct version control integrations. One of the nice things about JIRA is that it does its work using the CM history (the 'history' file in CVS, for example) so you don't need any super goofy scripts (Bugzilla and bugzilla-watcher come to mind) to integrate your issue tracker and CM environment.

Confluence also integrates tightly with JIRA (you can link JIRA issues to Confluence articles and vice versa) and using Crowd I have all of these authenticating off of a single database and support single-sign-on (log in to one and you're logged into all of them.)

Confluence has more than 125 plugins and a plugin repository that will live-install most plugins from the web administration page. JIRA also has a significant plugin and extension repository with everything from integrations with CMs to workflow plugins to facilitate methodologies such as Scrum.

Atlassian also has a product coming out, which doesn't affect the web portion but may affect the game portion, called Bamboo with is a fairly decent looking CI (continuous integration) system that links with JIRA (builds and build errors can generate issues or attach to related issues.) Cenqua is also releasing a commit acceptance and peer-review tool to work with FishEye called Crucible which looks very promising. Again both of these tools all integrate nicely with all of the afore-mentioned ones.

I know I sound a little like an Atlassian salesman but my project is using them and we really like them. The only real down side to these products is that their "open-source" nature isn't really there. These guys aren't purists so only components of the system are open-soruced (e.g. Seraph) and they do submit significant code to other projects (e.g. Hibernate, Maven.)

The other bonus is that for true open-source projects (commercial or not, as long as the code is all open-source) the licenses for these softwares are free.

Just something to think about..

You can see something we started to put together when we thought that Nevrax was going to be no-more, our "backup" of NeL.

http://dev.ironicentertainment.org/confluence/display/NeL/Home

Aprak

Posted: Wed Dec 20, 2006 3:48 pm

Joined: 02 Dec 2006 Posts: 60 Location: Stockholm, Sweden

Jetto wrote:

I ever had to do some SCM/VCM tools benchmark to think on how to replace ClearCase. I look at Bazaar, Darcs, Monotone, Subversion and Git.

This is exactlly the kind of objective posts we need :) GJ Jetto!

BTW if you want/need some arguments against ClearCase, drop me a note and I'll send you a list. Here comes one or few that really annoys me the most though:

- Dependency towards a company end their so called "specialists" (they'd really most of all want you to have one of their expensive consultants sitting in your lap full time).

- Expensive like a sunovabiach

- Wink-in crap meant to make builds faster, requires "virtual devices". This is not only unbelievably slow, it murders you network AND it locks your development team into using a certain platform (due to practical and economical reasons). Make a practical (i.e. real experiment) comparison if you haven't done so already - I promise you you will be surprised of the results.

BTW sbf: I might have understood you incorrectly, but if you mean that the choice of SCM does not matter (even when it comes to processes), I'd have to strongly disagree.

My 2 dappers worth...

_________________
FREEEEEEEEEEEDOM!

/Aprak
http://cea-history.blogspot.com/
http://kato.homelinux.org/~aprak/

sfb

Posted: Wed Dec 20, 2006 4:46 pm

Joined: 28 Nov 2006 Posts: 46 Location: Minnesota, USA

Aprak, you did misunderstand me. I was saying that your issue tracker should not dictate the CM environment you use. E.g. you shouldn't say "I want to use Trac but then I'd have to use SVN." You should be able to say something like "I want to use Trac and I'm going to decide between Perforce and SVN."

I agree with you regarding ClearCase. There are many free and inexpensive tools available to make other CMs out there (such as CVS) perform adequately enough to replace anything that ClearCase would provide. At my last employer we investigated ClearCase because StarTeam was prohibitively expensive, our support was coming to an end and we were still about 5 revs behind. In the end we found that using Bugzilla (I was a proponent for Mantis at the time) with the suite of log-info and various other scripts (e.g. bugzilla-watcher, cvsspam, ViewVC, CVSmonitor) and a commercial piece of software called WANdisco and, as the Software Development Manager put it, "good old common sense" was as good as what IBM pitched us and a hell of a lot cheaper.

mildred

Posted: Wed Dec 20, 2006 6:40 pm

Joined: 28 Nov 2006 Posts: 52 Location: France

I would like to see Ryzom using a decentralized tool, mostly because you don't have to have an account on the repository to commit changes, you do it locally.

Someone suggested Git, it must be a very good system, but lst time I checked it, it was nor really easy to use on Windows. So I don't think it could be a good idea (since Ryzom is actually windows only).

For my projects, I use Bazaar-ng, but I have no clue if it is a good idea for ryzom or not.

_________________
xmpp:[email protected]

Jetto

Posted: Wed Dec 20, 2006 10:16 pm

Joined: 01 Dec 2006 Posts: 59 Location: France

mildred wrote:

Someone suggested Git, it must be a very good system, but last time I checked it, it was nor really easy to use on Windows. So I don't think it could be a good idea (since Ryzom is actually windows only).

This was also a problem I had. It works with cygwin but this is far to be ideal.

mildred wrote:

For my projects, I use Bazaar-ng, but I have no clue if it is a good idea for ryzom or not.

I think arch is the good experimental tool. I switch some of my personal work on it. But it is hard to understand. Bazaar is more usable but very hard to seriously promote because of its name :o. I never try Bazaar-ng.

Aprak

Posted: Wed Dec 20, 2006 10:30 pm

Joined: 02 Dec 2006 Posts: 60 Location: Stockholm, Sweden

Cygwin is not to bad.

I'm running both CVS and SVN under Cygwin when I'm forced to use WinDongs. Works OK if you're not after uber performance.

Just tested to build Git under Cywin but had some dependancies that broke the build. No need thoug, Git was included in the package list, so it's just a click away.

http://sources.redhat.com/cygwin/

_________________
FREEEEEEEEEEEDOM!

/Aprak
http://cea-history.blogspot.com/
http://kato.homelinux.org/~aprak/

nicklinn

Posted: Thu Dec 21, 2006 2:48 pm

Joined: 18 Dec 2006 Posts: 2

Git is designed to manage the thousands of patches a week that Linus handles in a meaningful way and does so at the expense of many other features that people find useful in much smaller projects such as this would be. Put simply it would be a overkill for a project of this nature particularly when attempting to court windows developers which at this point is the currently on the client side at least (and probably will be for at least the short-term future) a windows only piece of software. There really is no reason why patches cannot be submitted by regular means (email, bugzilla, etc) for individuals without write access.

Sure git and such is cool and new but being cool and new doesn't write code. The purpose of a VCS is to serve the developers not the other way around. Please keep that in mind people.