On Wed, 05 Feb 2014 10:55:59 -0600 Steev Klimaszewski <st...@gentoo.org> wrote:
> On Wed, 2014-02-05 at 13:58 +0100, Tom Wijsman wrote: > > Can we do something about our growing queue when fixing is > > insufficient? > > > > https://bugs.gentoo.org/chart.cgi?category=-All-&datefrom=&dateto=&label0=All%20Open&line0=320&name=320&subcategory=-All-&action=wrap > > > > PS: As a bonus, here's a nice view of our stabilization queue over > > time: > > > > https://bugs.gentoo.org/chart.cgi?category=Gentoo+Linux&subcategory=Keywording+and+Stabilization&name=639&label0=All+Open&line0=639&datefrom=&dateto=&action-wrap=Chart+This+List > > > > Notice how the graph goes down near the dates the threads were made; > > although, if you would draw an average it would appear to be > > growing. > > > There is far more to stabilizing than just closing the bugs. It is a sufficient indicator of how the amount of stabilization bugs, as well as the amount of overall bugs, is increasing over time. > I've been working for over 2 months now on the GNOME stabilization on > ARM. There has been a lot involved, including (but not limited to) > rebuilding kernels for proper systemd integration, setting up systemd > so that software would build (empathy won't build if systemd has no > locale set (lol!) so much for systemd properly importing my settings > from openrc) - building the software itself. Realizing that some > things were built against the GPU opengl implementation instead of > mesa's implementation, having to rebuild that software, and all it's > dependencies. Then the process of actually attempting to get it to > run, tracking down the junk in the logs - figuring out which messages > can be ignored, which ones are actual errors (why exactly is it > throwing an error message if that message can be ignored?) > > This is on multiple machines, because I'd like to cover softfp and > hardfp. This takes time. Even if I were to build everything on my > octa-core ARM server and just use the binpkgs, it still takes quite a > bit of time to get through everything. And this is JUST for the > default useflags. > > So you know what? I'm sick of hearing about "slow arches" - there's a > LOT of shit that we have to do to make sure things ACTUALLY WORK, and > based on your emails, you either have NO IDEA what all is involved in > alternate arch work, or you're purposely being obtuse about it. Or it appears that some arches and people already skim down on all that work because of the huge amount of workload; as you have seen today, I gave an example of that on #gentoo-dev. I do have an idea; but, it appears that that idea is already no longer applied by some of us. I'm sick of important packages being affected this way; "sorry WilliamH, we can't stabilize unless it's a security bug", *ouch*. > Now, we COULD do like Ubuntu, and just say if it builds, it's stable. > But I personally am against that, maybe that's okay with you. We used > Ubuntu on ARM devices at my last job - I'm intimately familiar with > their practices. We do not want to replicate that here in Gentoo > land, or at least, I don't, not on ARM. Feel free to look at all the > GL based apps that they have available on armel - and test how many > of them actually run on the hardware. I'll wait for you to finish > going through them all... You'll wait until we burn out in increasingly unimportant workloads. > Save the charts for upper management, they are the only ones who care > what the pretty graphs look like instead of knowing the full details. It demonstrates the actual problem this is all about; some of us do care about managing the future of Gentoo, as some of us do care to make sure the water tap is less open before mopping the floor. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
