Hey, first of all I couldn't find any official info on how to submit QA policy suggestions. Then onto mine: I strongly feel like any non-keyworded packages should be banned. Clarification: I mean packages that only have -9999 ebuilds available in ::gentoo, and no ebuilds with KEYWORDs (where upstream has Git-like VCS). Rationale being the same as why -9999 packages can't have KEYWORDS: They are unpredictable and potentially insecure. Unpredictability could mean upstream repo being broken at any given time placing users in an awkward situation, where they are able to build some packages while not the others. Upstream repo can also be force-pushed over. I feel like packages offered in ::gentoo shouldn't have these issues, and there should be at least one safe release available to users. With Git-like VCS's becoming popular, it is super easy to create an unchanged snapshot based on a commit. Then onto another problem I've noticed: 9999 ebuilds aren't updated regularily. I know some people keep latest release and -9999's in sync, and this is totally fine, but when proxy-maintaining many of these -9999 ebuilds they get ignored. Thus they are broken, like in the example below: I looked at app-leechcraft/* and counted 72 packages where only 3 had KEYWORDS. Rest are pure -9999 only. When trying to emerge leechcraft-meta I was faced with unsatisfied deps (I guess removing these deps won't be caught by CI tool since leechcraft packages are masked by missing keyword?) and I couldn't continue. These ebuilds have last been touched in 2017, so it's no wonder they are outdated and broken. With this QA policy ::gentoo would've been saved from carrying dead ebuilds around for this long, and this dead weight being synced to every user's machines. Leechcraft is being developed in Github and regardless of the outcome for this policy I will contact the maintainer next. Repoman and pkgcheck can probably easily force/track this policy too. Truthfully I thought a policy like this existed already.
And how about new packages still in developing and not yet ready to get tagged? Some developers are actually developing on Gentoo and live ebuild allows you to get all the benefits from packages itself combined with latest code. For example when I worked on genkernel-4 I used live ebuild a lot. Now you will probably answer that genkernel wouldn't be affected because it has keyworded ebuilds but look how even pkgcore started in Gentoo (as live-ebuild only package)... I also get your point. I can't say anything about app-leechcraft. Let's hope they have a good reason or couldn't think of a better solution for _now_. My point is: We shouldn't need a new policy for that. It should be common sense that a live-ebuild only package doesn't make much sense the long term. However, if we have a policy, even short term live-ebuild only packages would be banned or violate policy. Any policy which will have know violators/exception is a bad policy and shouldn't exist from my POV.
(In reply to Thomas Deutschmann from comment #1) > And how about new packages still in developing and not yet ready to get > tagged? > I don't see any problem making an ebuild with -0_pre<date> format every now and then. Should reach more users than a pure -9999 ebuild anyway. Check rlottie, upstream hasn't yet made a release, it has commits in Github ~daily and many consumers in Gentoo already. It's keyworded for multiple arches already and stabilized on couple. > > My point is: We shouldn't need a new policy for that. It should be common > sense that a live-ebuild only package doesn't make much sense the long term. > However, if we have a policy, even short term live-ebuild only packages > would be banned or violate policy. > Yes, maybe "ban" is a bit harsh word. Of course they are given time to find and make a snapshot of a working commit. I felt like this is common sense as well, b ut you can't force action for a better change without having strict policies about them.
Created attachment 669767 [details] 9999_packages_only.txt Hey, a slight ping. I'd like the QA team to make this an official policy. Since cleaning leechcraft, we have 43 -9999-only packages left in the tree. I've gone through all of them, and here's a link to the detailed list I gathered from them: https://dev.gentoo.org/~juippis/tmp/9999_packages_only.txt Because the list is too large to be pasted in the bugzilla, here's a summary. Out of 43 ebuilds, - 2 are hosted in places that can't generate tarballs from commits - you can still utilize git tool and host a tarball in your own devspace. (5 %) - 3 are in maintainer-needed. (7 %) - 4 are maintained by candrews. (9 %) - 12 are still at EAPI-5. (28 %) - 17 are maintained directly or via projects by zero_chaos. (40 %) - 19 are currently unbuildable. (44 %) - 29 are hosted in Github. (67 % ) If the QA decides to make "no live-ebuilds only" policy true, I'll be filing bugs to each of these packages offering to help get them keyworded properly. Regardless, I'll be masking some of the dead packages listed above soon, and report bugs for broken ones that have hope to being keyworded.
And here's the final list and my next steps regardless of outcome for this bug: Last-rites: net-analyzer/nagios-plugins-flameeyes net-misc/lcr net-misc/srf-ip-conn-srv media-plugins/xbmc-addon-xvdr app-i18n/kde-l10n-scripts net-wireless/dump978 net-wireless/openggsn net-wireless/osmocom-bb net-wireless/openbsc net-wireless/osmobts net-libs/libosmo-netif net-libs/libosmo-abis app-emulation/rex-client Open bugs: app-doc/votca-csg-manual app-misc/no-more-secrets games-engines/exult media-plugins/kodi-screensaver-crystalmorph media-plugins/kodi-visualization-nastyfft media-plugins/kodi-screensaver-rsxs net-wireless/qradiolink net-libs/liba53 net-im/psimedia app-emulation/qt-virt-manager app-accessibility/simon Last-rites for packages that have dead upstream, and/or gentoo bugs open for a ~year without fix. Open bugs for packages that have active upstream and build issues can be easily fixed.
I've opened an issue in guru some time ago https://github.com/gentoo/guru/issues/32 For me 9999 are only double work to do: if you make a change in a package, you have to change the 9999 too
