Some database schema changes are going to be needed to fix current bugs in and add features to the blocker tracking app.
In my opinion, the best way forward for that is to implement support for [http://alembic.readthedocs.org/en/latest/ alembic] in the blocker tracking app. That way we don't have to worry about losing data or writing SQL migration scripts by hand.
Do we have some data that mustn't be lost? Fedora 18 is over and everything can be purged clean, from my perspective, with a fresh start for F19. No?
Replying to [comment:1 kparal]:
Yeah, the current data isn't all that important outside of it's value in generating stats about blockers from F18. However, I think that schema change control is important going forward because: * It's safer to figure things out in the blocker tracking app instead of somewhere where the old data is critical * We may want to do changes mid-release that require schema changes and I'd rather not risk losing data * It helps support more incremental changes to the DB since those changes become less risky * re-entering all the settings in the database is a pain
IMHO, schema control is a good thing to have for any non-trivial application and it's better to add it when the application is smaller than wait until you really need it - at that point, any database change is likely to be rather risky.
Fixed in [http://git.fedorahosted.org/cgit/blockerbugs.git/commit/?h=develop&id=713a65085ed4fa52b39dba2119ea1a12600fc94f 713a65085ed4fa52b39dba2119ea1a12600fc94f]
Log in to comment on this ticket.