Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 26, 2018 at 2:42 PM Adam Williamson
<adamwill@xxxxxxxxxxxxxxxxx> wrote:
> On Mon, 2018-11-26 at 11:30 -0800, Kevin Fenzi wrote:
> > Yeah, I think our goal should be 1 minute... just as realistic as one
> > hour. ;)
> >
> > I have not looked into things recently. However:
> >
> > * The mock fsync change (https://pagure.io/releng/issue/7909) may help
> > some.
> >
> > * We have plans to redo the setup on the s390x builders, which should
> > result in them being much faster. That should help.
> >
> > * I know pungi maintaienrs have been doing some work to make things
> > faster (even in the last release out this morning).
> >
> > All that said, I am not sure there's going to be a way to get it down to
> > an hour. I think getting it down to 3-4hours may be very helpful tho and
> > might be possible.
>
> While we're on the topic of unicorns, if I were the person actually in
> charge of this and had the freedom to do it how I wanted, what I'd
> really want to do is create a much more *modular* compose process,
> where inputs and outputs were defined and associated with each other,
> and you could easily define subsets to be produced at different times
> for different reasons. Not a compose, but a Compose Construction Kit. A
> big chunk of the length of "the compose" is associated with the fact
> that we define "the compose" as a single thing which produces (last
> time I counted) 70+ deliverables. If we had an easy way to say 'ok,
> right now we need a compose which produces A, B, C and D from the
> minimum necessary sets of inputs', that would be a massive improvement.
>
> This hasn't been true for a while (we actually have something like half
> a dozen or more different "composes", right now), but the system is
> still less flexible and it's still more difficult to configure
> different composes than it really ought to be.

Adam puts his finger on an important aspect of the work, which is to
"decompose the compose" (sorry). We need the ability to produce enough
A, B, C and D (abusing his example) to do integration tests for
specific inputs, such that maintainers get feedback in a reasonable
timeframe on their builds. With that, gating Rawhide can be an actual
thing.

-- 
Paul
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux