How to deploy our new jekyll website

Jason Guiditta jguiditt at redhat.com
Mon Oct 1 17:49:02 UTC 2012


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



More information about the aeolus-devel mailing list