FAD Goals and deliverables

[Paul W. Frields]

On Mon, May 18, 2015 at 09:11:32AM +0200, Pierre-Yves Chibon wrote:
> On Thu, May 14, 2015 at 11:00:10AM -0400, Ralph Bean wrote:
> > On Wed, May 13, 2015 at 04:45:46PM -0500, Adam Miller wrote:
> > > Yeah, a lot of people keep saying things like that but I was really
> > > hoping we could sort out as much as possible on the mailing lists or
> > > $other between now and then so that we could keep the amount of
> > > planning time at the FAD to a minimum and hopefully spend a bulk of
> > > the FAD time working on things. I don't know how realistic that will
> > > turn out to be but it's certainly something I'd like to strive
> > > towards. Maybe have a 1-4 hour planning session at the start of the
> > > FAD and then be doing actual work for the rest of the FAD.
> > 
> > This sounds good to me.  A little block of time at the beginning to
> > plan and talk high-level.
> > 
> > > From the grand pie in the sky concept of composedb (and koji 2.0 for
> > > that matter), I don't really know if that timeframe is feasible if we
> > > don't do any pre-planning on the requirements, desired features and
> > > technical architecture of these things.
> > 
> > Makes sense.  The more ideas about it that we can get out ahead of
> > time, the better off we'll be.
> > 
> > > Am I crazy to think that for the FAD schedule?
> > 
> > At the mirrormanager2 FAD in back December, we spent the entire first
> > day just picking Matt Domsch's brain about how mirrormanager1 works.
> > We white-boarded it all and then spent the rest of the FAD
> > implementing and writing tests for what we talked about.  It had a
> > good flow to it and it worked - we actually have a mirrormanager2 code
> > base now.
> 
> One thing which we might have missed in this process was to also write down
> properly all the information we got on something else than just the white board.
> For MirrorManager2 we did this a few days/weeks later and asked Matt to go over
> it but I am pretty sure this doc misses some of the things we learned from Matt
> during the FAD.
> So whiteboard and global overview +1 but make sure to take some notes while
> doing so as well ;-)

+1.  It's important to do more than photograph the whiteboard, which
can lose context over time and be hard to understand later (from
brutal, personal experience). ;-)

This is also going to be important for describing the newer release
systems while at the FAD -- the things we want to create that are
net-new.  Dennis did a good job describing a number of fixes that are
needed for the current system.  Those need to be prioritized in some
way, and the FAD needs to be a balance between those priority fixes
and designing (and hopefully hacking fundamentals of) any new tools
and infrastructure for creating deliverables.

-- 
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