FAD Goals and deliverables

Ralph Bean rbean at redhat.com
Thu May 14 15:00:10 UTC 2015


On Wed, May 13, 2015 at 04:45:46PM -0500, Adam Miller wrote:
> On Wed, May 13, 2015 at 4:11 PM, Ralph Bean <rbean at redhat.com> wrote:
> > On Wed, May 13, 2015 at 03:44:13PM -0500, Adam Miller wrote:
> >> On Tue, May 12, 2015 at 12:10 PM, Dennis Gilmore <dennis at ausil.us> wrote:
> >> > On Tuesday, May 12, 2015 01:03:15 PM Paul W. Frields wrote:
> >> >> On Mon, May 11, 2015 at 02:57:11PM -0500, Dennis Gilmore wrote:
> >> >> > On Sunday, May 10, 2015 01:28:13 PM Dennis Gilmore wrote:
> >> >> > > Hi all,
> >> >> > >
> >> >> > > As we get closer to the FAD we need to nail down the deliverables and
> >> >> > > what
> >> >> > > we want to achieve by the end of the FAD.  I am going to list some of
> >> >> > > the
> >> >> > > things I think we need to have done. feel free to discuss and add
> >> >> > > things.
> >> >> > > at the ned we will update the wiki with the deliverables.
> >> >> > >
> >> >> > > 1) working pungi 4.
> >> >> > > 2) integrated ability to make atomic installer and pxe to live in pungi
> >> >> > > 3) mash ported to createrepo_c
> >> >> > > 4) rawhide looking like a TC/RC
> >> >> > > 5) bodhi2 able to trigger atomic installer and pxe to live as part of
> >> >> > > the
> >> >> > > update push process.
> >> >> > > 6) livemedia-creator koji integration
> >> >> > > 7) koji able to manage the url line in kickstarts so that we can do real
> >> >> > > builds
> >> >> > > 8) run-root plugin configured
> >> >> > > 9) Secondary arches working exactly teh same as primary
> >> >> > > 10) port pungi to dnf
> >> >> > > 11) make headway and plan to port to python 3
> >> >> >
> >> >> > 12) have koji be able to specify the backend for installing packages into
> >> >> > chroots on a per target basis. we will need to use yum/yum-deprecated for
> >> >> > most but we will want to use dnf for rawhide and new releases.
> >> >> > yum-deprecated will be needed when we move builders to f22
> >> >>
> >> >> Here are some things that have been under previous discussion some
> >> >> time but which I don't see on this list:
> >> >>
> >> >> * Koji 2 -- What does it look like?  How does it work vs. current
> >> >>   Koji?  How will it change compose processes?
> >> > at this point in time it does not exist at all. we can not assume anything
> >> > about it. I have asked the koji devs to start planning and get moving, but
> >> > right now thwere is no such thing.
> >> >
> >> >> * Composedb -- Dennis has talked about this many times.  Is it still
> >> >>   meant to happen?  Is there e.g. a schema design?
> >> > Mathieu Bridon was tasked with this but AFAIK there is nothing existing for it
> >> > yet. Again we need to move forward without it :( though it is something that I
> >> > do really want. Perhaps he can give us an idea where it stands.
> >> >
> >>
> >> It turns out that I have been tasked with composedb[0] in some
> >> capacity for FY16, I was hoping to get some background information on
> >> it: What is it? What does everyone want it to be? Who do I need to nag
> >> appropriately to get some discussion, design doc, $other ongoing out
> >> in the open so that we can work towards this and potentially get it on
> >> the list for the FAD?
> >>
> >> -AdamM
> >>
> >> [0] - https://fedoraproject.org/wiki/Fedora_Engineering/FY16_Plan#Application_development
> >
> > I get the sense that we don't really know what composedb is or should
> > be, but having everyone together at the FAD will be a good time to
> > suss out those details.
> 
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/rel-eng/attachments/20150514/b55b7063/attachment.sig>


More information about the rel-eng mailing list