On Wed, Jun 03, 2009 at 08:55:48AM -0400, Paul W. Frields wrote:
On Tue, Jun 02, 2009 at 08:15:32PM -0400, Josh Boyer wrote:
> We are facing some real limitations on our turn around time for
> things at the moment and they are only going to get worse as we have
> newer releases that will get the delta rpms. At the same time, the
> same people are getting raked over the coals for not getting bits
> out fast enough.
>
> We are working on this from a rel-eng standpoint, but advocating for
> a bit of discretion on what should be pushed as an update is not
> entirely a bad thing. Personally, I would love it if package
> maintainers slowed down a bit. But it's not an end solution.
>
> So certainly the leadership, defined as FESCo and FPB, is not in
> conflict with the contributor's apparent direction. As far as I can
> see, they haven't made a statement either way. If there is a group
> that was pushing for something that ran contrary, it was Rel-Eng.
> And given that Jesse and I both just said we're going to basically
> stop begging people to slow down on updates, I think even that group
> is trying to figure out a way to make things better. Hell, that's
> partly what this FAD is all about.
If the FAD identifies some tangibles (hardware, etc.) that would help
alleviate some of the time problems, I can tell you that Spot and I
will do our best to procure them. From what I've heard others
describe up until now, it doesn't seem like there's one clear
roadblock in that regard -- just a huge mountain of tasks that our
current systems have to chug through for composing, and no matter how
you slice it, it takes a lot of time and I/O bandwidth.
Yep. As a simple test, We'd like to do some experiments to see if running
updates pushes and rawhide composes on separate boxen makes things worse or
better or about the same. I don't think we need additional procured hardware
for that, just a cloned guest which I already have a ticket opened for.
Oh, and time. Always need time. If you or spot could procure time, let me
know ;)
josh