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 -- == Hugh Brock, [email protected] == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I’m not sure you realize that what you heard is not what I meant." --Robert McCloskey
