Opened 9 years ago

Closed 9 years ago

#128 closed defect (fixed)

move bug tracker

Reported by: Will Kahn-Greene Owned by: Will Kahn-Greene
Priority: minor Milestone: 0.2.1
Component: component1 Keywords:
Cc: Parent Tickets:

Description (last modified by Will Kahn-Greene)

This bug covers moving the bug tracker from bugs.foocorp.net to our
own server.

I asked on the mailing list whether people wanted to switch bug
trackers and there were no strong opinions.

My current problems with redmine are:


1. can't tag bugs -- useful for marking bugs as bitesized (bug
   `#382 </issues/382>`_)
2. mediocre search
3. I'm concerned it won't scale to hundreds of contributors

It's possible I can solve issue 1 if we had our own redmine
instance using a plugin or something. We can push off issue 3. No
one else seems to have problems with issue 2, so we can push that
off, too.

Given that, this bug covers:


1. researching redmine to learn how to set it up and run it
2. figuring out what to do about tags
3. getting a dump of the data from foocorp
4. importing the data into the new bug tracker
5. changing all the urls in the docs and web-site to point to the
   new instance
6. creating some kind of automated something that watches the old
   bug tracker for activity and tells people to use the new one

I'm going to try to get this done for 0.0.4.



Subtickets

Change History (17)

comment:1 Changed 9 years ago by Christopher Allan Webber

If we get a data dump from foocorp we should try and get all the
patches too, or at least sure all bugs with patches in them are
resolved.



comment:2 Changed 9 years ago by Will Kahn-Greene

Milestone: 0.0.40.0.5
Bumping this to 0.0.5. I would rather do this at the beginning of a
dev cycle rather than at the very end of one.



comment:3 Changed 9 years ago by Will Kahn-Greene

I sent a status message to the mailing list about this.

The original plan was to install Redmine on mediagoblin.org and
migrate the data to that. I spent some time working on that and it
looks like it's a total pain in the ass to install and maintain
partially because I don't know anything about how Rails apps get
deployed. So I balked at that and decided maybe Trac is similar
enough ui-wise that we could use that instead.

I installed Trac at
`http://issues.mediagoblin.org/ <http://issues.mediagoblin.org/>`_
and I'm in the process of fiddling with it and tweaking
configuration. My plan is to continue doing this until it "feels
right" and then dump the database and migrate. Any help with this
would be super. Ping me on IRC.



comment:4 Changed 9 years ago by Elrond

-  Click register
-  fill out form. (I don't know, if I filled in the final optional
   "Name" field.
-  Submit it.
-  Got the "Registration has been finished successfully. You may
   login as user elrond now." (the appeared as text)
-  On the same page a login form. So I put my user and password
-  Submit it
-  Got an error page

   Trac detected an internal error: TypeError: **call**() got an
   unexpected keyword argument 'link'

   There was an internal error in Trac. It is recommended that you
   inform your local Trac administrator and give him all the
   information he needs to reproduce the issue.

   To that end, you could ==== How to Reproduce ==== While doing a GET
   operation on ``/prefs/account``, Trac issued an internal error.
   ''(please provide additional details here)'' Request parameters:
   {{{ {'panel\_id': u'account'} }}} ==== System Information ==== \|\|
   '''Trac''' \|\| ``0.11.7`` \|\| \|\| '''Python''' \|\|
   ``2.6.6 (r266:84292, Dec 27 2010, 00:18:12)`` [[br]]
   ``[GCC 4.4.5]`` \|\| \|\| '''setuptools''' \|\| ``0.6`` \|\| \|\|
   '''SQLite''' \|\| ``3.7.3`` \|\| \|\| '''pysqlite''' \|\| ``2.4.1``
   \|\| \|\| '''Genshi''' \|\| ``0.6`` \|\| \|\| '''mod\_wsgi''' \|\|
   ``3.3 (WSGIProcessGroup WSGIApplicationGroup issues.mediagoblin.org|)``
   \|\| \|\| '''Pygments''' \|\| ``1.4`` \|\| ==== Python Traceback
   ==== {{{ Traceback (most recent call last): File
   "/usr/lib/python2.6/dist-packages/trac/web/main.py", line 450, in
   \_dispatch\_request dispatcher.dispatch(req) File
   "/usr/lib/python2.6/dist-packages/trac/web/main.py", line 217, in
   dispatch self.\_post\_process\_request(req,
   *resp) File "/usr/lib/python2.6/dist-packages/trac/web/main.py", line 309, in \_post\_process\_request resp = f.post\_process\_request(req,*resp)
   File
   "/usr/local/lib/python2.6/dist-packages/TracAccountManager-0.3.1-py2.6.egg/acct\_mgr/web\_ui.py",
   line 869, in post\_process\_request email=email, link=link))))
   TypeError: **call**() got an unexpected keyword argument 'link' }}}
   a ticket.

   The action that triggered the error was:

   GET: /prefs/account

-  Login seems to have worked (without waiting for the verification
   email).
-  Clicking on "Preferences"
   (<`http://issues.mediagoblin.org/prefs> <http://issues.mediagoblin.org/prefs%3E>`_)
   gives a similiar error.
   (done a few minutes ago)




comment:5 Changed 9 years ago by joar

Via the same steps described by Elrond in
`http://bugs.foocorp.net/issues/418#note-4 <http://bugs.foocorp.net/issues/418#note-4>`_
I discovered another issue.

For every pageload I do as a logged-in user, I get two registration
emails, all with unique verification tokens.



comment:6 Changed 9 years ago by Will Kahn-Greene

Man oh man... So I spent the afternoon debugging and patching
AccountManagerPlugin. I created three bugs upstream:


-  `https://trac-hacks.org/ticket/9091 <https://trac-hacks.org/ticket/9091>`_
-  `https://trac-hacks.org/ticket/9092 <https://trac-hacks.org/ticket/9092>`_
-  `https://trac-hacks.org/ticket/9093 <https://trac-hacks.org/ticket/9093>`_

All of them were fixed within an hour of me filing them which I
think is pretty phenomenal.

We're now running the latest code in svn. I registered a few new
users, logged in, and verified emails. I'm not seeing the issues
we've been having so far. Seems like it's working correctly now.

I'll let it sit for the night to see if I get any more email
verification request emails.

The next step is to wipe the database, then register some new users
and then go through and test things somewhat thoroughly. If that
goes well, then I'll do a test migration. Then a real migration.
This will probably take another week or two--this month is crazy.



comment:7 Changed 9 years ago by Christopher Allan Webber

Milestone: 0.0.50.1.0

comment:7 Changed 9 years ago by Will Kahn-Greene

I wrote a html scraper for redmine in order to capture the redmine
data. The scraper is at
`http://github.com/willkg/redminelib/ <http://github.com/willkg/redminelib/>`_
. Took a while to write because redmine is so ... clever.

Anyhow, now that that is done for the most part, I have the
following steps left:


1. write a script that takes the redmine data and puts it in the
   trac database
2. do a test migration
3. test the resulting trac instance and make sure the data is
   correct and that the system is usable; this step requires help from
   other people like Elrond

Once we're in agreement that the new system is good enough:


4. wipe the trac instance, switch it to use mysql instead of sqlite
5. tell chris to nix everyone's ability to tweak redmine data
6. do a real migration
7. work through creating accounts for everyone in trac
8. update documentation to point to the new issue tracker.

Step 7 is kind of a pain in the ass. Trac doesn't really have an
account system, so what's going to happen is people will create an
account, then let me know what it is, and then I'll re-associate
the bugs and comments to their new trac account. I have access to
peoples' email addresses in redmine, so I'll follow up with people
to make sure they get moved over.



comment:8 Changed 9 years ago by Christopher Allan Webber

Sounds great, Will... you're doing a great job of handling this
pain in the ass migration :)



comment:9 Changed 9 years ago by Christopher Allan Webber

Milestone: 0.1.00.2.0

comment:10 Changed 9 years ago by Christopher Allan Webber

Milestone: 0.2.00.2.1

comment:9 Changed 9 years ago by Will Kahn-Greene

Milestone: 0.2.1
Current status:


1. redminelib and my script accurately (as far as I can tell) pulls
   down all the bugdata from Foocorp. So that part is done.

2. mediagoblin.org is using Debian stable which has Trac 0.11 in
   its packages. That sucks. I'm switching tracks and I'm going to
   install Trac 0.12 instead. I'm in the process of figuring out the
   configuration and generating a build script for everything now.

3. I still need to write a script that takes the redmine data and
   shoves it into Trac.


This is a few days of real work. I'm focusing on this now and
pushing other projects to the sidelines for a while until it's
done. I'm hoping I'll have it done by the end of the month.

I'm taking it out of the target milestone because it's not really
related to MG releases.



comment:10 Changed 9 years ago by Elrond

What about trac 0.12.2 from backports?



comment:11 Changed 9 years ago by Will Kahn-Greene

It's much easier to just install Trac manually (it's a one-liner)
than it is to deal with adding the backports repository.



comment:12 Changed 9 years ago by Will Kahn-Greene

Did a test migration. Added a wiki page covering the migration
status
(`http://wiki.mediagoblin.org/Redmine\_migration <http://wiki.mediagoblin.org/Redmine_migration>`_).
Sent mail to the devel list to discuss outstanding issues.



comment:13 Changed 9 years ago by Will Kahn-Greene

The original url for this bug was http://bugs.foocorp.net/issues/418 .
Relations:
#290: blocks

comment:14 Changed 9 years ago by Will Kahn-Greene

Component: component1
Description: modified (diff)
Milestone: 0.2.1
Resolution: fixed
Status: acceptedclosed

This was completed on January 30, 2012. Yay!

If there are outstanding issues, please open new bugs for them.

Note: See TracTickets for help on using tickets.