On 26/05/16 14:06, Jeremy Stanley wrote:
On 2016-05-26 11:37:18 +0100 (+0100), Zara Zaimeche wrote:
[...]
Updating the bug/task-tracker from those changes, however, would
be different for each tracker, so you wouldn't be able to do that
part in a generic way. Plus, while analyzing the data from the
stream could theoretically be the same, in practice different data
might matter for each tracker, and one might be looking for a
different regex in the commit message, etc. So I think the only
part that can be generic will be getting the changes from gerrit,
and from other comments on this thread, it sounds as though people
have already covered that.
I'd imagine things like regular expression matches and API methods
could be extracted into configuration (as long as we make
assumptions like the task tracker APIs are all RESTish and don't
require fancy branching business logic). So a rules engine which can
be configured to tokenize parts of specified Gerrit events and then
expand corresponding variables in configured API calls would
presumably fit the bill.
I agree regexps should definitely be extractable. I'm less sure about
API methods; some general things I've noticed in discussion of task
trackers are:
* The APIs seem to often be a muddy spot (I hear complaints about how
they're not as RESTful as desired)
* Trackers designed to work on a small scale have a very different
architecture from those designed to span multiple repos
So the first point there makes me wonder how safe we are in assuming
tracker APIs are all RESTish. The second makes me wonder how far a
generic implementation can go, or whether it'd be better to have
different implementations for cross-project bug/task-trackers vs single
project bug/task-trackers. (eg: the contrast between StoryBoard and
Github issues)
The latter tend not to, say, distinguish between stories and tasks,
which makes sense when the tracker doesn't have to worry about
coordinating cross-project work. But if someone writes middleware that
assumes stories and tasks are the same thing in a tracker, it requires
some fiddling to make it work for StoryBoard, possibly to the point
where it's easier to implement a custom thing from scratch. From my
perspective, there's a good chance that something designed initially for
Github Enterprise won't have much I can use-- which is still fine; we
were just asked if we'd find it useful. :)
StoryBoard is the unusual one here, and I think a lot of teams with
smaller trackers will find their architecture similar enough for it to
work for them. And maybe it's possible not to make those assumptions,
but I figure if I flag it up, it's easier for people to know what
assumptions they're making, and choose an approach from the start.
Best Wishes,
Zara
_______________________________________________
OpenStack-Infra mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
