Prioritizing FAD Goals and Deliverables

Paul W. Frields stickster at gmail.com
Tue Jun 2 19:51:30 UTC 2015


On Tue, Jun 02, 2015 at 08:18:38AM -0500, Adam Miller wrote:
> Hello all,
>     There was previously some good discussion around FAD Goals and
> Deliverables[0]. I was hoping that we could start to get priorities
> lined up. I had an idea about "Current Gen Tooling" vs "Next Gen
> Tooling" objectives and kind of changed that table in the wiki[1] to
> reflect. (If there are objections on that please let me know, it just
> made sense in my head).
>     What I would like to propose is that we select 3 top priority
> items from the "Current Gen" list as well as 3 top priority items from
> the "Next Gen" list, then scope those items out somewhere (maybe even
> just on this wiki page) with enough detail that it's clear to everyone
> what the problem is and what the deliverable will be. From there I
> think we can order the remaining items in a list of "Nice to Haves" if
> there is enough time. When we meet for the FAD, focus on the
> prioritized and scoped out items and if we just kick butt and knock
> them all out then move on to the "Nice to Have" list.
> 
> Here's my vote(s) for top 3 in each and why:
> Current Gen:
> - Working pungi4:
>     Why? This will give us a lot of near-term wins for making rel-eng
> build/compose operations parallel by being able to farm them out to
> builders in koji
> - stage koji needs to be and then get it setup/deployed, ansiblized.
>     Why? Right now it's very difficult to properly test new versions
> of the tools because there's not a proper staging/testing evironment
> - rawhide looking like a TC/RC
>     Why? Making these align will allow for the rel-eng process and
> tooling to be identical between Rawhide/TC/RC where as of today that
> is not the case
> 
> Next Gen:
> - define what composedb should be
>     Why? I keep hearing about this mythical thing and the problems it
> will solve, would love to see it's ideas/requirements put down on
> paper so we can start working on it.
> - koji 2.0 Draft document
>     Why? This is another space where there is this mythical thing
> people talk about that will solve a bunch of problems. Would love to
> see it come to fruition
> - Content Generators for Koji
>     Why? This to me seems like something that will open up Koji 1.x
> for more flexibility and allow Rel-Eng to iterate and deliver newer
> build types/artifacts while we work towards Koji 2.x (which I think
> should also support the metadata format as defined by content
> generators for migration and compatibility reasons)
> 
> Thoughts?
> 
> I look forward to feedback and if anyone thinks I'm running around in
> crazy-town please let me know. It just seemed like the old idea
> gathering thread went stale and now would be a good time to start
> prioritizing and scoping.
> 
> Thank you,
> -AdamM

I don't think it's crazy to prioritize, quite the opposite.  Planning
out which granular deliverables are most important to accomplish at
the FAD is critical to coming out the other side with things done (and
hopefully done well).  All the FADs I've been to with a clear set of
priorities were successful, and the inverse was also true.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com


More information about the rel-eng mailing list