On Thu, 2006-03-23 at 10:09 +0000, Chris Bainbridge wrote: > Reduced responsibility for package QA (I expect "we don't care about > overlays" to become a standard response on bugs.g.o)
You will *definitely* get this from developers that won't be using the overlays. Let's just say you decide to use a toolchain overlay and it exposes some problem in random app foo because you're using gcc 5.1.99 and we only have 4.0 in the tree. You file a bug against package foo without a patch. I'm the maintainer. You've now made me spend my time supporting something that isn't even in the tree, and could be an artifact of the overlay itself and something that will *never* end up in the tree. Why should I do this? What we have done here is actually *reduced* the amount of productive work that I can do by forcing me to deal with these overlays, even if I choose not to participate. > Surely the solution is to provide that safety net within the tree? > Rather than pushing changes into a live tree, push them into a testing > tree, then after they pass repoman/QA checks, and a build check, apply > the changes to the live tree, otherwise email a rejection. And allow > developers to add their own testing ebuilds to the tree (for a start, > they will be more widely tested). While this would be great, there is one major obstacle that people miss. Horsepower. Let's say I add a new openoffice ebuild to the tree for a security bug. We now have to wait how many hours for it to hit the tree? What if the KDE team is committing a new KDE version at the same time? I'm sure you can guess how this could bring all of our development to a complete and grinding halt. I wouldn't mind seeing an actual "unstable" designation added to KEYWORDS. The basic premise would be like package.mask packages where things can be done *within the tree* but still has the same air of "this might be totally busted at some point" as overlays. Users would be very unlikely to run unstable on their machines. Heck, we could even make it impossible to actually use unstable globally if we wanted to. The whole point is that I completely agree with you, a better solution would be to try to work within the tree to resolve this problem, rather than moving it outside the tree and into hundreds of individual overlays, which could be conflicting with each other. > The current system of overlay usage is very annoying for users, > particularly when bugs are hanging around with packages in the tree, > and after filing bug reports the user is told that the bug is already > fixed in the overlay. Or when new packages are added to overlays > instead of the tree. How are users expected to find them? They should not have to. It's as simple as that. Bugs in the tree should be fixed in the tree. New packages should be added to the tree. If it isn't a candidate for ~arch, then add it under package.mask instead. That is why we have package.mask in the first place. > Another thing that needs fixing is the massive number of packages that > aren't really maintained. Either the maintainer doesn't respond to > bugs, or the package is maintained by a herd and so no one feels it's > actually their responsibility to deal with the boring bugs, and when > some developer outside of the herd comes across it, they feel like > they can't fix the bug without stepping on someone's toes. What's > worse is that in a lot of these cases there will be a user on bugs.g.o > posting fixes and new ebuilds, and yet they never make it into the > tree. This is really both a political/social problem and one of manpower. There's a lot more users out there than there are developers. There are many developers out there who aren't quite so territorial. The main thing is us being civil with each other. There are many times where a developer wants to make a fix or change to a game. If they ask us, we let them. It's that simple. Heck, we usually ask them if they want to maintain it. Also, a herd is a group of packages, not a group of developers. A group of developers could share responsibility in looking out for a herd (or many) but they are not a herd themselves. > A system where developer ebuilds are kept in the tree, and users have > a way to automatically contribute ebuilds, either human reviewed, or > in some reputation based system, would be very useful. Users also need > feedback - how many times does a user submit an ebuild via bugzilla to > be told that it doesn't meet QA standards? Why isn't there a system in > place to run repoman/QA/build checks on user ebuilds/patches to make > sure they are fixed *before* being submitted for inclusion into the > tree? And if this could be linked to a bug reporting system where > people report/fix individual ebuilds or packages, and I can just type > 'gbugs -l pkgname' and get a list of problems and fixes that other > people have proposed, even better. Ebuilds that are human reviewed are exactly what we have now. The process isn't automated, but it cannot be automated if you expect human review. Automated review isn't possible, as it is very easy to work around automated tests to do something completely malicious in an ebuild. There should *always* be the human factor before *anything* makes it into the tree. Our reputation and even the stake of Gentoo as a whole depends on our reliability. As for ebuilds meeting QA standards, most developers that I am aware of will inform the user of how to make their ebuild better, and even point them to relevant documentation to assist them, expecting the user to make the changes. This makes for better submission and informs the user so they don't make the same mistake twice. All in all, it is good for all involved. Any developer that is closing a bug without reason is in the wrong. It is as simple as that. Saying something doesn't meet QA is bunk *unless* they also point you to reasons *why* it fails QA. As for bugs being posted, you're more than welcome to use "ALL pkgname" as a search on bugzilla to get anything related to that package. There's even a few command-line bugzilla query tools. > I'm not sure whether the answer is more openness of the existing > system, some custom submission flow system, or a distributed SCM, but > I do think there's a lot that could be changed to make things better. See, I 100% disagree that this is a technical problem. It cannot have a technical solution. Want better developer/user relations? Start talking amongst ourselves. Talk to other users. Talk to other developers. I tend to think our biggest failure is communication. Improve our communication and we'll improve Gentoo. Together. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
