* Chris Gianelloni <[EMAIL PROTECTED]> schrieb: <snip>
> > 1) thousands of packages will never be marked stable > > Honestly, they shouldn't be stable. hmm, maybe we should have different groups of ports (*1) for a) quite stable: no bugs yet and enough votes) b) *proven* to be stable: has passed the whole bunch of qm tests. The quite stable category could be used for "normal" packages which are used in production but are not very critical. Maybe games and seldomly used stuff can be taken from here. Critical things (ie. base system, toolchain, critical apps) should only be taken from the proven/mature category. Maybe we could maintain several profiles which does the common masking. I'm not quite familar w/ overlays yet, but it seems wise to me to maintain overlays for several groups of b) ports. Individual overlays may have their own policies. For example one for critical server systems would require absolutely reliable, automatic remote updates, security fixes fast in but enhancements lazy, binary compatibility, etc. > In fact, likely, many shouldn't be in the tree. We have way too many > packages that are used solely by a small group of people sitting around > the tree. These would be better served in official overlays, where > they can be maintained by the interested parties (including users), > rather than in the tree. Those overlays seem good, if they represent an entire subtree (aka distinct from the main tree). For example there could be an KDE/Qt overlay, which contains the whole KDE stuff. People not interested in any of KDE (like me) don't need it. This would make syncing less resource intensive. But: please let's call them *Subtrees*. > > 2) Everyone running stable who wants some recent packages ends up with > > /etc/portage/package.keywords with hundreds of entries > > People don't seem to understand that you cannot have your cake and eat > it, too. I have no sympathy for these people. > > If you want *stable* then you're going to have to wait until the package > has passed QA and the bugs have been resolved. If you want *new* then > you simply have to deal with the bugs. Well, as I said, there're different views of "stable". One means "it is working", others mean "it has to be absolutely robust". Therefore we should differenciate between "stable" and "mature". For example bugzilla-2.22 (which is still masked ~x86 :(): I needed 2.22 for postgresql. This requires 2.22, which is ~x86, so I had to add it to package.keywords. It also requires DBD::Pg, also masked ~x86, also added to package.keywords. Fine so far, as long as I don't have to do it on many packages. Maybe we could handle the two cases installing vs. updating different. Again my bugzilla example: I installed bugzilla-2.22 and DBD::Pg, (both still masked ~x86). At this point I tried something new. Bugzilla + DBD::Pg work for me now, evrything's fine. Now it comes to an update. We've got a new Bugzilla version, which is considered at the same stability level as my current 2.22. I don't see any need for update, since I'm happy w/ current one. So emerge should leave it untouched. Some day we'll have an new version approved to be more stable than current or fixes some bugs. Now emerge should upgrade, but only to the point where it gets more stable. BTW: sometimes it will be good to maintain different branches, ie. there could come an quality enhanced 2.22.1 parallel to an not yet proven 2.23 from upstream. While 2.23 will bring new features, but is not yet properly tested, the 2.22.1 will only have - very carefully checked - bugfixes. This case should also be coped here. <snip> > People seem to think that there's some magical solution to this. There > is no solution other than more people actually *solving* the problems > that keep packages from making it to stable. The packages that are > complained about the most are invariably large sets of packages, like > GNOME or KDE, that have hundreds of dependencies and take quite some > time to get into a condition that can be considered "stable" at all. > > If you want things to make it to stable faster, then start supplying > patches. ACK, of course. Maybe we need some system to get users and latent contributors more informed about things to do. I imagine something which directly utilizes portage db (installed packages) to query for information. Ie: box:/ # equery-2do world [www-apps/bugilla-2.22 ~x86] (installed: 2.22 +postgres ...) * solve bug 12345 * test seamless upgrading from 2.20.2 ... [knollo/test-1.23 ~x86] (installed 1.20) * solve bug 1222 * try out new +postgres ... <snip> > > 4) The user experience sucks - see the forums/wiki... "to install > > this great sw you need the latest version of x, which depends on y,z, > > so copy paste this huge block in to /etc/portage/package.keywords."... > > then 2 weeks later some depend changes, and suddenly emerge -u world > > no longer works, and user has more problems to solve. > > Honestly, the number of people out there giving shit advice is part of > the problem. Rather than telling people to do this sort of thing, a > better solution would be to tell people how they can *help* instead of > how they can bypass the system, which ends up with clueless users filing > more bugs, which delays the stabilization longer. ACK. It's quite the same problem as many many packages (upstream) in the OSS world have - they try to work around bugs in imported packages, sometimes even ship their own branch of them (ie. apache -> expat) instead of simply fixing the problem on the source. And this then ends up in thinkgs like the whole autotools hell. That's why I started my OSS-QM project, I had announced some weeks ago. <snip> > Every user that someone knowledgeable gets to use something they don't > understand, is a potential bug report slowing stabilization even more. At least these bug reports should contain the user's keywording info. Ie. if the bug applies to an masked version, there should be an tag, so the devs can easily filter on that. Maybe one's only fixing bugs in unmasked packages and keeps things stable, another one then works on stabelizing an still masked package. BTW: is there any console tool for reporting bugs w/ all necessary information quickly ? Ie. if I found an bug in my current bugzilla, I simply wan to call it with the package name - the tool gathers all necessary information (ie. looks for the installed version, including masks, useflags, etc) and asks a few questions. > > The testing is supposed to be for the ebuild, not the package itself, > > so there's not much point in holding back packages with simple ebuilds > > from being stabilised. And the testing process isn't that extensive > > anyway - all it ensures is that the package builds and can be run on > > one particular arch testers system. No disrespect to the testers, but > > they can't be experts in every particular piece of software. How much > > code coverage does a typical ebuild really get when being tested? > > First off, we have a level of expectation of stability to maintain. If > all packages were done "right" then 90% of the ~arch packages in the > tree would be under package.mask, rather than ~arch. Only packages in > ~arch would be ones with no bugs open, to test the ebuild, so that they > can become stable. As we all know, this isn't the case. Developers all > over the place, including myself, have put in tons of packages that > aren't necessarily perfectly stable themselves. We do this because our > users demand it. We have reached a critical mass of users, where no > matter what we do, somebody is going to bitch and piss and moan because > we don't do things the way they would like. There's nothing that we can > do about this except decide collectively what the best course of action > for our users would be and try to make things as high-quality as > possible. hmm, social pressure is a big problem here. The mass of people who maybe are happy with semi-stable packages hurt those few who need critical stability. I tend to like the idea of mission-critical overlays more and more. > Automatic stabilization is one of those things that would cause our > quality to go to hell. Another thing is this. If you don't like it, > fork. You've got the code. You're *more than welcome* to go around > making your own overlay/tree and marking whatever rubbish you feel like > as stable. There's *nobody* stopping you from doing so. However, many I just read over the discussion very quickly, but isn't this exactly what Sunrise should be for ? <snip> > Another problem is that we don't *know* what is being run by our users. hmm, why not creating an database for this ? Users are then encouraged to run an tool which regularily posts the interesting parts of the emerge database (package+version+useflags+ keywords) and some system information (CFLAGS, hardware data, ...) into the database. Once we've reached an critical mass, we've got some usable statistic information. So we could also see, what should not be kicked off the tree (ie. someone's still using old packages, etc). We simply should tell people to use this tool if they like to get their systems supported. <snip> > out into overlays. I wouldn't mind seeing the tree completely split > into the "ricer" and "stable" camps. Let's call them "Gentoo > Enterprise" and "Gentoo X-Treme UberEdition" just to keep them > separate... So like other distros like debian do with there "testing" vs. "stable" branches ? hmm, would be easier to maintain, but mixing would be hard for users. <snip> > Seriously, folks. If you think that packages should be available > faster, run ~arch. Test the packages. Report successes/failures to the > maintainers. File stabilization bugs if your favorite package hasn't > had another bug in 30 days and you've been using it. Basically, help maybe this could be done (partial) automatically: + an tool checks the emerge db for masked packages which are older than 30 days and asks the user if he likes to give comments and if he likes to see it stabelized. BTW: is there an quick way for checking if some package in an specific version has some bugs ? Is there a fixed syntax for such bug reports where we could let the machine filter on ? cu *1: port := package+version -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- -- gentoo-dev@gentoo.org mailing list
