Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: > Well, we would hope that people using the package would file a bug, but > this obviously doesn't always happen. A little request here: Please don't mass-file bugs with a single sentence like "It works, please stabilise.". At least add your emerge --info, preferably some more information (how long have you been using it, etc). And before doing so please search bugzilla if there already is a stabilisation bug on that package. If so feel free to comment on that bug, again with some verbosity... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE02pf6q4f+IV6B/wRAnGeAJ9/f8+QDKmIiBZkAJVLVDX1/9mU5gCdGKsk mWqaRouUWVk4Cc6gmKGSmV4= =4XGt -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
Enrico Weigelt wrote: > >>> 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 > ... > > 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. > > >> 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, usefl
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On Fri, 2006-07-28 at 22:20 +0200, Matthias Bethke wrote: > no reply, opened a bug (#140242) some two weeks ago---still nothing. Everything prior to this was unlikely to get a response. As for the bug, two weeks is barely infancy for some bugs. > Seems I'm not following some arcane protocol. I mean, I'd be fine with > any comment. Nope. You're doing it all correctly now that you've filed a bug. > "Your ebuild sucks, read $DOC and fix it"---Cool. > "We don't have time for the three-and-a-half users of this package, just > submit it for an overlay at $FOO"---Fine, I know what to do. > "Mail $DEV and see to it that you get dev status yourself"---OK. > > Hum. Well, I've been subscribed here for a while to get a feeling for > the dev process, and this seemed like a good opportunity. Maybe someone > else can tell me where to start? As I have said, you've done it right. Now it is just up to the maintainers to actually pick up the bug and work it. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
Richard Fish wrote: On 7/27/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: The "majority" of packages are also the ones that need more extensive testing. Sure, we could probably stabilize a bunch of the fringe packages that hardly anyone uses and it wouldn't affect anything. The majority of Aliz's database seems to be made up of these "fringe" packages. Many of which are stable on at least one arch already, or have only a single version in the tree anyway. Stabilizing these on the remaining archs that they support should not have any significant impact on the perceived overall quality of Gentoo. I was planning on working through the list some time in the near future. I have to finish filing GCC 4.1 stabilization bugs for half the tree first. ;) --de. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On Fri, 28 Jul 2006 09:41:09 -0400 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > That's actually how I read the first email, was that it's really > > the majority of the _minor_ packages that get completely neglected, > > and just sits in the tree for months or years marked unstable > > because nobody cares. The people that use it have marked it ~arch > > a long time ago in their package.keywords because they know it > > works just fine. > > Well, we would hope that people using the package would file a bug, > but this obviously doesn't always happen. It indeed doesn't - I have quite a few friends who complained to me that package xxx is still in ~arch despite being in the tree for a long time, and when I asked them if they filed a bug to ask for stabilization, they reply that they didn't know it could be done this way, or worse, that they simply do not have time for such thing (!!!). -- Andrej -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
Chris Gianelloni wrote: > (stuff) "Me too!" Seriously, you nailed it on the head. How many times have you had this conversation: u: "Why is it taking so *!#$!@ long to get KDE/Gnome/XFCE stabilized?! Fedora/Debian/Ubuntu got it a whole week ago! OMG!!1!" d: "It'll be stabilized once it's actually stable. If you want that version now, you could always keyword it ~arch." u: "But I can't use ~arch! It's unstable!" --de. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
Hi Chris, on Friday, 2006-07-28 at 09:41:09, you wrote: > Well, we would hope that people using the package would file a bug, but > this obviously doesn't always happen. Even if it happens that doesn't mean anything is gonna change :) I'd like to get involved and help out with stuff like this but frankly I don't know where to start ATM. The thing is, I maintain net-misc/hsc, upstream that is. The latest stable version in portage is two years old, the unstable one is almost 1yo and buggy. Now there's been a fix for about 5 months now, even comes with an ebuild, maybe not a very good one but it works on various platforms. I notified the developer that made the last ChangeLog entry in March, and again in June, copied to some others devs from the log when there was no reply, opened a bug (#140242) some two weeks ago---still nothing. Seems I'm not following some arcane protocol. I mean, I'd be fine with any comment. "Your ebuild sucks, read $DOC and fix it"---Cool. "We don't have time for the three-and-a-half users of this package, just submit it for an overlay at $FOO"---Fine, I know what to do. "Mail $DEV and see to it that you get dev status yourself"---OK. Hum. Well, I've been subscribed here for a while to get a feeling for the dev process, and this seemed like a good opportunity. Maybe someone else can tell me where to start? cheers! Matthias -- I prefer encrypted and signed messages. KeyID: FAC37665 Fingerprint: 8C16 3F0A A6FC DF0D 19B0 8DEF 48D9 1700 FAC3 7665 pgpUA1DhAtkLp.pgp Description: PGP signature
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On Thu, 2006-07-27 at 22:55 +0200, Robert Cernansky wrote: > Chris Gianelloni wrote: > > But, nobody likes doing the small stuff, and I can't blame them. > > I understand. I do not expect that these packages will have same > attention by developers as major ones. I would understand if > stabilisation or version bumping will be slower than normal. But at > least it should be done somewhen. Most are marked stable at some point. There are a few that are not, for various reasons. > Yes, we (users) should help. But I can't have impression that when > I don't ask for stabilisation/version bump it simply never happen. It *should* happen, no matter what. However, we've seen that this is not always the case with every package, especially with packages that are used by a very small subset of our users. > From the user point of view it is simply lot of work, lot of > maintaining a distribution to fill a bug for every action that should > be made on package. Yes, it is. Gentoo is a community-based distribution. If the community doesn't help out, nothing gets done. It's not like we get paid to do this or anything. > Again, I agree that we should help, but if our busyness does not allow > it for a while, the packages should move anyway. Yes, they should. Again, it simply doesn't always happen. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On Thu, 2006-07-27 at 11:11 -0700, Richard Fish wrote: > On 7/27/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: > Please don't interpret my original message as a complaint. It isn't. > It is mostly a question of the process. My understanding of > stabilization bugs was that they should be the exception, not the > rule... > > > that you might not be able to make a commitment, or even want to do so. > > However, every single bug report that you file *is* helping out... and > > every little bit helps. > > ...and I was wrong. The x86 architecture team (as well as some others) do not mark packages stable unless there is a bug. In the case of the x86 team, it is simply due to a lack of manpower and also due to our feelings that we should not mark things stable without the maintainer requesting it. Of course, we don't *require* a bug report be made. If the maintainer asks (via email, IRC, etc.) us, then we will do it. Also, we don't require that requests originate from the maintainer, only that the maintainer approves. For example, I, as a user, could file a request to have a package marked stable, this would be assigned to the maintainer. If the maintainer agrees, then the arch teams are added to CC on the bug and they mark the package stable. Many packages do not get marked stable simply because most developers maintain a very large number of packages, and simply forget. This is why bug reports from the users is definitely helpful in getting things stable. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On Thu, 2006-07-27 at 09:24 -0600, Steve Dibb wrote: > Chris Gianelloni wrote: > >> I'd say no bugs, 30 days, passes internal tests, being run by users => > >> stablise, for the majority of packages (obviously, there may be some > >> exceptions...). > >> > > > > Luckily, you're not making the call. ;] > > > > The "majority" of packages are also the ones that need more extensive > > testing. Sure, we could probably stabilize a bunch of the fringe > > packages that hardly anyone uses and it wouldn't affect anything. > > That's actually how I read the first email, was that it's really the > majority of the _minor_ packages that get completely neglected, and just > sits in the tree for months or years marked unstable because nobody > cares. The people that use it have marked it ~arch a long time ago in > their package.keywords because they know it works just fine. Well, we would hope that people using the package would file a bug, but this obviously doesn't always happen. > THAT stuff I wouldn't mind going through and just bumping to stable > myself. They don't need extensive testing, they don't need patches, > they work, and have been working, and just need arches flagged and > versions bumped. I'd have no problem with that so long as it was done by a person. I just don't trust that anything like this should ever be automated. Now, we could have an automated system to send out *alerts* on packages that have been in testing for more than 30 (or 60) days. We could even make it searchable by architecture and put it on a web page. We could probably also make it give some information about QA problems. We could even make it searchable by herd. That would be cool. I propose that we put up such a page and we call it http://gentoo.tamperd.net/stable/ and make it publicly available. ;] > But, nobody likes doing the small stuff, and I can't blame them. True that. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
(I subscribed to -dev only a while ago so I can use only this message to reply. So take this as more general reply. I used quotes from other mails also. Hopefully it is not too confusing.) On Thu, 27 Jul 2006 11:11:33 -0700 Richard Fish <[EMAIL PROTECTED]> wrote: > On 7/27/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > > testing. Sure, we could probably stabilize a bunch of the fringe > > packages that hardly anyone uses and it wouldn't affect anything. > > The majority of Aliz's database seems to be made up of these "fringe" > packages. Many of which are stable on at least one arch already, or > have only a single version in the tree anyway. Stabilizing these on > the remaining archs that they support should not have any significant > impact on the perceived overall quality of Gentoo. This sounds good. I agree. But the problem is probably: Chris Gianelloni wrote: > But, nobody likes doing the small stuff, and I can't blame them. I understand. I do not expect that these packages will have same attention by developers as major ones. I would understand if stabilisation or version bumping will be slower than normal. But at least it should be done somewhen. > > 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. Yes, we (users) should help. But I can't have impression that when I don't ask for stabilisation/version bump it simply never happen. Moving of package (updating/stabilizing) is also my motivation to make and submit a new ebuild. If the package never moves without my further interaction why should I bother by making an ebuld? I'll rather take tar.gz, unpack & build it. It will be less work for now (I do not need to make ebuild) and also for future (I do not need to fill bugs that package should be included/keyworded/stabilized/bumped to new version+updating the ebuild). >From the user point of view it is simply lot of work, lot of maintaining a distribution to fill a bug for every action that should be made on package. Again, I agree that we should help, but if our busyness does not allow it for a while, the packages should move anyway. > > Basically, help out, rather than sitting back and complaining. > > Complaining helps nobody. But it is also good to know what users think about your work, how they feel when using Gentoo. It is not big complaint from me. I'm not saying that I'm unhappy with Gentoo. I'm happy with it, but there is a chance that I can be happier. ;-) Stefan Schweizer <[EMAIL PROTECTED]> wrote: > As a better system I would like to see packages stable automatically > after 30 days and no bugs. But this is probably not going to happen > with gentoo so I just stay away from stable and put ACCEPT_KEYWORDS > in my make.conf I agree with others that this can cause a big quality drop. Maybe it should be done that way, that only _some_ packages will be allowed to stabilize automatically. And it could be just these "fringe" packages. It would solve doing that small suff that nobody likes. Robert -- Robert Cernansky E-mail: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On 7/27/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: Honestly, they shouldn't be stable. 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. This might be a good idea. I think some additional tools support would be useful, so that things like esearch could find things in the official overlays that are not actually present on the user's system. The "majority" of packages are also the ones that need more extensive testing. Sure, we could probably stabilize a bunch of the fringe packages that hardly anyone uses and it wouldn't affect anything. The majority of Aliz's database seems to be made up of these "fringe" packages. Many of which are stable on at least one arch already, or have only a single version in the tree anyway. Stabilizing these on the remaining archs that they support should not have any significant impact on the perceived overall quality of Gentoo. Another problem is that we don't *know* what is being run by our users. This is something that the Summer of Code project for a Gentoo Stats project should at least help with, as it will give us an insight into what is actually being used and what isn't. I hope that all users subscribe to this, it will only be useful with a large enough pool of people submitting their stats. It would also be great if Aliz's database incorporated this information when it becomes available. 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 out, rather than sitting back and complaining. Complaining helps nobody. Please don't interpret my original message as a complaint. It isn't. It is mostly a question of the process. My understanding of stabilization bugs was that they should be the exception, not the rule... that you might not be able to make a commitment, or even want to do so. However, every single bug report that you file *is* helping out... and every little bit helps. ...and I was wrong. Regards, -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
* Steve Dibb <[EMAIL PROTECTED]> schrieb: > That's actually how I read the first email, was that it's really the > majority of the _minor_ packages that get completely neglected, and > just sits in the tree for months or years marked unstable because > nobody cares. then the users probably didn't put enough preasure on the stabelizing teams ;-P As I suggested in my last mail: an tool which files stabelizing requests for installed packages after some time (semi-)automatically could help a lot. Once I've got some spare time, I'll sit down and code something. Anyone who likes to join me ? cu -- - 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
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
* Chris Gianelloni <[EMAIL PROTECTED]> schrieb: > > 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. > 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 ... > > 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. > > Honest
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
Chris Gianelloni wrote: I'd say no bugs, 30 days, passes internal tests, being run by users => stablise, for the majority of packages (obviously, there may be some exceptions...). Luckily, you're not making the call. ;] The "majority" of packages are also the ones that need more extensive testing. Sure, we could probably stabilize a bunch of the fringe packages that hardly anyone uses and it wouldn't affect anything. That's actually how I read the first email, was that it's really the majority of the _minor_ packages that get completely neglected, and just sits in the tree for months or years marked unstable because nobody cares. The people that use it have marked it ~arch a long time ago in their package.keywords because they know it works just fine. THAT stuff I wouldn't mind going through and just bumping to stable myself. They don't need extensive testing, they don't need patches, they work, and have been working, and just need arches flagged and versions bumped. But, nobody likes doing the small stuff, and I can't blame them. Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On Thu, 2006-07-27 at 10:34 +0100, Roy Bamford wrote: > Maybe this semi-automatic stabilisation by default could be adopted by > the tree cleaners project? I propose that we remove the name "project" from any "team" that really consists of only one or two people. I think part of the problem is that many people assume that because there is a project, there must be some kind of support structure behind it. Another thing that doesn't help is the number of people that "join" a project, but don't actually *do* anything for the project. I implore all developers to do the following. If you are listed as a member of a project, but aren't actively participating, remove yourself from the list. Perhaps if our tools showed the real state of things, rather than the utopian non-truth, we would get help in the places where it is really needed. A good example of this is the x86 team. There are currently 15 developers listed. At most, 5 of them are active on the team. This makes it look like the team has plenty of help, when the truth is that the team is barely managing to keep their heads above water. Users don't know that the team needs help, because the numbers look so large artificially. This problem gives everyone the wrong impression of the state of affairs within Gentoo and keeps us from being able to get help or provide help in the areas that need it most. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On Thu, 2006-07-27 at 10:00 +0100, Chris Bainbridge wrote: > I would also like to see that (though maybe with some automated > feedback from users systems as to which packages are installed / how > often they are run). All that the current process ensures is that: Any automated system will cause serious problems for the quality of the distribution without several orders of magnitude of more powerful hardware on our side. > 1) thousands of packages will never be marked stable Honestly, they shouldn't be stable. 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. > 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. 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. > 3) Debugging user bugs when users have a mixed x86/~x86 system is a > lot more complicated. Every system ends up being a unique combination > of different packages and versions. This isn't even an issue. Every Gentoo system is a unique combination of packages and versions, USE flags, CFLAGS, etc. > 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. Every user that someone knowledgeable gets to use something they don't understand, is a potential bug report slowing stabilization even more. > 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. 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 of the Gentoo developers feel a stronger sense of duty to the users, and would prefer not shove a bunch of crap down the pipe onto people's computers. There are a few of the developers that are followers of the "ricer" philosophy, claiming that they don't mind a few bugs here and there. Well, the number of bugs in bugzilla shows that our users simply don't agree. > I'd say no bugs, 30 days, passes interna
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On 2006.07.27 10:00, Chris Bainbridge wrote: On 27/07/06, Stefan Schweizer <[EMAIL PROTECTED]> wrote: [snip] As a better system I would like to see packages stable automatically after 30 days and no bugs. But this is probably not going to happen with gentoo so I just stay away from stable and put ACCEPT_KEYWORDS in my make.conf [snip] 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? I'd say no bugs, 30 days, passes internal tests, being run by users => stablise, for the majority of packages (obviously, there may be some exceptions...). -- gentoo-dev@gentoo.org mailing list Maybe this semi-automatic stabilisation by default could be adopted by the tree cleaners project? Maybe I'll get flamed for even thinking that. Regards, Roy Bamford -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On 27/07/06, Stefan Schweizer <[EMAIL PROTECTED]> wrote: The problem is in the system. Unless you are a developer _and_ part of the arch team you cannot do anything but file a bug and wait and wait and wait until a member of the arch team decides to test the package again for his own and mark it stable. So with the current system the arch teams cannot cover all the packages. I would say for your litle pet package to get stable you have little chances. And you would not want it stable anyway, because stable marking usually lacks behind the bugs of the package. That means you most certainly will hit the bugs and a month later when someone has filed a bug _and_ the package herd or developer has said yes _and_ a developer from the arch team has tested it the bug will be stable, too. As a better system I would like to see packages stable automatically after 30 days and no bugs. But this is probably not going to happen with gentoo so I just stay away from stable and put ACCEPT_KEYWORDS in my make.conf I would also like to see that (though maybe with some automated feedback from users systems as to which packages are installed / how often they are run). All that the current process ensures is that: 1) thousands of packages will never be marked stable 2) Everyone running stable who wants some recent packages ends up with /etc/portage/package.keywords with hundreds of entries 3) Debugging user bugs when users have a mixed x86/~x86 system is a lot more complicated. Every system ends up being a unique combination of different packages and versions. 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. 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? I'd say no bugs, 30 days, passes internal tests, being run by users => stablise, for the majority of packages (obviously, there may be some exceptions...). -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
Richard Fish wrote: > On 7/2/06, Daniel Ahlberg <[EMAIL PROTECTED]> wrote: >> Hi, >> >> This is an automatically created email message. >> http://gentoo.tamperd.net/stable has just been updated with 15968 >> ebuilds. > > A question [1] has come up on -user about why some ebuilds take so > long to become stable for an arch. This isn't the old "when will we > have KDE yesterday.3am" type question. In reviewing the above > database, and the OP, it looks like a fair number of ebuilds that > could/should be stable are not. > > Of particular concern to me are packages that: > > a) have no open bugs. > b) are marked stable on some archs, but not others. > c) may have only a single version available in portage. > > As an example, consider net-analyzer/etherape, which is "~amd64 ppc > sparc x86", and has no open bugs (other than a version bump request), > and only a single version available in portage to begin with. > > So my question is: is there anything that interested users can do to > help here? I know we can file stabilization bugs, but I agree with > Robert [1] that this should not be necessary in the normal case. > Besides, do you _really_ want 16,000 new bug reports that say nothing > more than "blah/foo works for me, please stabilize"! Is the problem a > lack of time, devs, arch testers, or interested users? The problem is in the system. Unless you are a developer _and_ part of the arch team you cannot do anything but file a bug and wait and wait and wait until a member of the arch team decides to test the package again for his own and mark it stable. So with the current system the arch teams cannot cover all the packages. I would say for your litle pet package to get stable you have little chances. And you would not want it stable anyway, because stable marking usually lacks behind the bugs of the package. That means you most certainly will hit the bugs and a month later when someone has filed a bug _and_ the package herd or developer has said yes _and_ a developer from the arch team has tested it the bug will be stable, too. As a better system I would like to see packages stable automatically after 30 days and no bugs. But this is probably not going to happen with gentoo so I just stay away from stable and put ACCEPT_KEYWORDS in my make.conf Things you can do for stabilization to go better: - file a lot of bugs and wait - become an arch tester and test packages to recommend them for stabilization. Of course they still need testing by a developer in the team then. - look for developers and ask them to comment on stale bugs to get them solved To get involved the best way is maybe to show up in IRC in the arch team channel like #gentoo-x86. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords
On Mon, 10 Apr 2006 08:44:49 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Monday 10 April 2006 04:19, Michael Sterrett -Mr. Bones.- wrote: > > On Mon, 10 Apr 2006, Paul de Vrieze wrote: > > > On Monday 10 April 2006 05:26, Daniel Ahlberg wrote: > > >> * if ebuild has $PN in SRC_URI (cosmetic). > > > > > > Why is this one bad? It creates some flexibility, and has the name of the > > > package in one place only. > > > > Because you can't cut-n-paste the url when editing the ebuild. > > eh ? a sourceforge SRC_URI that uses $PN can easily be cut & paste ... > -mike yeah - isn't this argument lost the second you have a SRC with mirror? (i'm a known violator of this cosmetic convenience, so i might just be biased here) ~mcummings -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords
On Monday 10 April 2006 04:19, Michael Sterrett -Mr. Bones.- wrote: > On Mon, 10 Apr 2006, Paul de Vrieze wrote: > > On Monday 10 April 2006 05:26, Daniel Ahlberg wrote: > >> * if ebuild has $PN in SRC_URI (cosmetic). > > > > Why is this one bad? It creates some flexibility, and has the name of the > > package in one place only. > > Because you can't cut-n-paste the url when editing the ebuild. eh ? a sourceforge SRC_URI that uses $PN can easily be cut & paste ... -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: aging ebuilds with unstable keywords
Because you can't cut-n-paste the url when editing the ebuild. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] On Mon, 10 Apr 2006, Paul de Vrieze wrote: On Monday 10 April 2006 05:26, Daniel Ahlberg wrote: * if ebuild has $PN in SRC_URI (cosmetic). Why is this one bad? It creates some flexibility, and has the name of the package in one place only. Paul -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: aging ebuilds with unstable keywords
Andrej Kacian wrote: > On Sun, 20 Nov 2005 20:39:43 -0600 > R Hill <[EMAIL PROTECTED]> wrote: > >>> * if ebuild installs COPYING and/or INSTALL into doc. >> Is this actually important? There are a hell of a lot of ebuilds that fail >> under this rule. I'd like to start filing patches for some of the packages >> in this list so I'm interested in knowing what's worth fixing and what's >> being pedantic. > > Note that some of the packages caught by this test also install non-generic > (thus actually useful) INSTALL document. Yep, i did notice that. Most of them on this list are, but i'm still weeding through them. --de. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords
On Sun, 20 Nov 2005 20:39:43 -0600 R Hill <[EMAIL PROTECTED]> wrote: > > * if ebuild installs COPYING and/or INSTALL into doc. > > Is this actually important? There are a hell of a lot of ebuilds that fail > under this rule. I'd like to start filing patches for some of the packages > in this list so I'm interested in knowing what's worth fixing and what's > being pedantic. Note that some of the packages caught by this test also install non-generic (thus actually useful) INSTALL document. -- Andrej "Ticho" Kacian Gentoo Linux Developer - net-mail, antivirus, sound, x86 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords
R Hill wrote: > Daniel Ahlberg wrote: > > >>* if ebuild installs COPYING and/or INSTALL into doc. > > > Is this actually important? There are a hell of a lot of ebuilds that fail > under this rule. I'd like to start filing patches for some of the packages in > this list so I'm interested in knowing what's worth fixing and what's being > pedantic. > Not a blocker but just useless. Filing patches for ebuilds doing this is greatly appreciated by at least me. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: aging ebuilds with unstable keywords
Daniel Ahlberg wrote: > * if ebuild installs COPYING and/or INSTALL into doc. Is this actually important? There are a hell of a lot of ebuilds that fail under this rule. I'd like to start filing patches for some of the packages in this list so I'm interested in knowing what's worth fixing and what's being pedantic. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: aging ebuilds with unstable keywords
Anthony Gorecki posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 12 Sep 2005 01:09:34 -0700: > On Sunday, September 11, 2005 20:42, Daniel Ahlberg wrote: >> The page shows results from a number of tests that are run against the > ebuilds. > > Why does this script no longer include the results in the actual message? > It was helpful to have both as a reference source. Well, the idea was helpful, but (as an amd64 user) I'm not entirely sure the implementation was all that helpful. The problem was due to the non-x86 "imlate" tracking. Unfortunately, it didn't work right, with the result normally meaning the top-10 spots as listed in the message, were all ~amd64 entries where ~arch (for some arch, normally x86) had been added several hundred days earlier (before there /was/ a Gentoo amd64 arch, AFAIK), because it had no way of tracking when the ~amd64 keyword was added, and incorrectly assumed that the package had been ~amd64 since the package was keyworded ~arch for /one/ arch at that point. As one of the newer and more active archs, just then adding ~arch for the first time to many apps, this was particularly frustrating for amd64, since it left the impression the amd64 arch-team were a bunch of slackers (no offense to slackware folks) that left packages in ~arch for hundreds of days at a time, for little reason. So... if the script now ignores that factor, at least when calculating the top-10, or if it has been fixed to correct the issue (a non-trivial task, someone remarked at one point, because the info wasn't directly available), and assuming there are no other such "spammer factors", it /could/ be /very/ useful. However, personally, at least, I'd /not/ like to see it return in the broken state it was in, as I can't imagine that being anything but frustration, to those responsible for the ebuilds wrongly listed, due to a broken script. (Not that my personal opinion means a lot as "just" a user, on a dev list, but FWIW, whatever /that/ may be.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
