At the moment a patch is split into two model entries: a Patch and a
linked Comment. The original rationale for this was that a Patch is
really a sub-class of Comment. A comment is a record of the text
content of an incoming mail, while a patch is that, plus the patch
content too. Hence the separation and a one-to-one relationship when a
patch is present. However, this decision was made before Django added
support for model inheritance and is no longer necessary. This change
flatten the models in preparation for some email subclassing work. This
is achieved by copying over the non-duplicated fields from the Comment
to the linked Patch, then deleting the Comment.
The migrations are broken into two steps: a schema migration and a data
migration, per the recommendations of the Django documentation [1]. SQL
migration scripts, where necessary, will need to be created manually as
there appears to be no way to do this in a way that is
RDBMS-independant [2][3].
Stephen Finucane [Fri, 11 Mar 2016 18:31:01 +0000 (18:31 +0000)]
fields: Simplify HashField
The HashField was written to be configurable. It supports customisable
hash types and provides fallbacks for a missing 'hashlib', which was
only introduced in Python 2.5. However, the customisable hash types
are not used anywhere (the actual hashing is hardcoded to use 'sha1')
and Python 2.7/3.3+ are the only versions of Python currently
supported. As a result, it is possible to remove much of the code
without losing any real functionality. Do this.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Reviewed-by: Andy Doan <andy.doan@linaro.org>
Stephen Finucane [Tue, 15 Mar 2016 10:57:06 +0000 (10:57 +0000)]
requirements: Loosen testing requirement versions
There's not really any reason to pin the requirements for dependencies
only used in tests, so don't do it. Replace these specific versions
with broader, major-version checks.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
This tool is exceptionally helpful for debugging issues with Django:
install it as part of the 'dev' configuration. This only works on
Django > 1.6, due to a lack of support for older versions in the
upstream.
A note is included to help users avoid the issues seen when running
patchwork on a different machine.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
Andy Doan [Thu, 25 Feb 2016 20:49:29 +0000 (14:49 -0600)]
xmlrpc: Add a check_create function
This changes adds the ability to create Check objects via the XMLRPC
interface. It includes a corresponding helper to the pwclient script.
The command can be used like:
Stephen Finucane [Thu, 18 Feb 2016 21:26:55 +0000 (21:26 +0000)]
views: Redirect when only one TODO exists
At the moment, the page listing all TODOs will display like the page
detailing a single TODO. This is misleading. Instead, use the same
approach as the index page, where the user is automatically redirected
to the appropriate project's page when only one project exists.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
Stephen Finucane [Thu, 18 Feb 2016 15:59:02 +0000 (15:59 +0000)]
tests: Remove check for 'tbody'
As part of 'f8cc68', the response for the patch list page changed
slightly. This means one of the things we were checking in a test is
no longer valid. Remove this check.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
The Django documentation suggests using environment variables as a way
to allow devs to commit settings files via source control without
including confidential information therein [1]. As such, change the
provided 'production' settings to do this. This should promote best
practices while also ensuring provisioning tools like
'ansible-django-stack' [2] work as expected.
The existing deployment could do with a little bit of fleshing out.
Do this, adding notes about the possibility of sidestepping much of
the process using deployment tools or PaaS solutions.
This also drops notes on deploying using MySQL/MariaDB or non-Ubuntu
distros. While it would be good to cover all use cases, it simply
isn't practical. Do one thing and do it well, providing notes for
users who want other options.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Suggested-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Stephen Finucane [Wed, 10 Feb 2016 19:41:55 +0000 (19:41 +0000)]
docs: Combine MySQL init/reinit instructions
Apply some learnings for the Vagrant work and combine the commands used
to configure a MySQL database for first time use with those used to
reset an existing database. This should simplify installation.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
vagrant: Add Vagrant-based development environment
Integrate Vagrant by way of a Vagrantfile and a simple install script.
This follows many of the instructions found in the development guide
with the exceptions of the superuser creation, which is optional, the
loading of archives, which requires per-user authentication, and the
use of virtual environments, which are unnecessary in a teardown
environment such as this.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
Stephen Finucane [Wed, 10 Feb 2016 19:58:47 +0000 (19:58 +0000)]
requirements: Remove psycopg2
It would be good to provide the required packages for devs using both
MySQL and PostgreSQL. However, there does not appear to be any way to
specify an exclusive-or condition in pip requirements files and the
existing behavior of including dependencies for both RDBMSs means
system packages have to be installed for both, when you are likely
only using one. This is particularly problematic when you want to
set up a fast dev environment using something like Vagrant.
Settle on MySQL for now, until such a time as the consensus is to go
all-in with PostgreSQL (including docs, for example).
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
Damien Lespiau [Sun, 20 Dec 2015 03:53:53 +0000 (03:53 +0000)]
ui: Switch to HTML5 doctype and fix issues
A few common things:
- Remove the 'role' attribute of <nav>
- Don't use the self closing syntax ('/>') on non void elements
- Don't use the language attribution in <script>
- Remove spurious attributes
- The 'check' attribute of <input> doesn't take any value
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Stephen Finucane <stephen.finucane@intel.com>
Damien Lespiau [Fri, 18 Dec 2015 17:34:29 +0000 (17:34 +0000)]
ui: Merge the TODO list into the user dropdown
We still leave the badge on the top bar so we can see, at a glance, the
number of items on the TODO list. The actual menu item is folded into
the dropdown.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Stephen Finucane <stephen.finucane@intel.com>
Damien Lespiau [Mon, 14 Dec 2015 18:04:23 +0000 (18:04 +0000)]
ui: Let the bootstrap inverse navbar style shine through
Time for another iteration of the design. Let's start by using the
inverse bootsrap style with a slightly whiter color for font for better
contrast.
That color change has repercussions in the style sheet, mostly in the
custom containers/boxes we're still using on the secondary pages
(login/register/...)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Stephen Finucane <stephen.finucane@intel.com>
I'm really not anything of a UX designer, nor a native speaker, but I
can try to make tools a bit less 'dry'. 'Number of patches' would have
worked as well, but opted for a shorter one.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Stephen Finucane <stephen.finucane@intel.com>
Damien Lespiau [Mon, 1 Dec 2014 15:07:28 +0000 (15:07 +0000)]
ui: Move the background color of the table headers to a class
As we are using "sticky headers", the column headers stay apparent when
scrolling down, we need to specify a white background to hide what's
underneath.
With the addition of Seres, the patchlist table is not the only table we
want this behaviour on, so let's make it a CSS class rather then a
selector on the patchlist id.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Stephen Finucane <stephen.finucane@intel.com>
Damien Lespiau [Mon, 26 Oct 2015 08:17:09 +0000 (08:17 +0000)]
ui: Don't allow to the date to wrap
When rendered on smaller screens, the mininum column size for the date
was reached and the text was wrapping. We can force it to not wrap with
white-space: nowrap; and bootstrap already includes a convenient
text-nowrap class.
v2: Extend the use of 'text-nowrap' to existing classes
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Stephen Finucane <stephen.finucane@intel.com>
The example "production" settings expect a PostgreSQL database backend,
yet the requirements file for the same scenario install MySQL
dependencies. Correct this mismatch.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
The map function doesn't return a list in Python 3, which means it
can't be used like one. Many of these issues were previously resolved
but there were some uncovered code paths. Resolve these, adding tests
to ensure it doesn't regress.
In addition, change what's serialized and returned. Instead of
returning a subset of the serialized values, only serialize a subset
of the original values. This means n items are serialized instead of
max.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
Thomas Monjalon [Sat, 30 Jan 2016 15:34:34 +0000 (16:34 +0100)]
models: Allow to unselect maintainer projects in user profile
The admin page for user profiles have a field "Maintainer projects"
to grant maintainer rights to an user. It is a list of available
projects. When a project was selected, it was impossible to revoke.
It is now possible to unselect by clicking while holding the "Ctrl"
key.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com> Acked-by: Stephen Finucane <stephen.finucane@intel.com>
There are two distinct types of documentation available: documentation
for patchwork developers and documentation for patchwork deployers.
Rework the mkdocs configuration such that this hierarchy is
established.
As part of this change, the installation doc is renamed to deployment.
This guide should be used to install patchwork in a production
environment and not necessarily a deployment one. The existing name
was misleading so fix it.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
patchwork has undergone a number of changes recently that can make
deployment of a development environment much simpler than it was
previously. Unfortunately, these were not illustrated in the
documentation. Resolve this oversight by rewriting the developer guide
to reflect, for example, the usefulness of the 'parsearchive' script or
the fact that environment variables like 'PW_TEST_DB_USER' do not
always need to be exported.
This includes changes to the provided 'default_projects' fixture: the
existing projects weren't chosen for any particular reason and the
rewritten guide expects a 'patchwork' project to exist.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
The guide details the general pitfalls such users may encounter when
upgrading a patchwork. Upgrading older deployments of patchwork,
particularly those that are pre-1.0, can be a daunting task and this
guide should support users in this task. However, it should not
replace the UPGRADING document but rather supplement it with more
general, non-version specific advice.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
This guide serves to illustrate import aspects of patchworks release
process: when, why and how. It also serves as a helpful reminder for
the maintainers themselves.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
This guide details the steps one should follow to submit patches for
patchwork. It's nothing onerous but rather common sense. This requires
moving the testing section from the development guide to this new
document.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
Stephen Finucane [Thu, 28 Jan 2016 11:34:17 +0000 (11:34 +0000)]
docs: Add a README
This is mostly a copy/paste of 'index.md' with added badges. This will
be useful to provide an overview to people who stumble upon patchwork
on GitHub.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
Stephen Finucane [Mon, 24 Aug 2015 13:21:43 +0000 (14:21 +0100)]
Allow assigning of any user as delegate
Currently, Patchwork only allows to delegate patches to developers who
are registered as "maintainers" of the project in Patchwork or set up
as autodelegate "targets". This is a bit annoying as "maintainers" in
the Patchwork sense have the power to change the state of *any* patch.
Allow delegation of patches to developers who are not the submitter of
the patch in question, a maintainer of the project or an autodelegate
"target". This request is documented here:
Stephen Finucane [Mon, 24 Aug 2015 10:05:47 +0000 (11:05 +0100)]
Add delegate filter autocomplete support
It would be helpful to provide autocomplete functionality for the
delegate filter field, similar to that provided for the submitter
field. This will provide a way to handle larger delegate lists without
overloading the user with options.
Add this functionality through use of Selectize, which is already used
to provide similar functionality for filtering of "submitters".
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
Reversing by Python paths has been deprecated in Django 1.8, causes
warnings in Django 1.9 and will be removed in Django 2.0. Resolve the
warnings and prevent issues in the future by importing by module
instead.
Reversing by Python paths has been deprecated in Django 1.8, causes
warnings in Django 1.9 and will be removed in Django 2.0. Resolve the
warnings and prevent issues in the future by referring to URLs by name,
rather than by Python path.
Reverse by name is an alternative to reverse by Python path. The names
must be added as a prerequisite for removing reverse by Python path,
per Django documentation.
This is a collection of unrelated functions, many of which belong in
their own file. Do this, taking the opportunity to rename some of these
functions to better indicate their purpose in the process.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
When a patch is delegated, it can be important to report it via
pwclient, as handing delegated patches may be different. So, add
an optional field at the email's body if this is happening.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Suggested-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
When things are broken at parsemail, we need to be able to
debug it. So, add some messages to it, in order to allow
checking what it actually did, and to let it return 1 if
an email got skipped by parsemail.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
Laurent Pinchart [Sat, 28 Nov 2015 12:14:40 +0000 (10:14 -0200)]
forms: Allow the delegate field to keep its current value
When a patch is delegated at parse time (either through the
X-Patchwork-Hint mail header or through delegation rules), the delegate
might not be in the list of project maintainers.
Add the current delegate to the list of acceptable values for the
delegate field to allow the current value to be kept when editing the
patch.
Stephen Finucane [Thu, 17 Dec 2015 17:29:32 +0000 (17:29 +0000)]
parsearchive: Handle duplicates
The parsearchive tool can be used to load missing messages sourced
from mailman or another source. In this use case, there's a good
possibility that at least some of the messages found in the archive
are already stored in patchwork. Handle this case by ignoring these
duplicates.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
projects / thirdparty / patchwork.git / log
