Age | Commit message (Collapse) | Author |
|
|
|
|
|
These clearly had little to do with reality since they would return
duplicate entries if a patch was in more than one cf..
|
|
This is particularly interesting towards the end of a cycle where it can
be used to flag patches that are not intended for the current version
but still needs review.
|
|
|
|
|
|
|
|
|
|
|
|
By popular (?) request
|
|
We've long gone past what the django ORM can handle and got into
hundreds of queries for large commitfests. And it's not really that hard
to rewrite as SQL, even though we have to dynamically build the WHERE
clauses. So do that.
|
|
Both had a default set to '', so also put that in the model. Needed to
give correct diffs in newer djangos
|
|
|
|
Userprofiles aren't set for everbody, so catch a missing exception and
just ignore it since we know a user without a profile didn't specifically
ask to get notified (as that's stored in the profile).
|
|
This makes it possible to receive notifications (via email) when a patch
has been updated.
It's possible to subscribe to notifications on a specific patch. It is also
possible to set the user profile up so that one receives notifications for
all patches where one is author, reviewer or committer on.
Notifications are, of course, only sent when other people make modifications
to the entry.
|
|
Newer djangos give warnings about this...
|
|
Somehow this worked on 1.4, probably by accident
|
|
Per request
|
|
feedback"
Returned with Feedback will now actually close the patch and *not* move it to
the next CF. Since it used to do that, all existing Returned with Feedback patches
are changed to Moved to next CF which does the same thing that Returned with
Feedback used to do. And of course, Moved to next CF is a new option available for
each patch from now on.
|
|
This highlights the different statuses better in a long list.
|
|
This feature makes it possible to "pull in" a message in a thread and highlight
it with an annotation (free text format). This will list the message in a table
along with the annotation and who made it.
Annotations have to be attached to a specific message - for a "generic" one it
makes sense to attach it to the latest message available, as that will put it
at the correct place in time.
|
|
Noted by Stefan - we did this for everything except the patch history, so
let's make it consistent.
|
|
|
|
Quick overview of how many patches are in each status, as exist on
the old app.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This tracks all the emails that are sent on a patch. Note that this
currently only picks up emalis when the attach thread function is used,
since there is no cronjob that fetches this data yet. When that job
is added, it should also update this field.
|
|
This weill eventually get exposed as some sort of API for a buildbot,
but we might as well track it and show it on the website already now.
|
|
|
|
|
|
|
|
May very well do a complete rebase later to get rid of history
|