Re: Prioritizing FAD Goals and Deliverables
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