On Mon, Nov 26, 2018 at 2:42 PM Adam Williamson <adamwill(a)fedoraproject.org>
On Mon, 2018-11-26 at 11:30 -0800, Kevin Fenzi wrote:
> On 11/26/18 10:58 AM, Peter Robinson wrote:
> > On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
> > <adamwill(a)fedoraproject.org> wrote:
> > > On Mon, 2018-11-26 at 18:44 +0000, Peter Robinson wrote:
> > > > On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller <
> > > > > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > > > > Here's the summary from the page, which proposes we
> > > > > > after F30 for these efforts:
> > > > >
> > > > > I know it was a big time-off holiday week in the US, but I
expected a little
> > > > > more interest in this post. Perhaps it seemed like too much
> > > > > along with turkey and stuffing. :) I'm highlighting it with
> > > > > reflecting the big, direct impact, and here's some other
> > > > > proposals:
> > > > >
> > > > > * embrace Taiga (an open source kanban tool) for project
> > > > > * fix the compose speed (target: one hour!)
> > > >
> > > > Can I have a unicorn? Everyone wants this bug absolutely no one has
> > > > done analysis.
> > >
> > > I just don't believe this is true. I'm pretty sure Dennis and
> > > have both looked into it before.
> > Yes, I mean recently, I was involved in the last time we attempted
> > this, and there was a number of things identified but quite a bit has
> > changed since that last happened.
> 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
> * 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.
This would be great.
I want to get to a state where different WG's can run their own composes
by calling a service.
They might actually release on their own schedules as well. (Not all, but
something like Labs or Spins) .
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines