Steev Klimaszewski posted on Wed, 05 Feb 2014 10:55:59 -0600 as excerpted: > There is far more to stabilizing than just closing the bugs. > > 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. > > > 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.
That *IS* a lot of work and you definitely have my respect for even /trying/ to carry it out. But Tom's "burn out in increasingly unimportant workloads" seems apropos. Which, given the continuing onslaught of stabilizations and the acknowledged bottleneck, eventually means something /must/, /WILL/ break. Which is exactly what this thread is about. Maintainers are actually seeing that breakage now as the backlogs get untenable. So they're complaining. Given the bottleneck and the continuing onslaught, it's /already/ broken. The "will break" has for them become "now has broken". The question then becomes what to do about that breakage, how to move it to the point of least disruption for gentoo as a whole. Thus the proposal, on bottleneck archs drop stable keywords for "unimportant" packages, reducing the working set to something tenable and thus reducing the bottleneck, allowing those archs to focus more strongly on core packages with the idea of keeping them stable and relatively current, even if it comes at the cost of a much smaller stable set. If the arch gets more resources in the future, it can expand that set, but right now it's an untenable bottleneck and /something/ must happen to break that bottleneck. If it isn't this, the problem will get worse and worse until that /something/ gets much worse, perhaps triggering a drop of the entire arch to experimental. The other alternatives include letting maintainers either reassign bugs for otherwise stale versions to the bottleneck arch in question, which just makes the problem worse as now the bottleneck has even MORE work piling up on it, or simply closing bugs filed against such stale versions as WONTFIX, perhaps with a note suggest the filer upgrade to something even half current, even if it's NOT stable on the arch and in fact is broken on the arch. Unfortunately, that last option is the current de-facto default, except that without a formal policy, bugs often remain ignored or closed WONTFIX without a useful explanation. IOW, for users and maintainers both the state is already broken, while arch-devs face an ever-increasing backlog and a bottleneck that's not going to get better. Now I'm admittedly a bit biased as I'm a kde guy who wonders what sort of self-respecting "customization is king!" gentooer would want to run "our way is the ONLY CORRECT way and if you think otherwise you're just stupid!" gnome in the first place, case in point being this apparent systemd requirement, but I'd certainly personally consider an after all non-core optional package set requiring *THAT* much additional stabilization work a prime candidate for first exercise of that keyword dropping policy. By your own statements that's two months of work for an optional non-core package set that you would have been able to skip, thus allowing you to focus more strongly on stabilizing other things, including gentoo's own default initsystem, openrc, which I think most would agree is otherwise a pretty core package, and this thread wouldn't have happened. Of course an alternative to that, particularly if the arch-devs involved are gnome folks (or if there's specific gnome sponsorship, etc), would be to consider gnome part of core for that arch, thus effectively considering systemd core on that arch and dropping many/most other desktops and initsystems to non-core and likely ~arch-only. With systemd now considered core as gnome is core for that arch and requires it, openrc would by definition then be non-core optional, and keywords could be dropped to ~arch, at which point again this thread wouldn't be happening. The fact is arm does seem to be a bottleneck, and one way or another, facts "on the ground" will adjust to that. At present, those facts on the ground are an enormous backlog and thus enormous pressure on the arm- arch-devs and ATs, while both arm users and general package maintainers have an unsatisfactory experience as bugs on otherwise stale but unfortunately still latest stable packages on that arch remain unfixed and essentially unfixable. The proposal simply adjusts to those current facts on the ground by allowing non-core packages to drop to ~arm, thus reducing the backlog and making /everyone/ happier, arm-arch devs and ATs because their backlog now reduces to something they can reasonably handle, general package maintainers and thus other arch users because those unfixed and unfixable bugs now get acknowledged as such and dropped off the radar, allowing for quicker progress elsewhere, and arm users because their actually marked stable package set better matches reality and they aren't dealing with all those bugs on supposedly stable packages. There remains one loose end, however, the fact that ~arch packages can be dropped without notice, thereby likely dropping the only actually working package on an arch. =:^( I'm not sure what to do about that. Introducing another keyword level for it and giving archs veto power over dropping the last known working but otherwise labeled ~arch version, would very likely bring us back pretty fast to exactly this same spot with that other keyword, since we would have effectively simply relabeled the problem. But I fail to see how that loose end is any worse than the current situation, since at least the ~arch keyword properly reflects the situation, that the arch in question simply doesn't have the resources necessary to properly support that package at anything like current versions, and old versions can always be pulled out of the attic if someone wants something that actually works even at the cost of no support. Which is unfortunately pretty much what they're getting now, if the last stable version is so stale the maintainer isn't supporting it any longer and would drop it if he possibly could, except if a user has to pull it out of the attic to get it, he at least has truth in labeling about the support status, which is lacking with the supposedly stable keyworded version he'd be using now. The only other alternative I can see would be effectively forking the gentoo tree into an arm-overlay, where all those stale arm keyworded packages can live on, supported by the people, including or even explicitly users, who care (this is actually what kde-sunset did, explicitly user-supported overlay, except that was obviously for a desktop package set, not an arch package set). That's certainly possible as can be seen by the kde-sunset example, but has its own negatives. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
