Open Stack

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