Although it's unlikely to be an issue, technically we shouldn't be
insisting the sha1 field be unique globally, just within each
layerbranch, so adjust the constraints.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Most layers do not track maintenance on a per-recipe basis, and for
those layers we will hide some of the per-recipe maintainer features
and on the recipe detail show the layer maintainer(s) as the
maintainer(s) of the recipe.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
RecipeUpstreamHistory was not linked to the layer it was produced from,
which meant that it wasn't easy to query for a different maintenance
plan (i.e. a different layer) and thus the maintenance plan selection
on the recipe list didn't really work. Add a link field, populate it in
a migration and then make it required.
We had added a link earlier from RecipeMaintainerHistory to LayerBranch
but it was optional; for the same reasons we now populate it and make it
required.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
I missed changing this constraint when adding the plan field. We want to
be able to have the same named release on another plan.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Provide a mechanism set the maintainer for things like gcc-cross-<arch>
to the same as gcc. (We do have entries in the .inc file for these,
however they aren't useful as they don't match the recipe name when we
parse it, and due to the fact that RecipeMaintainer objects link
directly to Recipe objects, we can't handle entries that don't map to a
real recipe).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add an option that deletes all maintainer history records for the
current layer branch so that they can then be reloaded from scratch.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Instead of arbitrarily importing the last 8 days of upgrades, record the
date and commit when we do an import, and then use that information the
next time the script is run.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If you want to go back and get history for the earlier releases (krogoth
and previous) then we need to be able to support both python 2 and 3,
which practically means we need the same split for this script as we
have for the main layer index update script.
The catch here is that since we are going back and following the history
of changes forward, we basically need to use the same version of bitbake
that was current at that time. This works except for around the
transition between python 2 to 3 where the metadata lagged behind a bit,
so we need to take that into account. In order to keep things generic we
have a date field on the maintenance plan layer branch that specifies
the date in the metadata where we should switch over to python 3, and
then link to PythonEnvironment records that should be used for python 2
and 3 respectively.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Fixtures aren't supported in current Django versions. Add some code to
the initial migration to add the data instead.
Also add releases/milestones up to and including 2.5.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
* Add a flag to say whether emails should be sent
* Add fields for from/to/subject (to replace what's currently in
settings)
* Add user link for administrator to replace the hardcoded values in the
email template
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If any Releases exist then we create a default MaintenancePlan and then
link all Releases to it - this needs to be done in multiple upgrade
steps since the field needs to be non-null.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The MaintenancePlan will provide some context for the RRS records so we
can effectively enable RRS functionality only on certain layers where we
want it. You can also consider the maintenance of multiple layers
together under a single plan if desired.
Here we add just the MaintenancePlan and the corresponding migration;
a non-null link from the Release requires a separate migration and thus
that will be done in a separate commit.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This is of course a new Django migration rather than the previous South
one. This will have to be applied using --fake-initial on a database
that already has the RRS tables.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add database indexes in models.py also create migration for upgrade
the current database in order to improve performance.
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
rrs/models.py: Milestone now have unique in Release and Name fields
instead of only field. When try to get current milestone give priority
to Mn instead of All.
templates/rrs/base_toplevel.html: Display only release name when
milestone is All.
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Now Recipes and Maintainers page can be access by Release and Milestone,
to support this a url namespace was add also update views/templates
handle new URL's.
rrs/models.py: Add support model for store Release also foregin key in
Milestone.
rrs/admin.py: Add admin site for Release model.
rrs/fixtures/initial_data.json: Add initial data with Release/Milestone
relation.
rrs/{views, urls}.py: Add support for handle Release/Milestone.
templates/rrs: Update to handle new URL's.
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Now can you get maintainers based on Milestones.
Feature changes,
rrs/models.py: Add RecipeMaintainerHistory to store maintainer updates.
rrs/admin.py: Add admin site for RecipeMaintainerHistory.
Adapt changes,
Now you need to specify RecipeMaintainerHistory to get RecipeMaintainer,
changes into rrs/view.py.
These set of changes are incompatible with the previous version you need
to do initial setup described in README.rrs.
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
To provide statistics about RecipeUpstream information based on
Milestones we need to store RecipeUpstreamHistory that contains when the
update script was executed.
rrs/admin.py: Add admin page for RecipeUpstreamHistory.
rrs/models.py: Add model for RecipeUpstreamHistory with helper functions
for get last and last by date range also add migration.
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Add models for store Milestone, Maintainer and Recipe{Maintainer,
Upgrade, Upstream, Distro}, add initial data for Milestone and
Maintainer, initial migration and admin sites.
Add rrs/context_processors.py for return the site_name and application
for use in templates.
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
