FAD Goals and deliverables

[Adam Miller]

On Tue, May 12, 2015 at 12:03 PM, Paul W. Frields <stickster at gmail.com> 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

I was hoping to discuss this at length once some internal folks who've
made commitments to move documentation (or create it) out in the open
so we can have an open discussion with the broader community but that
is still pending so I hadn't brought it up just yet.

>   Koji?  How will it change compose processes?

I think this is similar to previous, though I could be mistaken and/or
lacking context.

>
> * Composedb -- Dennis has talked about this many times.  Is it still
>   meant to happen?  Is there e.g. a schema design?
>
> I'm not against items in the previous list getting done at the FAD.
> But I guess I was asking what will happen wrt. the revolutionary list
> beyond discussion (which is what the list is for).  IOW, leaving the
> FAD with a vague consensus that "yeah, we'll take care of all that
> with composedb, whatever/whenever that is" would be more like kicking
> the can down the road.

+1 - I actually hope to try and make some progress on some of the
items on dgilmore's list pre-FAD as I find time and am able to dig in
but I'm glad he brought them up as areas that need work in the Fedora
Rel-Eng space. I would love to see at least part of the FAD dedicated
to working on what will be the basis for the future.

-AdamM

>
> --
> 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
> _______________________________________________
> rel-eng mailing list
> rel-eng at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/rel-eng