[combining some posts here] Jan: > sorry for the late coment. I am catching up the list only in certain > intervals and usually can not react immediately unless put in cc > or notified else.
Ok. I hope you saw all the comments from a number of us about how happy we have been with the CVS and other support from Intevation. That is probably the number one reason we have not moved to OSGeo's servers a year ago and why this discussion continues on and on. > this list apparenly is driven by the wish to go to osgeo. I would say there is some general wish to have closer ties with OSGeo than we have now. There is no reason to move away from Intevation, just a slight reason to put something at OSGeo. In that case, all other things being neutral, and having to do a cvs2svn port anyway, a move to OSGeo has had some support. (my personal view is that I'd be happy with either place) Markus: > > We clearly see that GForge for GRASS is way under-used. Jan-Oliver Wagner: > I guess you mean the bug tracker is underused? yes. (AFAIK that's all we have turned on) I think it is best to solidly decide which support software we want to use. Once we have clearly decided that we just push hard to get it ;) Right now we seem to be deciding what to use (& where) based on what is already installed, which seems backwards. What support software to use seems to be a totally separate issue from where to host things, as Intevation seems to be happy to provide what we ask for as best they can, and I guess (but don't know) that the OSGeo admins would be supportive too. For me, getting the support service software "right" is much more important than looking like a good OSGeo team member or keeping *everything* on the same server in some unified content management system. But of course we should encourage tie-ins with OSGeo as best we can, I don't mean to say we shouldn't do that as much as possible, just not at the expense of choking the good infrastructure we have now. For my 2c, I like: * current web server setup seems ok (including rsync mirrors and CVS) * current wiki software (MediaWiki) (we can fix the current spam issue) * move to SVN for source code management (actually, for me anyway, I don't have any problems with CVS) * Same ViewCVS setup as we have now, but interfaced to SVN: e.g. http://josef.fsv.cvut.cz/cgi-bin/viewcvs.cgi/?root=grass7svn * .... bug tracker .... what was wrong with the old one again? The two really annoying things with Gforge bug tracker to me is the top posting of comments and that you can't cc it in posts to the grass-dev mailing list, you have to use the web form, duplicating effort and killing casual contributions. I don't like to think that we are defeated in what we want to do based on spammers. I don't see a huge need to move Everything into "the" OSGeo framework with a OSGeo "look" to it. On the same lines I don't see a huge need to combine all web/wiki/SCM/bugs under a single Trac or Gforge master. (I accept Frank's word that the SVN tie-in will be rewarding, but haven't seen that clearly yet myself) I accept that there can be e.g. multiple SVN web interfaces running at the same time, to suit all tastes -- at least for that it is important to note that it doesn't have to be mutually exclusive. Another point is that the CMS (trac,gforge,..) doesn't have to actually host the wiki, e.g., it just has to point to where it is. So what I really care about is having the right tools working at 100%, not where they live at night or what colors they are painted. If we decide to stay with GForge or MediaWiki but there is some feature we just can't live without, then surely there is enough programming talent around here to patch them & submit to upstream..... and if Intevation or OSGeo needs help fulfilling our wants, we can do that too. regards & sorry for the ramble, Hamish _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
