How to deploy our new jekyll website

Hugh Brock hbrock at redhat.com
Mon Oct 1 18:45:01 UTC 2012


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, hbrock at redhat.com                                   ==
== 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



More information about the aeolus-devel mailing list