After my ranting about QA – which brought back our lead from hiding, at least for a while, let’s see how he fares this time – a number of people asked me what they could do to help QA improve. Given that we want both to test and prevent, here comes a list of desirable features and requests that could obviously be helpful:
- as usual, providing for another tinderbox would be a good thing as more situations could be tested; right now I’d very much like to have a server powerful enough to run a parallel tinderbox set up to test against stable-tree amd64 keyword, rather than the current unstable x86;
repomanright now does not warn about network errors inHOMEPAGEorSRC_URI; see this bug as for why; it would be a good thing to have;- again
repoman, lacking network checks, lack a way to make sure that the herd specified inmetadata.xmlexists at all; it’s pretty important to do that since it happened before that herds weren’t updated at all; - there is also no way to ensure that
metadata.xmllists maintainers that have accounts in Bugzilla; with proxy-maintainership sometime it happens that either the email address is not properly updated (proxier fail) or the maintainer does not have an account on Bugzilla at all (which is against the rules!); unfortunately this requires login-access to bugzilla, and is thus a no-no right now; - the
files/subdirectories are still a problem for the tree, especially since they are synced down to all users and should, thus, be kept slim, if not for the critical packages; as it turns out, between Samba and PostgreSQL they use over half a megabyte for files that a lot of people wouldn’t be using at all; we also had trouble with people not understanding that the 20KB size limit on files does not mean you can split it in two 10KB files, nor compress it to keep it in tree (beside the fact we’re using CVS, there is a separate patch repository for that; Robin is working on providing a reliable patch tarball hosting as well); see bug #274853 and bug #274868 - moving on to bugzilla, there is currently no way to display inline on the browser logs that are compressed with gzip, that the new Portage can generate and make the tinderbox work much easier; this makes bug reports a bit more complex to manage; if somebody knows how to get Bugzilla to provide proper headers so that the browsers can read them, it’d be pure magic;
- right now we lack a decent way to test for automagic dependencies; you could make use of something similar to my oneliner but it won’t consider transitive dependencies on virtual packages;
- with split-unsplit-split-unsplit cycles, it happens that a number of packages are in tree and are now obsoleted – this is why I had to remove a number of geda ebuilds the other day – removing these packages not only reduces the pressure on the tree itself, but also allows the tinderbox to run much more smoothly without me having to mask those packages manually: when they are visible, the tinderbox might end up trying to merge them by removing the (newer) un-split ebuild, or vice-versa;
- one more Portage (non-repoman!) feature that would be nice: per-package features or at least per-package maintainer mode while Portage has a number of features to make sure that maintainers don’t commit crap (testsuite support; die-on-some-warnings; fix-or-die) – such as the
stricterfeature – but using them system-wide is unfeasible (I’m okay with fixing my own stuff, but I don’t want an unusable system because some other developer didn’t fix his).
For the files dir the solution must be that it may not be more than 20kb in total.
Wouldn’t it be neat to only sync a /cached/ version of the portage tree (like what eix uses)? I guess it would require a huge alternation of Portage, but why not download ebuilds and required files in $FILESDIR until they’re really needed when emerging a specific package? This way an emerge –sync would pull considerably less data and it might solve some other /problems/ too.The bug on $HOMEPAGE and $SRC_URI is quite interessting, as for QA I guess this feature should really be implemented.
How about one that’s a lot simpler to implement: * devs that break users’ boxes more more than once a year are retired.You’d certainly have fewer pissed off users fleeing Gentoo for other distros with such a policy. QA might also improve as a result, too, since it seems to be the repeat offenders that are doing the most damage to Gentoo’s image.
* there is also no way to ensure that metadata.xml lists maintainers that have accounts in Bugzilla […] unfortunately this requires login-access to bugzillaCould you elaborate on why login access is required for this check? As a quick test, I ran a search for bugs where the assignee ‘is’ (rather than ‘contains’) flameeye@ (intentionally left out the s) and Bugzilla spit back an error page complaining it was an invalid username. The error comes back even if I do the query without being logged in. Granted, this is not a very efficient way to check the tree, but with a cache of known validated names, it would become cheap pretty quickly. With a little help from the Bugzilla administrators, a one shot dump of existing accounts would let you avoid the overhead associated with building the cache. As far as I know, accounts cannot go away, so the cache would never need to be dropped and rebuilt. It appears there are presently 415 unique entries:find /usr/portage/ -name metadata.xml | xargs sed -e ‘/<email>/!d’ -e ‘s/^.*<email>(.*)</email>.*/1/’ | sort -u |wc -l415You get a few more without that last .* because of people merging other tags onto the same line as the <email> tag.If the infrastructure folks are amenable, it might be possible to bypass Bugzilla and have a script that runs directly on a Gentoo-owned machine and queries the Bugzilla account table directly. For security reasons, such a script would need to be writable only by people already entrusted with database access, but an outsider could write the script and submit it for them to install when they were happy it was safe. That brings the burden on them down to just a code audit and an scp.
Valeo, not sure if so strong is going to work, but definitely I’d be for easier drop-first-and-ask-questions-later commit access… but I’m “unsuited” for the position; I “am not delicate enough” as it happens.As for the checking for metadata; there already is a script that queries bugzilla for the right data without hitting tables too heavily, but it requires to be logged in. And yes, accounts can go away or change their email address, thus why we can’t just rely on that…
Diego, I hope you won’t mind, if I’ll use this post as a place to announce (at least in this comment) that the Vaizard institute, an EU based n.g.o. started a project to support Gentoo.
Could you elaborate on why compressed patches shouldn’t be allowed in $FILESDIR – even if they don’t break the 20k limit when compressed?I guess I am otherwise with bangert that the total size of all the files in $FILESDIR may not excess 20k.Of course that may cause trouble if there are patches for several releases.
I think that Valeo has a great idea.In terms of the server requirements what do you think you’ll need?
@kierans:Then comes the question of who should enforce it, and if this should go for only default-stable or default-arch too (where, a bit like fedora-updates-testing/rawhide it is to some limits approved to break the tree).Also, if a developer (like vapier who committed glibc-2.12) does one to five bad commits a year, but the rest of the year is one of the leetest toolchain ninjas you could ask for? Do you really want to retire him because of some lame-ass policy that “you worsen the breakage of unstable for about two days (or how long it took to fix m4) ~arch which is already approved to be broken to some point”?Personally I feel that if people have problems with ~arch breaking, then they should stay with stable or try another distro until they realize that they are just as broken from time to time (hell even fedora 13 breaks sometimes for people because of kernel bumps, broken dependencies, or developers who thinks that two libraries that has the same name is the same library and thus because of lame-ass usage of the fedora policy that you should always use system libraries breaks package for months while arguing with upstream without listening in a bugzilla. And Debian or Ubuntu? Do not get me started, but at least everybody should have heard about OpenSSL?).However I do tend to agree with flameeyes that the extent that some stuff (like python, gcc, glibc and other critical packages from system set) should be approached with caution. Maybe place bigger version changes (major.minor updates, massive backports) inside of package.mask and test so at least the system package set compiles, installs, boot and still is able to compile and install itself and other packages (unlike that broken version of python that hit ~arch users for a day or two until removen some weeks ago).For ~arch I think that should be a minimum requirement.
@Valeo de Vries<li>devs that break users’ boxes more more than once a year are retired.</li>Sorry, but I can’t decide if you’re trolling or joking :-/
@XakeI agree with you, enforcing such a policy is fraught with perils; where as the intent (let’s stop people constantly doing stupid things) is gold.However as Valeo pointed out, it’s repeat offenders that’s the problem. We all make mistakes and to use your example, one to five bad commits a year is pretty small. However if said dev makes a bad commit, finds out about the consequences and fixes it quickly, that’s not a bad dev. That’s a human dev who fixes his mistakes and learns from it.
Retiring devs in such a way could also lead to a point where no dev is willing to build on packages which are predestined to break the system.
Dictatorship. Gentoo need a dictatorship, Gentoo council is a horrible bureocratic monster.
Instead of pulling the plug on devs, couldn’t we do something to speed up the process of switching to a DVCS?Then if you do an offence once, you only have push access to a staging repo for some time. If you don’t do another mistake, you get back your push access to the main repo afterwards.If you repeatedly make grave mistakes, you’ll just be in staging for longer (exponentially rising times? 🙂 ).And if you for example want that additional layer of safety against your own errors, you can just ask for being staged, despite making no mistakes.What is still standing in the way of the git-migration? And can I help with not-too-complex python coding?
@Vaizard: How about hiring flameeyes as full-time QA member?From your goals: „Fulltime-devs: Hiring part-time or full-time devs to work on Gentoo Linux.“@Flameeyes: Are you already in contact?
@Arne Babenhauserheide: There is a bug related to git migration, you can look into it’s blockers:https://bugs.gentoo.org/sho…
By now there is “a way to make sure that the herd specified in metadata.xml exists at all”. Unless I’m mixing somthing up all you need is a newer version of portage.
I’d have to check that one, maybe running full-tree repoman later… we’ll see.
Congratulations, your blog entry was featured in the print edition of the German “Linux Magazin” (November 2010). The online version of the article can be found “here”:http://www.linux-magazin.de…. Thank you again for all your invaluable contributions, including your help in raising awareness for our favorite Linux distibution.