>> I like Trac fine, but my only concern is how much of a maintenance headache >> is it? I'm guessing from the discussion so far is that SF would setup Allura >> and we just "plugin" to it whereas it looks like the onus is on us to setup >> Trac and maintain it. As all of us are already overbooked with work to do, >> I'd hate to put something else in our queue. If it's a one-time setup kind of >> thing then that shouldn't be too bad. > > It's not much maintenance headache to just get it up an running. I can have > Jason Miller (our current technician that handles all of our repository > management / Trac management / release management / package management / > machine maintenanceŠ yes he has a LOT of responsibilities!) set it up for you > guys if you like. He's a Trac wizard at this point that can get it up and > running in no time and configured the way you want it.
He would have to be able to do it through our sourceforge private web space, as hosted apps are going away basically now: http://sourceforge.net/blog/hosted-apps-retirement/ I share Paul's concern about time sink. For libMesh at least, I would like to be able to use as much existing and managed infrastructure as possible, so we can all focus on the tool itself and not the management tools. If Trac is the way to go (I'm not ruling it out!) that poses an issue. We maybe *could* do it in the sourceforge framework, but it is a hack and will continue to be a struggle over time (think our mediawiki instance). If Trac is the way to go then I think we would be much better suited breaking up with sourceforge and going somewhere that handles hosted Trac as a core service. But if we did leave, that opens up a lot of options I've been thinking about. One worth serious consideration would be using Atlassian's hosting, which is supposedly free for open source projects. I'm investigating that. They provide a tightly bundled service with everything we need, including regression test/automatic build support. See http://www.atlassian.com/software/ondemand/overview?_mid=2504fdbe151885f3955 9e11250dd9c85&gclid=CI67rpm9urICFbKiPAodHjAARA I've been thinking about this a lot lately, and here's where I'm at: - Current libMesh collaboration is pretty much just email and collective memory, and we should be doing a lot better. - Staying with sourceforge has some benefits - I for one would like whatever collaboration environment we choose to use to be a *provided service* - not just one we shoehorn into sourceforge's web space offering. With that in mind, I see two possible paths forward: (1) stick with sourceforge (at least for now), but explore using Allura to help enable better collaboration, or (2) move somewhere else that hosts the collaboration environment we want directly, maybe even if this means paying a nominal annual fee. Since (1) is so easy (only impact will be svn switch'ing to a new repository URL) I'd like to try that first, but stay open to option (2). Note that if we went to option (2) we should still be able to retain our svn history, but things like user accounts (and potentially mailing lists) would be redone and therefore represent a more major headache. Other thoughts? -Ben ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
