[Patchew-devel] [PATCH v2 03/12] Generalize Review model to Queue

[Paolo Bonzini]

On 29/11/18 13:41, Fam Zheng wrote:
> On Wed, 11/28 18:16, Paolo Bonzini wrote:
>> On 28/11/18 17:57, Paolo Bonzini wrote:
>>> On 28/11/18 15:34, Fam Zheng wrote:
>>>> From: Fam Zheng <famz at redhat.com>
>>>>
>>>> The concept of a queue is a per-user model for maintainers. A maintainer
>>>> can have one ore more queues. The current Review model already has
>>>> accept and reject stautus, so we generalize that to support a more
>>>> flexible queue feature.
>>>>
>>>> Previously, "mark as accepted" adds a (user, message, accept=True)
>>>> record in the Review model. Now it adds a (user, message, name='accept')
>>>> record in the Queue model.
>>>>
>>>> Similary, for 'mark as rejected', a (user, message, name='reject')
>>>> record is added in the Queue model.
>>>>
>>>> This makes the two queue names specially purposed on the web interface
>>>> and search terms, which we'll extend to also support normal queues.
>>>
>>> Can you rename this to QueuedSeries?  Apart from this nit, I'm totally
>>> okay with the series!
>>
>> Meaning - I still am not sure about the presentation of /my-queues, but
>> I understood why you did that way (I do believe that, given the current
>> functionality, a per-series view is more useful, on the other hand most
>> of the time ack:me/nack:me/maint:me would be enough so your per-message
>> view can be useful too).  Probably having _both_ message-list and
>> series-list views would be the way to go.  In any case it doesn't have
>> to block the functionality and I'd like this to be included in the next
>> deployment to patchew.org; we can look later at improving it later and
>> the basic database concepts are already fine like this.
> 
> What about add "queued" and "queued:xxx" search terms so that we can reuse the
> series-list page for that view?

That could be enough, though it would show only one queue rather than
all of them.  I think we can look at it after you commit this first
version, however.  Release early. :)

>> Maybe we'll add a first-class Queue model, in case we need something
>> more than (user, name); maybe we'll augment Patchew with per-message
>> tweaking and need a QueuedMessage model[1].  Either way it should be
>> easy to write a Django migration to populate them.
> 
> QueuedSeries alone can be sufficiently extensible even for the use cases of
> dropping and tweaking individual patches. I'll try to come up with a new model
> in the next version.

Again, let's not strive for perfection.  If it's not strictly necessary
to do it now, let's leave this kind of change for later.

In particular, before having tweaks, it's more important to have support
for applying an entire queue easily, IMO.  I created a kind of "roadmap"
at https://github.com/patchew-project/patchew/issues/101.  Feel free to
edit it according to your own views!

Paolo