Prioritizing FAD Goals and Deliverables

[Adam Miller]

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


[0] - https://lists.fedoraproject.org/pipermail/rel-eng/2015-May/020075.html
[1] -
https://fedoraproject.org/wiki/FAD_Release_Tools_and_Infrastructure_2015#...

[Paul W. Frields]

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

[Ralph Bean]

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 
Sounds good to me.

>  - 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 
This already works but only for simple builds which succeed only
because the production repos (and all their rpms) are linked in as
external repos. A negative side-effect of this is that we can't do
composes against staging koji because the staging kojira repos are
basically empty. It's been batted around in channel a few times, but
we'd need to address that problem.

>  - 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 
Also sounds good here.

>  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. 
+1

>  - 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 
I saw today there's a start of a discussion on this on the buildsys
list.  Good timing!
https://lists.fedoraproject.org/pipermail/buildsys/2015-June/004763.html

>  - 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) 
I had to look up what a Content Generator is (it's a relatively new
wiki page): https://fedoraproject.org/wiki/Koji/ContentGenerators
Also, looks good for this list.