On Thursday 28 January 2010, Dean Glazeski wrote: > > The only significant "anti-" sentiment I have is that the Trac git plug-in > > hasn't had an update since 28th of August of 2009. I'm going to play with > > this a little bit with my sourceforge project that's hooked up to git and > > I'll get back to you. > > > > Alright, it's impossible to do it, for now. The Sourceforge people haven't > setup the ability to have Trac connect to a git repository.
What would such a hookup amount to? I know that Linux, for example, doesn't need such a thing. One can just stick the bugtraq ID into patch comments, or a commit ID into the bugtraq record. That suffices. > If we want to > do only development tracking in the wiki and manage bugs and features in > Trac, I think it's still a good idea. That's pretty much how every project I've ever worked on has done things: bug database and source repository aren't coupled except by a convention about how to cross-link. Works fine. Fancier linkage could of course work too ... but is not required. > They may eventually get the git > connector working, but for now it's a no go. You can build the plug-in in a > shell on sourceforge, but I have no idea how to make trac aware of the > plugin. Here's a ticket about it: > https://sourceforge.net/apps/trac/sourceforge/ticket/7674 Let's hear from some more folk. I mentioned this issue a bit before I cut the RC1 release, and didn't hear any significant negative pushback. So I'm inclined to wait till maybe Tuesday evening, just in case. > Please, do consider using it. Having a viable ticket manager is a great > idea. Note that "manager" has two meanings. One is the programmatic sense, a database with front-end. (And there are more choices than just Trac of course ... but with Trac we offload a lot of work to the SourceForge team.) The other one is a *person* tracking bugs etc. That's always the problematic meaning ... making sure the bug database does not fill up with garbage. Right now I seem to be the person doing this for the bugs that can (or should!) affect the 0.4.0 release; nobody volunteered to handle *any part of that* for the community. ... And as far as I can tell, this is the first release cycle that's even had lists of bugs/regressions like that. I'm a lot less concerned with the detals of how the list of open bugs gets managed (email or whatever) than the fact that it needs to be managed ... in a public/open way. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
