Source control integration
First, let me say that what you have going here is awesome. You've obviously spent a lot of time thinking things through. The flow of the app is great. The main thing missing for me is source control integration (svn, git, github).
I have used two ticket systems thus far--trac and lighthouse. Trac is dog ugly but I like the syntax they use better. Basically on any commit, you can put Fixes #123 where 123 is the ticket number that needs to be closed. You can also say Refs #123 and it will not close the ticket but instead just reference the commit in a comment on the ticket. The last thing that is handy about trac is you can specify multiple tickets to fix and ref like so: Fixes #123, #132 and #156. If you fix a few small bugs in one commit you can close all the related tickets at once. The multiple ticket support is not essential but it is handy.
Lighthouse has an aesthetically pleasing UI but I find parts of it very confusing functionally. That said, it is my current choice as there isn't anything better for what I need. They have a bit different syntax for updating tickets from a commit. As far as I can tell they do not support updating multiple tickets at once either (if they do I couldn't figure it out). To close a ticket, you simple add something like [#123 state:resolved] to the commit and lighthouse will do the rest. Syntax like this is powerful because it also allows adding tags and such but I find that I rarely use that power. I just want a simple way to close a ticket or reference it from my commit message.
SCM integration for me is all about referencing a ticket and closing a ticket from commits. I don't need to be able to see all the commits in Sifter as Lighthouse does. Simply making the commit message a comment and updating the state of the ticket is plenty.
So that covers syntax but not necessarily how to integrate it with sifter. You definitely don't want to start doing subversion and git commands to pull in updates for all the projects. I would just implement an API for sifter and allow developers to build the tools that use the post commit hooks that subversion and github already have, to post to the API (trust me they will).
Ideally, as a user, I could create multiple API keys for a project (and name each key). You could then use a unique key for each app that needs to integrate with a Sifter project. Then, if you stop using an app, you can kill access for that app by simply inactivating that key in Sifter. If the other app tried to do anything after you inactivated the key, they would just be denied.
Obviously you could go crazy with API features for this but I would start simple. For the first iteration of the API, I would implement a way to get all tickets, tickets filtered by one or more states and an individual ticket. The only other API call that would be essential in the first iteration is the ability to add a comment to a ticket that would function identically to the web interface. An API with only these calls would be enough to do some serious integration with source control systems and github.
Hope this helps.
I have used two ticket systems thus far--trac and lighthouse. Trac is dog ugly but I like the syntax they use better. Basically on any commit, you can put Fixes #123 where 123 is the ticket number that needs to be closed. You can also say Refs #123 and it will not close the ticket but instead just reference the commit in a comment on the ticket. The last thing that is handy about trac is you can specify multiple tickets to fix and ref like so: Fixes #123, #132 and #156. If you fix a few small bugs in one commit you can close all the related tickets at once. The multiple ticket support is not essential but it is handy.
Lighthouse has an aesthetically pleasing UI but I find parts of it very confusing functionally. That said, it is my current choice as there isn't anything better for what I need. They have a bit different syntax for updating tickets from a commit. As far as I can tell they do not support updating multiple tickets at once either (if they do I couldn't figure it out). To close a ticket, you simple add something like [#123 state:resolved] to the commit and lighthouse will do the rest. Syntax like this is powerful because it also allows adding tags and such but I find that I rarely use that power. I just want a simple way to close a ticket or reference it from my commit message.
SCM integration for me is all about referencing a ticket and closing a ticket from commits. I don't need to be able to see all the commits in Sifter as Lighthouse does. Simply making the commit message a comment and updating the state of the ticket is plenty.
So that covers syntax but not necessarily how to integrate it with sifter. You definitely don't want to start doing subversion and git commands to pull in updates for all the projects. I would just implement an API for sifter and allow developers to build the tools that use the post commit hooks that subversion and github already have, to post to the API (trust me they will).
Ideally, as a user, I could create multiple API keys for a project (and name each key). You could then use a unique key for each app that needs to integrate with a Sifter project. Then, if you stop using an app, you can kill access for that app by simply inactivating that key in Sifter. If the other app tried to do anything after you inactivated the key, they would just be denied.
Obviously you could go crazy with API features for this but I would start simple. For the first iteration of the API, I would implement a way to get all tickets, tickets filtered by one or more states and an individual ticket. The only other API call that would be essential in the first iteration is the ability to add a comment to a ticket that would function identically to the web interface. An API with only these calls would be enough to do some serious integration with source control systems and github.
Hope this helps.
23
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?This is definitely one of our higher priorities, and this really helps provide some food for thought as we start designing how the process will work.
I’m anxious
The company thinks
this is one of the best points
-
Inappropriate?Would be great if you could configure a source-control end-point url like http://svn.domain.com/view.php?id= and translate r123 into a valid link.
-
Just to make sure I understand the suggestion, you're talking about updating a setting within Sifter and then enabling the ability to link externally to view a revision?
This is definitely something we'll keep in mind as we're digging into the API, and ultimately source control integration, right now. Obviously, this wouldn't need the API, but we'd really like to make sure the solution encompasses the whole thing.
For instance, if you could resolve issues with commit messages and not even have to login to Sifter, Sifter could automatically create the link out to the revision. We also have thoughts around submitting patches and how it would all fit together.
Anyhow, this is a great suggestion and something we'll be keeping in mind. Thanks! -
Yes something like this:
"I think this is a duplicate of i23 which was fixed in r56"
would translate into
"I think this is a duplicate of #23 which was fixed in r565
What's elegant about this solution is that you can easily connect Sifter with GitHub, a Trac installation or SourceForge without having to implement connectors to each of these within Sifter itself, you simply configure the URL of each project, or you could even have a list of templates for commonly used sites/software.
Resolving issues with commit messages is nice but it's important to keep in mind that if the connected source control system is slow or far away things will slow down considerably.
Lighthouse had a similar function in which we created a post-commit-hook that would POST a request to the app and close the ticket along with the commit message, this is perhaps worth looking into. -
You bring up some good points that it's not always just about resolving issues so much as tying things together.
I definitely like the linking, and I've already been thinking about having Sifter be smarter with links to external tools like Github, Pastie, Beanstalk, Exceptional, Hop Toad, etc. However, those ideas have all been around recognizing pasted URLS and turning them into prettier links like the issue links. I do really like the idea of enabling the ability to do this by using a revision/commit number like you described.
I'm not quite as excited about adding extra configuration within Sifter. This would likely need to be a project-based configuration setting because projects would be using different source control locations, and I really prefer for this kind of thing to be as invisible as possible.
I'll be giving it more thought. I just really want to make sure we put together a holistic solution that works with the least amount of extra configuration. I'm not sure that there's a way we could get around the configuration here, but that doesn't mean I won't try to find one. :) -
Inappropriate?Is there any update on this? I am about to commit (no pun intended) to a new bug/issue/feature tracker and source control integration is a necessity.
I prefer Sifter over Lighthouse at the moment, but lack of source control integration is keeping me from choosing it.
And migration at a later stage from one app to another (e.g. Lighthouse -> Sifter) is highly unlikely as we would want to retain historical data. -
Shane, I'm really sorry about the slow reply. I thought I had replied to this this morning, but I guess it never went through.
I'm sorry, but there isn't an update yet. It's something we plan on supporting eventually, but at this point we can't make any promises on when that will be.
I completely understand, and we're acutely aware of the number of people that want this feature. (Ourselves included.) -
Inappropriate?FYI. The one thing that is holding me back from adopting Sifter is the lack of source code control integration.
Ideally, I'd like to see integration with Beanstalk and Github.
-
We've begun work on the API this week, and we've already talked to the Beanstalk team about integration. While we haven't spoken with Github yet, we'd definitely like to integrate with them as well. -
Inappropriate?any news on this issue?
-
We're in the middle of working on the API right now. That's the first step before we can really integrate with anything. We've also started talking to some of the hosted source control services. It's underway, but we likely won't have any more news until it's live. -
Inappropriate?when are you hoping to go live with the API?
-
We're not sure at this point. We're planning on just going live with it when it's ready, but we won't have any more info until then. -
Inappropriate?I need the API to update ticket status through GIT post-commit hook's commit message. Pretty please Sifter, I will love you forever.
I’m happy
-
We're definitely on it, and it's our highest priority for new features. We don't have a date estimate yet, but we're all over it. -
Inappropriate?Just wanting to add that this feature would be crucial for making my decision between Sifter and Lighthouseapp. In particular we need a Service Hook on github.com.
I’m undecided.
-
We're all over it. The API is the gating factor, and that's where we're focusing 110% of our development time right now. -
Inappropriate?Can we expect this thing to release anytime soon? My superiors want to purchase service from either your competitor or sifter depending on whether we can integrate ticket updates through git commit hooks.
-
We don't have a date or even a specific timeline. All we can really tell you at this point is that it will be out when it's out.
Loading Profile...




EMPLOYEE



