Extension suggestions

[Soho]

Having hacked together an issue tracker extension I was left quite disappointed with the level of ambition when it comes to issue tracker integration in Plastic.

Here are a few, in my mind obvious, features I actually expected to find in the API, but to my surprise didn't find.

Create branch from ticket

I was surprised that I could not create a branch from a list of tickets. Instead I have to use a branch name convension to link my branch to a ticket. It should be trivial to extend the extension API with a "load tickets" method and present the list of tickets when creating a branch. How to select the tickets to be shown could be a matter of extension configuration. This could be made even better if the API could make the extension provide a list of filters to choose from.

It is not that it is a big issue to use the branch naming convension, but it would allow a more smooth workflow if the list of tickets was integrated with branch creation.

Two way state synchronization

I was also surprised that the extension seems to be a one way system with no support for adding states or comments to the ticketing system.

I had expected to find a "hook" to branch switching or creation. That way it would have been possible to change ticket state from say "new" to "open".

If the ticket properties, especially state, were synchronized with Plastic attributes, it would provide a very convenient way of filtering branches when integrating completed tasks for a build.

If there was a "hook" for changeset comments, changeset comments could also be added to the ticket comments. This would provide possibilities for a detailed change log.

Two way states and events on commits, branch switches, etc. is what I miss the most.

Caching

I would benefit performance if every branch explorer refresh didn't caused a complete loading of all issue tracker tasks in view. You might expect the branch explorer to attempt a refresh if you hit the refresh button, but it the refresh fails, for example if you are offline or the ticket server for some reason is not available, then all your ticket titles disappear. This is a problem if you have adopted a ticket id branch naming scheme. It would be better, if Plastic cached tickets and only replaced titles if a new was actually loaded. Also, why is the extension asked to load a ticket both by the branch explorer and when clicking on a branch?

I do however realize that the extension could do such caching by itself, but it would be easier to develop extensions if such behavior was implemented in the calling system.

Repository mapping

I found the repository to ticket system project mapping a little clumpsy in the API. E.g. when refreshing the branch explorer, the extension is asked to load tickets for all visible branches, but with the empty string as repository name. Only when clicking on a branch, the repository name is provided. There is probably an explanation, but it made it hard to map repositories with projects in the ticketing system. This is a problem for ticketing systems like YouTrack, where the project name (in short form) is part of the ticket ID and IDs within projects are sequential (i.e. non-unique globally).

Auto comments

In Plastic preferences you can setup auto-comments. You can choose between user name and date. This is almost entirely useless since that information is already baked easily available.

When using build servers like TeamCity, you get some nice links to your ticketing system if you refer to ticket id's in the comments. A typical workflow is making a solving a bunch of tickets and then integrating the branches in a build branch that the build server will use to generate a new build. In the process of integrating branches, it would be helpful if the comments automatically the ticket ids, since this would make a full circle between the VCS, Build server and ticketing system. Manully entering these comments is tidious and error prone, since it is often only a matter of repeating branch names and ticket titles.

It would be nice if the "custom" auto-comment formatter was extended more tags. Most obvious are branch name, ticket title, ticket id, ticket description.

This is all that comes to my head right now. In general I was disappointed with the issue tracker integration in Plastic. TFS or Github is better at this.

I know that the Plastic development team is not one of the largest, but it should be fairly easy just to add a few more hooks to the extension API and leave to the community to develop extensions.

In general I think Plastic would benefit if the dev team concentrated on the core VCS and opened up for community development of all third part integrations. For example I have had about a hundred issues with the Visual Studio plugin. Something I probably would have wasted less time on, if I had been able to fix some issues myself.

[psantosl]

Soho,

Thanks for the suggestions.

Definitely opening up the extensions would be something really useful. The thing is that we should make the core GUI stronger too, in order to be able to provide more options such us "autobranch creation" as you say. Don't remember now if our extensions give you any chance to do your own rendering. If so, it would be totally possible to add the "create branch button", for instance.

Regarding two way: our JIRA and other extensions are able to put info on the issue tracking system. Is that what you mean?

Regarding caching: we try to avoid it as much as we can, but less than we should. If I cache something on the BrEx, then the graphic would certainly be out of sync with the issue tracker at some point. But, requesting info from the issue tracking turned out to be amazingly fast so far. Why is it slow for you?

Thanks for all the great ideas!

[Soho]

About two way

As far as I have been able to reverse engineer, I can see that I can hook-up on check-in events. That would be useful for submitting comments, but then again changeset comments might not what I want to have submitted to the issue tracker. There are also some hooks for changeset based integration, but it is very limited what you can do with basic branching mechanics.

I still have a workflow like this in mind:

• You want to pick a new work ticket and start working.
  
• You open Plastic and bring up the "New tickets" dialog.
  
• You choose a ticket and click "Create new branch for ticket".
  
• Plastic now creates a new branch following some naming customer naming formatting (E.g. "{tickedId} - {ticketTitle}").
  
• Plastic notifies the issue tracker that the ticket has been opened by the current user.
  
• Plastic automatically switches to that ticket.
  
• You work on the task and eventually complete it.
  
• You open Plastic again and choose "Complete current branch".
  
• Plastic marks current ticket as fixed in the issue tracker.
  
• Plastic switches to the parent branch and perform a merge from the ticket branch.
  
• Plastic uses some customer format for creating the merge comment. E.g. "{tickedId} - {ticketTitle} completed".
  
• You review and test the merge and commit it, which triggers a new build on the build server.
  
• You start all over.
  

[Soho]

about caching

The BrEx uses titles from the issue tracker. Those titles are not likely to change very often, BrEx tries to reload everything quite often. Requesting titles might be fast for you because your issue tracker is installed locally, but these days cloud-installed issue trackers are becoming the norm and the cloud loaded tasks may turn out slow or chunky when 10s of tasks have to be loaded every time you scroll a little or whatever triggers a reload.

I would prefer that a reload was done when the refresh button was hit, and that refreshing did an actual refresh of the titles one by one, not a "remove all titles then load then again".

Also I have Plastic installed on my laptop and sometimes (daily) I am not on our LAN where our issue tracker is currently or even on the internet and in that case I can only see the task ID's in the branch names so I have to remember what task CFC-4321 was all about.

I know I request a lot of features from a small company like yours, but I think that emphasizes that you should consider prioritizing open APIs very high and let the community deal with all the third part stuff so you can concentrate on the framework.