Django 1.7 has built-in migrations support, so we no longer want these
around. All existing installs should be fully migrated at this point to
the latest schema.
Signed-off-by: Dan McGee <dan@archlinux.org>
Most of these were suggested by PyCharm, and include everything from
little syntax issues and other bad smells to dead or bad code.
Signed-off-by: Dan McGee <dan@archlinux.org>
Not sure why on only this one I decided to put all three parts in the
same column. We don't do this anywhere else.
Signed-off-by: Dan McGee <dan@archlinux.org>
This is more flexible than our existing 'optional' boolean and will
allow us to import check and make depends into the database as well as
what we are already doing.
Signed-off-by: Dan McGee <dan@archlinux.org>
These models regularly sort by or limit by the created field, so adding
a index on the created database column makes sense.
Signed-off-by: Dan McGee <dan@archlinux.org>
This will be used to track updates to package as we do them during
reporead. By storing enough relevant fields from the package object, we
should be able to produce a useful report on a regular basis of what has
been happening in the repositories.
Signed-off-by: Dan McGee <dan@archlinux.org>
New (and slightly odd with regards to verbose_name) in Django 1.4. This
simply ensures a deployment in an IPv6 environment actually works as
expected. If you were using PostgreSQL as a database backend, you won't
be affected by this as the 'inet' type was already used, but at least
now you can edit the values in the admin without getting an error.
Signed-off-by: Dan McGee <dan@archlinux.org>
This is most of the transition to Django 1.4 `USE_TZ = True`. We need to
ensure we don't mix aware and non-aware datetime objects when dealing
with datetimes in the code. Add a utc_now() helper method that we can
use most places, and ensure there is always a timezone attached when
necessary.
Signed-off-by: Dan McGee <dan@archlinux.org>
This makes it easier to match up a flag request with the package state
at the time of flagging, and might also help to determine if flagging
actions were legit. We only store it if it is the same across all
packages to be marked.
Also, move the various database write activities when flagging packages
into a single transaction.
Signed-off-by: Dan McGee <dan@archlinux.org>
This pulls them from the latest SVN commit on trunk. We don't have a
failproof method of getting the exact right commit, but this should be
close if it is run on a regular basis via cron (aka hourly).
Note that running locally, I needed the development version of South to
get the migration included here to apply because of information_schema
changes in the current version of MySQL.
Signed-off-by: Dan McGee <dan@archlinux.org>
Add a new 'SignoffSpecification' model which will capture metadata
regarding a specific package if it differs from the norm- e.g. more or
less than 2 required signoffs, is known to be bad, a comment from the
maintainer, etc. The groundwork is laid here; much of this will still
need to be wired up in the future.
Enhance the view with a lot more JS prettiness and add revoking of
signoffs. The signoff page can be filtered and the links and all the fun
stuff are totally dynamic now.
Signed-off-by: Dan McGee <dan@archlinux.org>
This one is centered around pkgbase, much as our PackageRelation object
is. However, it also tracks all of the versioning fields we have in
order to making joining against the current package testing list
possible. Finally, additional metadata including a created date, an
(optional) revoke date, and a comments field are added.
Signed-off-by: Dan McGee <dan@archlinux.org>
This allows us to store conflicts, provisions (provides), and replacements
in the database, things we weren't capturing before. All can be multivalued,
just like License and PackageGroup.
Signed-off-by: Dan McGee <dan@archlinux.org>
This allows us to store multiple licenses per package in a more elegant
fashion, and will later allow us to search and filter on this information.
Signed-off-by: Dan McGee <dan@archlinux.org>
We had some dependency issues between migrations that needed to be
explicitly defined in order to get things fully moving, and do to some
braindeadness in Django tests not including the project url config, we need
to do some clever business when using the url tag in the base template so
tests don't doe with a NoReverseMatch exception.
Signed-off-by: Dan McGee <dan@archlinux.org>
This is an attempt to fix our long-standing problems dealing with maintainer
information. Move the actual maintainer information off of the package model
into a PackageRelation object, which has some flexibility to later represent
more than just maintainership.
This solves multiple problems:
* If a package gets accidentally deleted, so did the maintainer info
* Testing packages have always shown up as orphans
* With split packages, it was easy to miss some of the sub-packages
This commit does not include the deletion of the original maintainer column;
that will come at a later time when I feel more confident that the data was
migrated correctly.
Signed-off-by: Dan McGee <dan@archlinux.org>
