1. 01 Apr, 2016 3 commits
  2. 18 Mar, 2016 1 commit
  3. 17 Mar, 2016 6 commits
  4. 11 Mar, 2016 1 commit
  5. 03 Mar, 2016 1 commit
  6. 29 Feb, 2016 1 commit
  7. 22 Feb, 2016 3 commits
  8. 18 Feb, 2016 3 commits
  9. 17 Feb, 2016 1 commit
  10. 25 Jan, 2016 4 commits
  11. 22 Jan, 2016 1 commit
  12. 20 Dec, 2015 1 commit
  13. 17 Dec, 2015 3 commits
  14. 04 Dec, 2015 2 commits
  15. 19 Nov, 2015 1 commit
    • Stephen Finucane's avatar
      testresult: Add Test and TestResult models · 5ae002be
      Stephen Finucane authored
      The idea is to store test results in patchwork itself so the series and
      patch pages can show a summary of the testing done.
      Tests are defined per-project, so they can be administrated at the
      project level (eg. configure the mailing policy).
      We only store one test results per test, the latest state updated by the
      testing system.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
  16. 09 Nov, 2015 2 commits
  17. 07 Nov, 2015 1 commit
    • Damien Lespiau's avatar
      project: Allow multiple projects to share the same mailing list · 33f4ed4b
      Damien Lespiau authored
      I have the case where contributions for several git repositories are
      sent to the same mailing-list. We really want to handle them separately
      though, some of the repos have different maintainers for instance.
      An easy way to solve that is to ask people to add a special tag in
      subject prefix of patches. It's can even be sticky to a specific git
      checkout with:
        $ git config format.subjectprefix "PATCH evdev"
      So people don't have to remember to tag their submissions by hand.
      Those tags are stripped out of the patch name because they are redundant
      information with the project they are now in.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
  18. 03 Nov, 2015 1 commit
    • Damien Lespiau's avatar
      models: Don't query a related field in __unicode__ · 6714f34d
      Damien Lespiau authored
      Turns out that str(object) is used when putting 'object' in the
      template context. Because of revisions __unicode__ was using series.name
      we were doing as many queries as revisions in the detailed series page,
      without actually using that string representation anywhere.
      Because the string representation of SeriesRevision is not very useful,
      let's just get rid of that query altogether.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
  19. 25 Oct, 2015 1 commit
  20. 23 Oct, 2015 1 commit
  21. 20 Oct, 2015 2 commits
    • Damien Lespiau's avatar
      series: Add a 'new-series-revision' event · 7f201e2d
      Damien Lespiau authored
      We create a new log entry when a new series revision appears.
      The series_revision_complete event only fires when the series/revision
      is fully complete, eg., the git send-email series has been fully
      processed. That behaviour is tested, making sure an incomplete series
      doesn't appear in the SeriesLog table.
      v2: Rebase on top of SERIES_DEFAULT_NAME changes
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
    • Damien Lespiau's avatar
      models: Add Event and EventLog models · 1fe6ec24
      Damien Lespiau authored
      I'd like to be able to track the history of manipulations done on series
      (and probably its patches as well). To start with, I'm only interested
      in when series are created so I can export a RSS feed containing the
      new series.
      For the curious mind, a full event table for just one field seems a bit
      overkill. I have to mind to attach more properties to events. For
      instance link a state to an event so we can generically set the state of
      a series/patch when a certain event is created.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>