> On Wed, Sep 23, 2015 at 10:14:05PM +0100, Finucane, Stephen wrote:
> > > So it does mean my assumption was correct, eg. 'intel/license-check'
> > > will be repeated for every patch. Hence abstracting a Test table we can
> > > use for good.
> >
> > Yes, but the context does not imply that the
On Wed, Jul 29, 2015 at 09:58:42AM +0100, Stephen Finucane wrote:
> +class Status(models.Model):
> +"""Status for a patch.
> +
> +Statuses define a state for patches. This is useful, for example,
> +when using a continuous integration (CI) system to test patches.
> +"""
> +
> On Wed, Jul 29, 2015 at 09:58:42AM +0100, Stephen Finucane wrote:
> > +class Status(models.Model):
> > +"""Status for a patch.
> > +
> > +Statuses define a state for patches. This is useful, for example,
> > +when using a continuous integration (CI) system to test patches.
> > +
On Wed, Sep 23, 2015 at 06:14:13PM +0100, Finucane, Stephen wrote:
> As such, can you explain what advantages the above proposal would
> introduce over the existing proposal? What does i915 need to do
> differently? If not, I'd like to rework the patch per existing
> comments (i.e. renaming
> On Wed, Sep 23, 2015 at 08:04:26PM +0100, Finucane, Stephen wrote:
> > * Context is a non-unique name used to distinguish different tests (in
> > the broader sense). Examples would include: intel/license-check,
> > intel/unit-tests, dpdkorg/unit-tests/module1,
> > dpdkorg/unit-tests/module2.
> >
Hi Stephen,
Thanks for your good work.
2015-07-29 09:58, Stephen Finucane:
+class Status(models.Model):
+Status for a patch.
+
+Statuses define a state for patches. This is useful, for example,
+when using a continuous integration (CI) system to test patches.
+
There is
From: Stephen Finucane stephenfinuc...@hotmail.com
This will represent the status of a patch. This includes a suitable
migration and admin view.
Signed-off-by: Stephen Finucane stephenfinuc...@hotmail.com
---
lib/sql/grant-all.mysql.sql | 5 +--
lib/sql/grant-all.postgres.sql
2015-07-29 13:33, Finucane, Stephen:
Having State and Status is confusing.
What about getting rid of State? :) I haven't found any public patchwork
project that modifies the default list of states, so I think a static
choices field on 'Patch' would be a better option. I actually have a
2015-07-29 09:58, Finucane, Stephen:
2015-07-29 09:58, Stephen Finucane:
+class Status(models.Model):
+Status for a patch.
+
+Statuses define a state for patches. This is useful, for
example,
+when using a continuous integration (CI) system to test patches.