This is an automatically generated e-mail. To reply, visit:
(Updated March 1, 2013, 6:08 a.m.)
This change has been marked as submitted.
Review request for blockerbugs.
Refactoring templates, bug sync and database to fit with new FreezeException nomenclature
adding alembic upgrade script for db changes
updated bug_sync code for python-bugzilla >= 0.8
I've done several syncs on both sqlite and postgres dbs and clicked around to make sure that all the templates that _were_ working are still working. Some of the admin pages still have issues but that is orthogonal to the changes here.
I did an alembic upgrade of the database with no issues.
As we start getting closer to the time where we're all busy testing
Fedora 19, it's time to start looking at what we want to get wrapped up
Looking at the Fedora 19 schedule , we have:
2013-03-12: F19 Branch from Rawhide
2013-04-02: Feature Freeze
The way I'm thinking, the drop-dead-date is 2013-04-02. I don't
remember a release where we weren't mostly consumed by testing tasks by
the freeze date and even though we don't _think_ F19 is going to be a
huge problem - that doesn't mean that we won't be busy :). I don't
want to find ourselves in a situation where we really should be working
on F19 but need to be wrapping up devel/integration work on any of the
The way I see it, we have some critical stuff left to do and some more
nice-to-have stuff that won't cause too many problems if left
unfinished. I've created a list at the end of this mail listing groups
of tickets in order of priority.
I'm not worried about (1) and (2) on that list. (1) is pretty much done
and (2) should be pretty quick. (3) could be a problem but should be
workable before F19 branches.
That leaves (4) and (5) as the larger items which I don't think _have_
to be done before F19 but it would be really nice if they were done.
Martin and I should know more about the likelihood of their completion
in the next couple of days.
(6) is a bunch of stuff that would be nice to have but I'm not going to
lose any sleep if they aren't done in time. They would be great small
things to pick up if anyone else is interested, though :)
== Critical to Finish Before F19 ==
1. Finish in-progress work
* Implement Blocker/FE Proposal Page
* Add Fedora 19 Milestones
These are either mostly done or close to being done - code reviews
have been filed and code should be in develop soon
2. fixing some small bugs reported during F18
* Bug summaries are not updated
* Blocker Components are not updated when a bug is reassigned
These bugs were found during the F18 test cycle and shouldn't be too
hard to actually get done. Since they were reported by users, the
issues were noticed and thus really need to be fixed before F19
testing gets into full swing.
3. packaging and making sure we're able to use SSL for F19
* Package Blocker Tracking App for Fedora and EPEL
* Create Ansible Playbooks for Deployment and Updating
Now that we're using FAS logins for blocker proposals, we need to be
able to use SSL so that passwords aren't transmitted in the clear.
While using a self-signed cert is an option, it is kind of a last
resort that decreases the usability of the site.
I've been talking to the infra folks and the best way forward is if
we can get the tracking app to the point where we are hosted in the
production infrastructure. This means that we should be packaged in
EPEL and have Ansible scripts for the deployment and updating of the
I already have the Ansible playbooks mostly written - they mostly
need some cleanup before submitting them. I'm not exactly sure how to
handle alembic updates with playbooks and the package but I think
that's something which could be figured out with packaging.
The potential snag here is the CSS - right now that is being compiled
from SCSS using sass/compass and the zurb-foundation framework. None
of these things are currently packaged for EPEL6 (sass and compass
are at least packaged for fedora so unless there are problems with
the ruby version in EL6, those shouldn't be difficult). It's possible
that CSS could be considered content instead of code which would
allow us to continue distributing the compiled css instead of needing
to compile it at build time.
== Would be VERY nice to have but not absolutely critical for F19 ==
4. improving the blocker submission so that it's either not so slow or
not vulnerable to refresh during submission
* Blocker Proposal is Slow
I haven't filed any detailed tickets for this yet because while I
have ideas on how I want to fix this, I'm not sure if they would
be practical or if there is enough time before F19 to actually get
5. Bugzilla auth integration
* Implement Bugzilla Account Association
* Store Bugzilla Email Association in Database
* Implement Bugzilla Email Verification
* Integration Bugzilla Email Association with Blocker Proposal
At the moment, Martin is planning to do this - not sure if it'll be
done in time but we're going to be discussing that tomorrow.
== Nice to have for F19 but not absolutely critical ==
6. misc. cleanup (minifying css and js, reworking templates so that
only the js _needed_ is loaded on every page, adding some links)
* Improve asset management
* Optimize Template CSS and JS includes
* Add visible Link to IRC Meeting Prep
* Add cgit link to Main Page