On Thu, Sep 27, 2012 at 11:19:34AM +1000, Justin Clift wrote:
Note - I've removed aeolus-devel from this, because I'm including links to internal things.
On 27/09/2012, at 3:23 AM, Hugh Brock wrote:
<snip> > I have a radical suggestion I would like to throw out for comment: > > I was talking to Matt Hicks the other day, of OpenShift, and he claims > they are moving *their entire agile setup* to GitHub. Basically they're > going to ditch stories in Rally and move them to the GitHub issue > tracker instead.
Interesting. As a data point, saw this last night in their recent archives while trying to resolve a problem:
[snipped private link]
Gives the impression that their GitHub usage varies heaps, which doesn't feel in line with a group moving everything to it.
I'm just relaying what I heard from Matt Hicks, who is the engineering lead for OpenShift. I don't think the switch is planned to happen overnight, but they are heavy users of Rally now, and they are finding that straddling two tools is bringing more problems than it solves.
But, leaving that aside, what do you guys think about the idea for Aeolus? I know Redmine has more tracking features than GitHub, but it feels like we're saddling ourselves with a substantial burden (hosting an app, manually closing issues after committing code, etc.) that we could erase simply by moving story tracking to GitHub.
--Hugh
On 27/09/12 10:32 -0400, Hugh Brock wrote:
On Thu, Sep 27, 2012 at 11:19:34AM +1000, Justin Clift wrote:
Note - I've removed aeolus-devel from this, because I'm including links to internal things.
On 27/09/2012, at 3:23 AM, Hugh Brock wrote:
<snip> > I have a radical suggestion I would like to throw out for comment: > > I was talking to Matt Hicks the other day, of OpenShift, and he claims > they are moving *their entire agile setup* to GitHub. Basically they're > going to ditch stories in Rally and move them to the GitHub issue > tracker instead.
Interesting. As a data point, saw this last night in their recent archives while trying to resolve a problem:
[snipped private link]
Gives the impression that their GitHub usage varies heaps, which doesn't feel in line with a group moving everything to it.
I'm just relaying what I heard from Matt Hicks, who is the engineering lead for OpenShift. I don't think the switch is planned to happen overnight, but they are heavy users of Rally now, and they are finding that straddling two tools is bringing more problems than it solves.
But, leaving that aside, what do you guys think about the idea for Aeolus? I know Redmine has more tracking features than GitHub, but it feels like we're saddling ourselves with a substantial burden (hosting an app, manually closing issues after committing code, etc.) that we could erase simply by moving story tracking to GitHub.
--Hugh
I would be in favor of trying this out (we have already started a bit with ime), though I would caution just jumping in with both feet, as we tend to do. I think with a little experimenting, that from a developer's pov, this would be a good change. I am less sure how well it will work for those in pm/mgmt type roles. My personal opinion is that our backlog to this point in redmine is largely worthless, partly because we are not good about scrubbing it to keep it current, and partly because it is just plain too big to follow or be useful. This problem may well repeat on github issues, should we move there, but I have some hope that we could lessen it by continuing to move toward more focused, loosely coupled but highly cohesive, components. Then each component has its own set of issues underway, and people working on a different component can easily request features or submit bugs as they come across these things.
As an example possible flow, Martyn and I recently did some planning with Scott and Jan wrt integration of ime (actual naming to be brought up once more in another thread) and conductor. We considered ime to be largely feature complete, but in this discussion, found some additional hooks or tweaks that would make the integration easier from the conductor side, given the needs there (a plan for how to wrap an ime call with conductor perms infrastructure, for instance). This could easily be handled from here on out in github issues. We could create (and have) a conductor_integration feature (milestone) in ime, and add tasks that we discussed needed doing. At the same time, anyone on the condcutor side could add to that list as they happen across additional issues that we may have missed. Conductor could do something similar with their own milestone. The focus of this model is to basically build out small chunks of backlog as we start to work on things.
Will this work? I have no idea, it is just a thought, but I really don't think net we end up losing all that much, since nobody ever really looks at the backlog we have (with the possible exception of management, though I have no idea for sure). We lose some of the structure that tools like redmine and rally allow, but potentially allow for a more interactive todo list with more potential developer/community ownership of features. I could ramble on toward some conclusion, but not sure where else this might go, so I'll cut it short (long?) here.
-j
On Mon, Oct 01, 2012 at 01:49:02PM -0400, Jason Guiditta wrote:
On 27/09/12 10:32 -0400, Hugh Brock wrote:
On Thu, Sep 27, 2012 at 11:19:34AM +1000, Justin Clift wrote:
Note - I've removed aeolus-devel from this, because I'm including links to internal things.
On 27/09/2012, at 3:23 AM, Hugh Brock wrote:
<snip> > I have a radical suggestion I would like to throw out for comment: > > I was talking to Matt Hicks the other day, of OpenShift, and he claims > they are moving *their entire agile setup* to GitHub. Basically they're > going to ditch stories in Rally and move them to the GitHub issue > tracker instead.
Interesting. As a data point, saw this last night in their recent archives while trying to resolve a problem:
[snipped private link]
Gives the impression that their GitHub usage varies heaps, which doesn't feel in line with a group moving everything to it.
I'm just relaying what I heard from Matt Hicks, who is the engineering lead for OpenShift. I don't think the switch is planned to happen overnight, but they are heavy users of Rally now, and they are finding that straddling two tools is bringing more problems than it solves.
But, leaving that aside, what do you guys think about the idea for Aeolus? I know Redmine has more tracking features than GitHub, but it feels like we're saddling ourselves with a substantial burden (hosting an app, manually closing issues after committing code, etc.) that we could erase simply by moving story tracking to GitHub.
--Hugh
I would be in favor of trying this out (we have already started a bit with ime), though I would caution just jumping in with both feet, as we tend to do. I think with a little experimenting, that from a developer's pov, this would be a good change. I am less sure how well it will work for those in pm/mgmt type roles. My personal opinion is that our backlog to this point in redmine is largely worthless, partly because we are not good about scrubbing it to keep it current, and partly because it is just plain too big to follow or be useful. This problem may well repeat on github issues, should we move there, but I have some hope that we could lessen it by continuing to move toward more focused, loosely coupled but highly cohesive, components. Then each component has its own set of issues underway, and people working on a different component can easily request features or submit bugs as they come across these things.
As an example possible flow, Martyn and I recently did some planning with Scott and Jan wrt integration of ime (actual naming to be brought up once more in another thread) and conductor. We considered ime to be largely feature complete, but in this discussion, found some additional hooks or tweaks that would make the integration easier from the conductor side, given the needs there (a plan for how to wrap an ime call with conductor perms infrastructure, for instance). This could easily be handled from here on out in github issues. We could create (and have) a conductor_integration feature (milestone) in ime, and add tasks that we discussed needed doing. At the same time, anyone on the condcutor side could add to that list as they happen across additional issues that we may have missed. Conductor could do something similar with their own milestone. The focus of this model is to basically build out small chunks of backlog as we start to work on things.
Will this work? I have no idea, it is just a thought, but I really don't think net we end up losing all that much, since nobody ever really looks at the backlog we have (with the possible exception of management, though I have no idea for sure). We lose some of the structure that tools like redmine and rally allow, but potentially allow for a more interactive todo list with more potential developer/community ownership of features. I could ramble on toward some conclusion, but not sure where else this might go, so I'll cut it short (long?) here.
I think this is a great idea and I would suggest we start inching forward as you suggest.
Let's *not* spend any more cycles figuring out how to move redmine around, preserve links, etc. until we have made a decision on what to do regarding github.
Take care, --Hugh
aeolus-devel@lists.fedorahosted.org
-
Hugh O. Brock -
Jason Guiditta