Enrico Weigelt wrote: <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.
This my first mail to this list. Short intro: I was introduced to gentoo by some colleagues roughly 2 years ago. *ALL* of them switched to Ubuntu, because the were annoyed by the package policy of gentoo with respect to server environments. I am still into gentoo and this upcoming criticism since Ubuntu motivates me to support gentoo more actively. Altough I did not finished any ebuild at this moment, I hope to help with my 'fresh' user view: I agree on the need to work on the unstable packages (my keyword list is large and I did not know that it is a bug to say please make it stable) To differentiate quite stable and proven is a good starting point. > 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*. The name overlay makes more sense, because a subtree is a sub-directory in case of a filesystem. The overlay is not a new subdirectory in portage, it exists of one or more directories outside portage which 'cover' one or more subdirectories of portage. But I don't know if the overlay is a solution to handle the discussed problem. > 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> Good idea, would be nice for me to find in an *efficient* way starting points for my helping hand. >>> 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. Overlays may be good for people like me who want to begin developing gentoo. But it can't help overall. > >> 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> What I understood from sunrise: They try to lower the barrier to get involved in ebuild development. BTW: Is there anybody who can tell me, if sunrise is now accepted by the gentoo community, and if not, what is the criticism? Should I go for sunrise? But also here I don't thing that sunrise should be a good practice for the gentoo user to overcome the aging unstable package problem. > >> 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> > + 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. Yeah, that's why I want to raise my voice! Great idea! That would be a community solution. Since the Ubuntu hype and criticism about unstable gentoo I was thinking in this direction. May the things and ideas said above are old (take them as a user vote then), I want try to make it more explicit and put my own view on it: 1. IMHO the problem is not aging ebuilds at all. It is about information content in portage and user feedback. More concrete: the problem is that there is not enough information about ebuilds. What we see on the surface (either on http://packages.gentoo.org or via emerge) is whether an ebuild is stable, unstable (keyword masked), hardmasked or not present at all. Not more. But what is needed is WHY,since WHEN and some other information: stable: OK, here everything is fine. The situation everbody likes ;) unstable: Why? Are there reason in the software package itself that makes the integration via an ebuild into gentoo non-trivial? Is the former maintainer Ubuntu addicted, know? Doesn't he find the time? Does he think, this ebuild is not important, because only two users are using it? hardmasked: Why? The same above, or severe security problems that arose? Since when? 2. To answer these questions, a feedback statistic would help a lot: a tool like 'emerge-feedback category/package-version' collecting the data in a single database could do it. scenario a) user just says 'emerge-feedback installation-succesfull category/package-version' and agrees that data like USEFLAGS, CFLAGS etc are also submitted. This enables the developers to see how important an ebuild in the community is and which package works best under which environment. scenario b) an emerge was not successful as an immediate reaction the user says 'emerge-feedback install-failed'. This tool could then collect all information necessary for a good bug report to bugzilla. If bug reports could be unified in this way, developer could also get to know how many user experience this problem under which circumstances. The difference here: If a bug occurs and a user is willing to submit it. He checks for an existing bug report. And if it already exist, he normally does not give any further feedback. scenario c) A user checks a package like postgis at packages.gentoo.org, he sees, 5 versions exist but only the oldest ver. 0.75 is marked stable, and the other 4 up to ver 1.1.2 are not. If he sees next to each version since when it is in the state and in addition to e.g. version 1.1.2 that a number of X user already installed it succesfully since then and Y user report problems he might be more encouraged to test and report it. Of course, all this information could be gathered from forums reading, bugzilla, ChangeLogs etc., but I am enthusiastic about this idea raised in this thread is: transparency, efficiency of the information and community feedback. I would also like to emphasize that it is important to also see why and since when a package is deleted. Not to say that I am often annoyed by package deletions, because they often force unwanted upgrades of depending packages. Also here to have the information, if a package was deleted because the programmer stopped the support like MySQL will do for the 3.x and 4.x in the next month. Or if the ebuild maintainer did not see the use anymore... I also dream of package branches that are marked as long time maintained, e.g. apache 1.3 should have a long life in portage. Ciao, someone -- [email protected] mailing list
