Hi Holger, On Thu, Feb 04, 2016 at 08:12:19AM +0100, Holger Freyther wrote: Thanks for getting the public discussion about this started. To give some more background to the mailing list: * The trac installations at osmocom.org are pretty much underused/dormant. The only part that's used is the Wiki. * Osmocom started when a single project (OpenBSC) got a sister project (OsmocomBB) and has grown into many projects. Running a single trac instance for each project on a separate dns hostname is overkill. Also, as code is shifted around between libraries and programs, we'd appreciate some flexibility. * at sysmocom internally we have successfully used redmine for dozens of different projects. The project hierarchy can be changed as needed on the fly, and issues can relate to issues of other projects, shifted from project to project, etc. * Quite a bit of the work we do at sysmocom on the Osmocom software should have the issue tracker for bugs and features in the public, but as our internal redmine is so much easier than the public trac setup, we kept using the internal redmine. So my plan moving forward is to migrate all Osmocom projects (initially those related to GSM) to a public redmine, and then keep all issues updated there. This would give more visibility into the work we're doing, such as the EDGE PCU, the 3G NITB + SGSN, the HNB-GW, etc. I think not importing tickets or dealing wih changing numbers is the way to go. If there is automatic import/conversion available, I'd prefer to import the OsmocomBB, SIMtrace, (non-spam) Security and OpenBSC tickets, even though most of them are probably stale and outdated for years. They're still part of the history. Changing the numbers doesn't matter, as we don't refer to them. I'm not aware of any tools that might be able to help here. Indeed, it would be great if anyone would volunteer to generate a script to generate the redirects. I guess the old format is e.g. http://openbsc.osmocom.org/trac/wiki/nanoBTS/Internals and the new URL would be something like http://projects.osmocom.org/redmine/openbsc/wiki/nanoBTS/Internals Or should we strip even the redmine from the URL? And should we have a rewrite for http://openbsc.osmocom.org/redmine to http://projects.osmocom.org/redmine/openbsc ? Any ideas? Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi Holger, let's move ahead and start with the migration, I can't wait to put all the various tickets into a public redmine. Thanks! -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Dear all, It's been more than half a year that we transitioned the Osmocom projects from the various trac instances to redmine. Still, a lot of people end up on the old redmine pages. How do I know? Because of the amount of personal e-mail I receive from people asking for accounts or for modification of the content there. [This is of course just the indicator, I don't mind those mails]. But what worries me is that people are looking at outdated information in the old trac without even knowing. How do we proceed about that? I'm not quite clear. The first step could be to add some kind of banner to the old trac installations, indicating at the header / footer of every page (or even as a floating block visible at all times) that this is old, outdated content that is scheduled to be removed at a certain date, and indicating the top-level page for the specific project in the osmocom.org redmine as an updated source. After that grace period has passed, we should probably make all the old trac pages redirect to the entry-page of the project in redmine. Trying to link to the respective new page in each individual wiki would be overly complicated and take a lot of time, unless somebody masocistic enough would volunteer for creating such a list. It can probably be auto-generated to some extent, but then each individual item would need to be manually verified and fixed up, if needed. Do you have other ideas on how to proceed in a better way? Do we have any volunters about any of the above? I'm quite sure it wouldbe easy to provide volunteers witha copy of the existing trac databases or any other information that might be needed. Thanks in advance for any assistance, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)