Add a script for doing a one-time import of OE-Classic recipe
information, so comparisons against OE-Core can be performed; this
is stored using a new ClassicRecipe model supporting additional fields
for tracking migration status. The migration status fields can be
updated as well as viewed and summarised in graph format.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This provides a way to set "meta" fields (SUMMARY, DESCRIPTION,
HOMEPAGE, BUGTRACKER, SECTION, and LICENSE) for a number of recipes at
once, and then download those changes in the form of one or more patch
files which can be submitted for merging into the layer.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Collect bbappend/bbclass info during the update process and display it
on the layer detail page.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add an index_preference field to enable control over which layer's
duplicate recipes get de-emphasised in the recipe search results.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Save individual field changes into revision comment and display this
comment on the history page. Now we're ready to add a link at the
bottom of every page so the history is easily visible.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
It's not really appropriate to say "Hi Joe Bloggs" at the start of the
email - we only need the user's first name or the login name if the
first name hasn't been filled in.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This avoids showing a 403 error when a user clicks on a review link in
the layer submission notification email but hasn't logged in yet.
Also protect the review list view with a permission check; it's not that
it's sensitive, but we should be consistent with the detail here.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If another recipe exists with the same name in a different layer and
that other layer is "older" (by layer ID) and is a software or base
layer then lighten the recipe entry in the search results as it may
not be the preferred version (e.g. recipes in BSP or distro layers may
have been customised specifically for the machine or distro).
This has had a performance impact on the recipes list; as a result
showing all recipes by default has been disabled. If the user really
wants to see all recipes they can just leave the search box blank and
hit the search button.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If the user edits the layer and changes the repository URL,
subdirectory, or dependencies, ensure that the entire layer gets
refreshed the next time the update script runs by clearing out the last
fetched revision field.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
So it turns out that one or two layers have changed in structure between
branches, so we need to be able to specify this on a per-branch basis.
Good times...
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This cuts out a lot of the elements that aren't needed for the review
list, shows fields in a more suitable way for review purposes than the
standard detail (and includes some fields that don't currently get shown
on the standard detail e.g. layer type and short description).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Newly submitted layers don't have anything other than a master branch,
so they won't display properly unless we have master selected; so just
add a parameter to submission email and review URLs to ensure that is
the case.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The simple views for about and the submit thanks pages don't need
special views, so the standard TemplateView can be used.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Change the data structure to support multiple branches. At the top level
there is a set list of Branch objects, and then a LayerBranch object
between each layer and the maintainers, dependencies, recipes and
machines, so that the set of each can be different per branch. The
branch is a session option, and can be selected via a drop-down that is
shown for all pages.
Additionally, with this change we avoid the need to run the update
script within a build environment set up with oe-init-build-env - since
we need a specific version of BitBake per branch we now use our own copy
of BitBake which is fetched by the script itself. The update script will
need to be called multiple times however - once per branch.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This should prevent spamming even though this is less likely with this
kind of site.
The CAPTCHA does not show when editing, only submitting, and is also not
shown for authenticated users.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If we get bogus or duplicate entries we'll want the ability to delete
them easily before publishing (without needing to have access to the
admin interface), so add this ability. Being able to delete a published
layer might be a bit dangerous and is less likely to be needed so that
is disallowed for now.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This allows adding an important notice to a layer e.g. "this layer is
deprecated, please use layer xyz instead". Only one layer note can be
added through the interface although the data structures allow multiple,
so notes may be added programmatically without disturbing user-added
ones.
With this change we also add a get_absolute_url() function to the
LayerItem model and change the calls to reverse() for layers to use it.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Allow users with publish permission to edit any layer, and users with
the same email address as one of the maintainers of a layer to edit that
layer.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The number of machines is likely to be quite high and it may not be
immediately clear to users which layer machines can be found in, so add
a searchable index to help with this.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Previously I had added a custom widget to handle this, but it turns out
it's not flexible enough - we want to style items individually (not done
yet) and reorder checked items to the top on refresh (done).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We have django-reversion to handle auditing/history now so we don't need
an explicit field to hold the creation date.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Formsets allow us to have separate fields for name/email for each
maintainer, as well as being able to collect the responsibility field
value. Also split the form to be output field-by-field to allow styling.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The layer list has a javascript-based search which won't interact well
with server-based pagination, so disable it for the moment.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
* Use more traditional GET instead of POST method
* Search in pn, summary, description and filename instead of just pn
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Just in case two users go to publish the same layer at around the same
time, avoid saving the record for a user who tries to publishes it after
the first time.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
