William L. Thomson Jr. posted on Fri, 28 Jul 2017 16:10:42 -0400 as excerpted:
> It seems odd that upstream will release a package. Just for downstream > to consider it not stable. Did it get messed up during packaging? Did it > get messed up by the distro? The whole lag thing does not make sense for > Gentoo. Sooner released and tested on Gentoo. Sooner bugs can be > founded, reported back to upstream, etc. Speeds up development. That is > Gentoo's role in FOSS IMHO. Not so odd. Gentoo's arch-stable has a different meaning than upstream's stable. As a long time gentooer I'm surprised you weren't aware of this already. In general (individual packages may differ somewhat on a case-by-case basis, one variant being packages where gentoo /is/ upstream and ~arch is thus used for upstream unstable testing to some degree)... Gentoo's stable doesn't really relate to upstream stable except that upstream betas and the like (well, short-term ones, not the ones that last years without a non-beta release...) aren't normally considered stable candidates because they're not released by upstream as such. Instead, gentoo's stable means that the packaging -- the ebuild script, the eclasses it calls, and the eapi as encoded in pms and deployed by the pm -- is considered tested and stable on a particular arch. Gentoo- stable also includes proper integration, making sure the header files, libs, configuration, documentation, etc, all end up in the place gentooers expect them to be, that they build with our particular toolset, etc. Similarly, upstream-unstable isn't supposed to be a candidate for ~arch either, because ~arch is supposed to be upstream stable that simply hasn't yet had enough testing of its gentoo packaging and integration in ordered for that particular package to be declared stable. That's one reason why ~arch normally works so well for those prepared to manually deal with the occasional packaging or integration hiccup, missed or incorrect dependency, failed merge due to conflict with existing files because upstream moved something and the package hasn't yet adapted to it, etc -- it's releases that upstream has already declared reasonably stable, that simply aren't yet sufficiently tested in terms of the gentoo packaging and integration, and if a user's willing to deal with the occasional hiccup there it should otherwise be as stable as the upstream declaration. Which is why people like me find ~arch quite stable -- it /should/ be for us, as it's upstream stable, and we're prepared to deal with the minor dependency and integration issues, etc, that the process of gentoo stabilization is intended to fix. The problem this thread is seeking to at least incrementally tweak toward the better is that the above only works for people on stable, when people actually declare a package stable when there's no serious bugs left after the testing period. Sometimes they forget, packages drop thru the cracks, etc, and stable users get further behind than they would be if policies were actually being followed. And perhaps more to the point, on the minor archs which tend to be the bottleneck, sometimes there's simply not the resources, either sufficiently interested people with the time (who are volunteers after all, so interest and time can't be commanded) or arch hardware or both, available to do those stabilizations. The proposal here hopes to automate much of the process as well as standardize it, hopefully alleviating that bottleneck. Tho as I've said before, as one who /is/ prepared to deal with the occasional packaging or integration issue and thus finds ~arch perfectly usable, I'd personally have no problem with dropping stable, it's just that I know it to be a practical impossibility, because were we to do so, instead of freeing that time to work on what's now ~arch, we'd simply lose most of the volunteers who have a major interest in stable. -- 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
