Moving from trac to a single redmine

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Fri Feb 5 16:10:54 UTC 2016


Hi Holger,

On Thu, Feb 04, 2016 at 08:12:19AM +0100, Holger Freyther wrote:

> I think some of us would like to move to redmine and start using
> public tickets more frequently. So in case we move there are some
> topics to be discussed and I would like to start with a couple of them
> right now.

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.

> Redmine has a global linear sequence of ticket numbers. If we move
> from many tracs to a single redmine we can either:
> 
> 	* not import tickets
> 	* only import from one project
> 	* deal with changing ticket numbers

I think not importing tickets or dealing wih changing numbers is the way
to go.

> In terms of installations the GMR trac is broken in regard to tickets,
> there are some for SDR that are probably not being fixed anytime soon,
> baseband might be relevant and OpenBSC is unlikely to be relevant. I
> don't think we have ever used ticket reference in OpenBSC commit
> messages so in terms of OpenBSC having changing ticket numbers would
> not be a big deal. E.g. we could add a custom field with the old trac
> number?

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.

> We have external references that should be redirected to the new
> place. Is there any way besides maintaining a list in the
> apache2/nginx configuration and making redirects as we find broken
> references? Can we proactively manage this? Is anybody willing to come
> up with a script and nginx configuration for doing this?

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the osmocom-sdr mailing list