On 10/20/2016 02:23 AM, Stephen Finucane wrote: > On 2016-10-19 18:09, Andy Doan wrote: >> On 10/18/2016 03:12 PM, Stephen Finucane wrote: >>> Provide a way for users to get a list of events they may be interested >>> in. This case be useful for CI systems or for general use in a ticker >>> or similar system. The following events are supported now: >>> >>> - Patch Created >>> - Patch Dependencies Met >>> - Delegate Changed >>> - State Changed >>> - Check Added >>> >>> The following events are not yet supported, as they would require >>> further database changes or not deliver tangible value: >>> >>> - Bundle Created/Changed >>> - Comment Added >>> - Tag Added >> >> This is a really cool. Two things: >> >> 1) I'm not sure I see the need for the "user" field? Events like Check >> Added and Patch Created already have a User associated with the target >> object. So I might say - don't bother with the user field until we see a >> need for it. > > Do I still have that? Yeah, it can be dropped. The idea was to record > who exactly caused the event, i.e. who changed the patch status, but I > can't do this using signals and ROI isn't significant enough to changing > this. I'll remove for the final version. > >> 2) Can you elaborate on how you plan to expose this data? ie something >> via REST? > > I've been thinking an '/events' API endpoint for now. This would require > polling from CIs etc., but it would be a good first step.
Makes sense to me. If we had a /events?created_on__gte=TIMESTAMP, the API could be used fairly efficiently. _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
