Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
I remember distinctly that I once publicly proposed to change http://packages.gentoo.org/ to actually interpret packages' metadata.xml and displaying its formatted contents on every http://packages.gentoo.org/package/CAT/PKG page Excellent idea, it would be great to have that on the packages.g.o site by default. -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mon, Apr 4, 2011 at 9:26 PM, Jeroen Roovers j...@gentoo.org wrote: On Sun, 27 Mar 2011 23:28:05 +0200 René 'Necoro' Neumann li...@necoro.eu wrote: Am 27.03.2011 22:44, schrieb Rich Freeman: Well, but you need some way of communicate that certain packages are w/o a proper maintainer. Why else should someone step up? I, for instance, was quite surprised about the list of m-n packages and seeing that quite some packages I use are on that list. I would never had a look at it without this thread (or are users nowadays supposed to check metadata.xml on a regular basis?). I remember distinctly that I once publicly proposed to change http://packages.gentoo.org/ to actually interpret packages' metadata.xml and displaying its formatted contents on every http://packages.gentoo.org/package/CAT/PKG page (notably because the site mentioned and still mentions the last committer at the top of the page, with his or her Gentoo e-mail alias/handle plainly visible, so at the time I envisioned it to prevent people from addressing the wrong developers). metadata.xml is a mere link on every page and doesn't invite anyone to dig deeper, when it could be put to better use. Our bugzilla database already has proper descriptions for every alias we use, so we could reuse that information to improve packages.g.o. http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml ? (Only, I cannot now find any trace of such a discussion at all, or even the bug report I am quite certain I would have filed about this.) jer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Tue, 5 Apr 2011 03:58:05 -0700 Alec Warner anta...@gentoo.org wrote: http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml People tend to visit http://packages.gentoo.org/ when they find a problem with a package, to find out more about the package, like who maintains it. You wouldn't visit the URL above unless you already knew about the maintenance status of a package. jer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, 27 Mar 2011 23:28:05 +0200 René 'Necoro' Neumann li...@necoro.eu wrote: Am 27.03.2011 22:44, schrieb Rich Freeman: Well, but you need some way of communicate that certain packages are w/o a proper maintainer. Why else should someone step up? I, for instance, was quite surprised about the list of m-n packages and seeing that quite some packages I use are on that list. I would never had a look at it without this thread (or are users nowadays supposed to check metadata.xml on a regular basis?). I remember distinctly that I once publicly proposed to change http://packages.gentoo.org/ to actually interpret packages' metadata.xml and displaying its formatted contents on every http://packages.gentoo.org/package/CAT/PKG page (notably because the site mentioned and still mentions the last committer at the top of the page, with his or her Gentoo e-mail alias/handle plainly visible, so at the time I envisioned it to prevent people from addressing the wrong developers). metadata.xml is a mere link on every page and doesn't invite anyone to dig deeper, when it could be put to better use. Our bugzilla database already has proper descriptions for every alias we use, so we could reuse that information to improve packages.g.o. (Only, I cannot now find any trace of such a discussion at all, or even the bug report I am quite certain I would have filed about this.) jer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, 27 Mar 2011 13:17:46 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. That would never work with m-n packages that other packages *DEPEND on. jer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 15:30, Jeremy Olexa darks...@gentoo.org wrote: Why does anyone need to *add* a package that is maintainer-needed? Regardless of how we might want to get rid of m-n packages, I do wonder about who commits them, and why. For example, while looking into the list of m-n packages, I also found dev-python/remoteobjects-, which was also entered into the tree by vapier as m-n. vapier, what's the rationale behind including these packages in the tree? And if you need them, why can't you maintain them? (I'm asking this as a member of the Python project, where we probably wouldn't mind picking up some python m-n packages.) Cheers, Dirkjan
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 10:15 AM, Jeremy Olexa darks...@gentoo.org wrote: On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote: Index: metadata.xml === ?xml version=1.0 encoding=UTF-8? !DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd; pkgmetadata herdno-herd/herd maintainer emailmaintainer-nee...@gentoo.org/email /maintainer /pkgmetadata Can this practice of adding m-n packages to gentoo-x86 be stopped? If you add it, take responsibility for it, please. If you don't want to take responsibility for it, at least find a team that is willing to look after it. If you prohibit people from doing that, they'll just commit it normally, and then remove themselves a week later. I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 01:17:46PM +0530, Nirbheek Chauhan wrote: On Sun, Mar 27, 2011 at 10:15 AM, Jeremy Olexa darks...@gentoo.org wrote: On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote: Index: metadata.xml === ?xml version=1.0 encoding=UTF-8? !DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd; pkgmetadata herdno-herd/herd maintainer emailmaintainer-nee...@gentoo.org/email /maintainer /pkgmetadata Can this practice of adding m-n packages to gentoo-x86 be stopped? If you add it, take responsibility for it, please. If you don't want to take responsibility for it, at least find a team that is willing to look after it. If you prohibit people from doing that, they'll just commit it normally, and then remove themselves a week later. I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team Uhm no. The fact that nobody takes care of it doesn't necessarily mean that the package is broken and that it should be removed Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgpMZ35rXvm0k.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 3:59 PM, Markos Chandras hwoar...@gentoo.org wrote: On Sun, Mar 27, 2011 at 01:17:46PM +0530, Nirbheek Chauhan wrote: On Sun, Mar 27, 2011 at 10:15 AM, Jeremy Olexa darks...@gentoo.org wrote: Can this practice of adding m-n packages to gentoo-x86 be stopped? If you add it, take responsibility for it, please. If you don't want to take responsibility for it, at least find a team that is willing to look after it. If you prohibit people from doing that, they'll just commit it normally, and then remove themselves a week later. I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. Uhm no. The fact that nobody takes care of it doesn't necessarily mean that the package is broken and that it should be removed I never said that such packages were broken. I'm saying that if no one wants to maintain them, they probably aren't needed by anyone, and we should clean such cruft from the tree. If they *are* needed by someone, then those folks should come forward to maintain it. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Treeclean all maintainer-needed packages, was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
Nirbheek Chauhan schrieb: I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. Uhm no. The fact that nobody takes care of it doesn't necessarily mean that the package is broken and that it should be removed I never said that such packages were broken. I'm saying that if no one wants to maintain them, they probably aren't needed by anyone, and we should clean such cruft from the tree. If they *are* needed by someone, then those folks should come forward to maintain it. The only such package I would like to see go is net-misc/mDNSResponder. And I am not convinced that having a maintainer listed in metadata.xml makes the package automatically non-cruft, or that orphaned packages are not at all cared about. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote: On Sun, Mar 27, 2011 at 10:15 AM, Jeremy Olexadarks...@gentoo.org wrote: On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote: Index: metadata.xml === ?xml version=1.0 encoding=UTF-8? !DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd; pkgmetadata herdno-herd/herd maintainer emailmaintainer-nee...@gentoo.org/email /maintainer /pkgmetadata Can this practice of adding m-n packages to gentoo-x86 be stopped? If you add it, take responsibility for it, please. If you don't want to take responsibility for it, at least find a team that is willing to look after it. If you prohibit people from doing that, they'll just commit it normally, and then remove themselves a week later. Why does anyone need to *add* a package that is maintainer-needed? This is one of the problems of the gentoo-x86 tree - too many maintainer-needed packages. It is a bad thing for our users because when they submit bugs and/or fixes, they go [generally] unnoticed for ages. Also, as you may know, the treecleaner team is constantly fighting with removing m-n packages. The tree has 679 m-n packages. http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. That is abit extreme for me (read: I don't have motivation to fight the flames), but I wouldn't complain if someone else did it to be honest. -Jeremy
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 7:00 PM, Jeremy Olexa darks...@gentoo.org wrote: On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote: If you prohibit people from doing that, they'll just commit it normally, and then remove themselves a week later. Why does anyone need to *add* a package that is maintainer-needed? This is one of the problems of the gentoo-x86 tree - too many maintainer-needed packages. I'm just pointing out that if you prohibit that by policy, this is what people will do. The real problem is that maintainer-needed packages are allowed to remain in the tree *indefinitely*. I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. That is abit extreme for me (read: I don't have motivation to fight the flames), but I wouldn't complain if someone else did it to be honest. Just start removing old[1] maintainer-needed packages. If people complain, tell them to start maintaining it. If they continue to complain, ignore them. As tree-cleaner, you have the power to do this and not take bullshit from people about it. 1. Set old as one month, with a 2 month package.mask duration before it's removed. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 9:30 AM, Jeremy Olexa darks...@gentoo.org wrote: On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote: On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote: I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. That is abit extreme for me (read: I don't have motivation to fight the flames), but I wouldn't complain if someone else did it to be honest. So, I'd like to propose that somewhere between adding stuff to the tree that nobody has any intent to look after, and removing stuff that has been around a long time with no clear problems, there is a happy medium. How about this - if you add a package to the tree, you are responsible for it for at least a year. If you can get somebody else to take it then that is fine. If it has problems QA can flame you (privately at first) for it, and you should feel appropriately embarrassed and fix it, or remove it. After a year, it can go maintainer-needed. Before a year, it cannot, and you either need to actually maintain it, or remove it. Developers should not be adding packages they have no interest in whatsoever, or that have so many QA issues initially that they're high-maintenance right from the start. If a dev gets a package from a proxy-maintainer and they disappear then they can nurse it along or remove it as makes sense - we should be nice to these devs but we shouldn't just cut the packages loose. Packages that are maintainer-needed stay around as long as they're not making trouble. If they get lots of complaints they get announced on -dev, and after two weeks they get masked if not picked up. If they end up blocking something then likewise they get announced and then masked. That basically is the current practice anyway. I don't see a need to remove m-n packages wholesale just to say that we did it, or to punish users for not becoming devs or whatever. And of course, the usual long-term solutions like making proxy-maintaining easier should be pursued. Rich
Maintainership offering; was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
Am 27.03.2011 15:30, schrieb Jeremy Olexa: The tree has 679 m-n packages. http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml If you cannot find someone else as a maintainer and someone is willing to proxy me, I'd take dev-vcs/stgit: I use it on a daily basis (though only to manage my configs) and the current ebuild has been written by me (well - except the -r1-Diff). This would at least reduce the number of m-n packages to 678 :-) - René signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 27.3.2011 15:44, Rich Freeman napsal(a): On Sun, Mar 27, 2011 at 9:30 AM, Jeremy Olexa darks...@gentoo.org wrote: On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote: On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote: I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. That is abit extreme for me (read: I don't have motivation to fight the flames), but I wouldn't complain if someone else did it to be honest. So, I'd like to propose that somewhere between adding stuff to the tree that nobody has any intent to look after, and removing stuff that has been around a long time with no clear problems, there is a happy medium. How about this - if you add a package to the tree, you are responsible for it for at least a year. If you can get somebody else to take it then that is fine. If it has problems QA can flame you (privately at first) for it, and you should feel appropriately embarrassed and fix it, or remove it. After a year, it can go maintainer-needed. Before a year, it cannot, and you either need to actually maintain it, or remove it. Developers should not be adding packages they have no interest in whatsoever, or that have so many QA issues initially that they're high-maintenance right from the start. If a dev gets a package from a proxy-maintainer and they disappear then they can nurse it along or remove it as makes sense - we should be nice to these devs but we shouldn't just cut the packages loose. Packages that are maintainer-needed stay around as long as they're not making trouble. If they get lots of complaints they get announced on -dev, and after two weeks they get masked if not picked up. If they end up blocking something then likewise they get announced and then masked. That basically is the current practice anyway. I don't see a need to remove m-n packages wholesale just to say that we did it, or to punish users for not becoming devs or whatever. And of course, the usual long-term solutions like making proxy-maintaining easier should be pursued. Rich And how exactly you want to track the level of failure for the package? Since nobody is watching them already we usually don't know how much they fail until somebody tries to emerge them from dev team or notify QA by adding as CC to bug... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2PT5MACgkQHB6c3gNBRYdepgCfYUo00PKNQFoa+ZaqGoPTHOuv Dd8Ani+d1sa/jIHvrWyZrwOF3UUkESl8 =k1EI -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mar 27, 2011 11:01 AM, Tomáš Chvátal scarab...@gentoo.org wrote: And how exactly you want to track the level of failure for the package? Since nobody is watching them already we usually don't know how much they fail until somebody tries to emerge them from dev team or notify QA by adding as CC to bug... If a tree falls in the forest...does anybody care? Broken packages that nobody notices don't cost us much. A tinderbox sweep will id and tag them for cleaning eventually. All I'm saying is that the problem is broken packages, so address those, m-n or otherwise. By all means be proactive about finding maintainers, but let's not go purging working packages. As far as how broken is too broken - if it causes the distro headaches, address it. That could be blockers, or tons of bug reports, or whatever... Rich
Re: Maintainership offering; was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On 03/27/2011 09:08 AM, René 'Necoro' Neumann wrote: If you cannot find someone else as a maintainer and someone is willing to proxy me, I'd take dev-vcs/stgit: I use it on a daily basis (though % cvs di Index: metadata.xml === RCS file: /var/cvsroot/gentoo-x86/dev-vcs/stgit/metadata.xml,v retrieving revision 1.1 diff -u -r1.1 metadata.xml --- metadata.xml6 Mar 2010 15:58:48 - 1.1 +++ metadata.xml27 Mar 2011 18:56:24 - @@ -3,6 +3,12 @@ pkgmetadata herdno-herd/herd maintainer - emailmaintainer-nee...@gentoo.org/email + emailgen...@necoro.eu/email + nameRené 'Necoro' Neumann/name + descriptionProxy maintainer, assign bugs/description +/maintainer +maintainer + emaildarks...@gentoo.org/email + descriptionProxy committer, CC bugs/description /maintainer /pkgmetadata All yours, pleasure to work with you. Please maintain a relationship on relevant bugs and poke me via personal email when I forget to do something =D (By the way, I know nothing of this package and will rely on you to do the work minus committing, I'll do that for you) -Jeremy
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 1:43 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: On Sun, Mar 27, 2011 at 7:00 PM, Jeremy Olexa darks...@gentoo.org wrote: On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote: If you prohibit people from doing that, they'll just commit it normally, and then remove themselves a week later. Why does anyone need to *add* a package that is maintainer-needed? This is one of the problems of the gentoo-x86 tree - too many maintainer-needed packages. I'm just pointing out that if you prohibit that by policy, this is what people will do. The real problem is that maintainer-needed packages are allowed to remain in the tree *indefinitely*. I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. That is abit extreme for me (read: I don't have motivation to fight the flames), but I wouldn't complain if someone else did it to be honest. Just start removing old[1] maintainer-needed packages. If people complain, tell them to start maintaining it. If they continue to complain, ignore them. As tree-cleaner, you have the power to do this and not take bullshit from people about it. The intent of the TreeCleaner project (years ago) was to essentially look for packages in bugzilla that had lots of bugs and no maintainer. For a while beandog essentially maintained a site that tracked this for us (Gentoo Package that need Lovin' was the awesome title.) From that list you either fixed the problems and commited them (e.g. you were a roving package maintainer) or you pmasked it and marked it for the deadpool. There is not much policy on treecleaning a package just because no one has touched it. Time since last touch was just one of a dozen indicators used to find packages that are broken (because a package not touched since 2006 is also not likely to compile.) -A 1. Set old as one month, with a 2 month package.mask duration before it's removed. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mon, Mar 28, 2011 at 12:47 AM, Alec Warner anta...@gentoo.org wrote: On Sun, Mar 27, 2011 at 1:43 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: Just start removing old[1] maintainer-needed packages. If people complain, tell them to start maintaining it. If they continue to complain, ignore them. As tree-cleaner, you have the power to do this and not take bullshit from people about it. The intent of the TreeCleaner project (years ago) was to essentially look for packages in bugzilla that had lots of bugs and no maintainer. For a while beandog essentially maintained a site that tracked this for us (Gentoo Package that need Lovin' was the awesome title.) From that list you either fixed the problems and commited them (e.g. you were a roving package maintainer) or you pmasked it and marked it for the deadpool. There is not much policy on treecleaning a package just because no one has touched it. Time since last touch was just one of a dozen indicators used to find packages that are broken (because a package not touched since 2006 is also not likely to compile.) Sure, that's the history. But what made sense back then doesn't make sense now. Back then we didn't have 600+ packages that no one maintains, and whose bugs go almost entirely unread. We had crazy amounts of manpower back then. As we evolve, the responsibilities of the different parts of Gentoo also evolve. As such, the tree-cleaners project has evolved, and if the team isn't allowed to clean the tree, then why do we even have it anymore? I really don't understand *why* people want to keep around unmaintained packages. If a package is not maintained, we should come up and say it outright. Trying to maintain the illusion of maintenance is really bad — for each person reporting a bug about a package, 100 people who got that same bug don't report it at all. So what happens when there are just 50 users for some packages? Half the time we won't even know that one of them is broken[1]. The rest of the time, users will get a bad impression of Gentoo saying Man, half the packages don't even work. It's really simple: (a) If the package has plenty of users, there should be no problems finding a maintainer or a proxy-maintainer. (b) If the package has few users and is high-maintenance, it's either already broken, or will get broken soon without a maintainer. Find one or remove it! (c) If the package has few users and is low-maintenance, package.mask it so we can figure out who the users are, and we can get them to proxy-maintain it, it's so little work anyway, right? (d) If the package has very few or no users, what the hell is it doing unmaintained in the tree? It's just eating up disk inodes and space. We all like to boast about how gentoo has 15,000 packages, but we neglect to mention that more than 1000 of these are either unmaintained or very poorly maintained. And this is a very conservative number. Let's not turn portage into a graveyard for packages. Let's just remove crap. 1. Writer is bad at statistics, this is probably inaccurate. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 7:40 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: On Mon, Mar 28, 2011 at 12:47 AM, Alec Warner anta...@gentoo.org wrote: On Sun, Mar 27, 2011 at 1:43 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: Just start removing old[1] maintainer-needed packages. If people complain, tell them to start maintaining it. If they continue to complain, ignore them. As tree-cleaner, you have the power to do this and not take bullshit from people about it. The intent of the TreeCleaner project (years ago) was to essentially look for packages in bugzilla that had lots of bugs and no maintainer. For a while beandog essentially maintained a site that tracked this for us (Gentoo Package that need Lovin' was the awesome title.) From that list you either fixed the problems and commited them (e.g. you were a roving package maintainer) or you pmasked it and marked it for the deadpool. There is not much policy on treecleaning a package just because no one has touched it. Time since last touch was just one of a dozen indicators used to find packages that are broken (because a package not touched since 2006 is also not likely to compile.) Sure, that's the history. But what made sense back then doesn't make sense now. Back then we didn't have 600+ packages that no one maintains, and whose bugs go almost entirely unread. We had crazy amounts of manpower back then. We probably had more than 600 unmaintained packages because no one was removing dead packages from the tree. I also dispute your manpower logic. Gentoo has been short on developers for years. I don't see how 2011 is any different than 2007 in this aspect. As we evolve, the responsibilities of the different parts of Gentoo also evolve. As such, the tree-cleaners project has evolved, and if the team isn't allowed to clean the tree, then why do we even have it anymore? The community got pissed when I deleted unmaintained packages from the tree 'just because it was unmaintained.' Thats why there were a set of criteria for removal. Maybe they changed their mind and you can convince them. Ignoring people's opinions because they are whiners and you are Treecleaners is a thin edge to walk though; so I'd be careful. At least during my tenure there were still hundreds of unmaintained and broken packages; so I didn't much care about unmaintained but working stuff (since there was plenty of work to do.) I would argue the tree is still in a similar state. I really don't understand *why* people want to keep around unmaintained packages. If a package is not maintained, we should come up and say it outright. Trying to maintain the illusion of maintenance is really bad — for each person reporting a bug about a package, 100 people who got that same bug don't report it at all. So what happens when there are just 50 users for some packages? Half the time we won't even know that one of them is broken[1]. The rest of the time, users will get a bad impression of Gentoo saying Man, half the packages don't even work. Properly tagged I don't think there is any illusion. Maintainer-needed is maintainer-needed after all. If half of the packages *in the tree* don't work then we have a problem. If half the packages *a user tries to install* are broken then they should certainly use another distro. Perhaps Gentoo is not for their area (and the key point is that it doesn't have to be.) It's really simple: (a) If the package has plenty of users, there should be no problems finding a maintainer or a proxy-maintainer. (b) If the package has few users and is high-maintenance, it's either already broken, or will get broken soon without a maintainer. Find one or remove it! (c) If the package has few users and is low-maintenance, package.mask it so we can figure out who the users are, and we can get them to proxy-maintain it, it's so little work anyway, right? (d) If the package has very few or no users, what the hell is it doing unmaintained in the tree? It's just eating up disk inodes and space. So launch gstats and get usage numbers. If no one is using a package that is a keen indicator it can be punted; however no one will get off their ass and get more data to back anything up (myself included...) All of your points above assume we have a decent metric of 'how many users a package has' and about the only way we know that is when users file bugs for it (version bump, bug, feature req, etc..) We all like to boast about how gentoo has 15,000 packages, but we neglect to mention that more than 1000 of these are either unmaintained or very poorly maintained. And this is a very conservative number. But again this is all made up...m-n was 670-odd packages last I checked. Do we still have m-w these days? Let's not turn portage into a graveyard for packages. Let's just remove crap. 1. Writer is bad at statistics, this is probably inaccurate. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 27 Mar 2011 08:30:16 -0500 Jeremy Olexa darks...@gentoo.org wrote: The tree has 679 m-n packages. http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml I want to proxy-maintain app-misc/pwsafe. It hasn't been updated in six years, but it still builds (albeit with a few warnings) and works and I use it and don't want to see it disappear. Is anyone willing to do this? Chris -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: GnuPT 2.7.2 iEYEARECAAYFAk2PnAEACgkQXUF6hOTGP7fSvACgls+xMxexfWytiXxYH0VwTY9c G1MAn3nKImR6inTrnh2Bsnq86rcsbzXd =pDQ6 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 3:40 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: It's really simple: (a) If the package has plenty of users, there should be no problems finding a maintainer or a proxy-maintainer. Uh, I guess that's why we are flooded with people wanting to be devs... There are lots of high-use packages that could use more maintainers. I'm not aware of any teams that would turn away help. (b) If the package has few users and is high-maintenance, it's either already broken, or will get broken soon without a maintainer. Find one or remove it! If it doesn't build, then it can be removed. Nobody is arguing with that. If you think that someday it might not build, then just wait a few months and if you're right you can satisfy your itch to prune the tree... (c) If the package has few users and is low-maintenance, package.mask it so we can figure out who the users are, and we can get them to proxy-maintain it, it's so little work anyway, right? Uh, package.mask is not intended to be an end-user communication tool. News is slightly better in this respect, but again this is not its purpose. We shouldn't be punishing people for not becoming developers. I don't want to use a distro that throws up warning messages every few months because some package I've been using had its developer retire, and I'm a developer. If it breaks and I care enough about it, I'll rescue it. If I'm passionate about it, I'll step in before it breaks. Holding users ransom is not the solution. (d) If the package has very few or no users, what the hell is it doing unmaintained in the tree? It's just eating up disk inodes and space. Uh, and how much does the inodes, space, and bandwidth consumed by those ~700 m-n packages actually cost. Are we talking about going through wailing and gnashing of teeth so that our stakeholders can save a total of 45 cents worth of disk space across 50 mirrors and 50,000 Gentoo boxes over the next 5 years? If one person is getting use out of it, and nobody is getting hurt, and it costs a few inodes, I'm fine with that. We all like to boast about how gentoo has 15,000 packages, but we neglect to mention that more than 1000 of these are either unmaintained or very poorly maintained. And this is a very conservative number. I don't know anybody who uses Gentoo because of our huge repository. Sure, compared to LFS it is big. Compared to most major distros, Gentoo isn't all that large. If all somebody wants is a ton of packages they're going to run Debian or whatever. Sure, we have a nice repository and we should be proud of it, but I don't think anybody is trying to over-inflate our repo size just by loading it up with junk. The thing I don't understand here is that there seems to be some perception that having stuff in the tree or in Bugzilla costs us something. Sure, at some level it does, and if 99.99% of portage were junk data, then we might have a problem. However, database records and inodes come billions for the dollar. Having a few percent more churn so that we can more gracefully handle the lifecycle of packages doesn't seem like much of a sacrifice. If you're tired of looking at junk when you search bugzilla, then you need to think about how you're searching it. These sorts of arguments come up at work all the time and unless there is some kind of regulatory issue at stake or real loss of revenue associated with lost opportunities, chasing down unnecessary database records to be tidy almost always costs far more than it saves. I'd be shocked if the total cost to our sponsors in mirror space for m-n packages exceeded the value of time spent by everybody reading this thread. I think we should be practical - I'm all for giving treecleaners a free hand when packages really cause problems, but being anal-retentive just for the sake of doing so doesn't seem to create real value. Rich
Re: Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mon, Mar 28, 2011 at 1:50 AM, Christopher Head hea...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 27 Mar 2011 08:30:16 -0500 Jeremy Olexa darks...@gentoo.org wrote: The tree has 679 m-n packages. http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml I want to proxy-maintain app-misc/pwsafe. It hasn't been updated in six years, but it still builds (albeit with a few warnings) and works and I use it and don't want to see it disappear. Is anyone willing to do this? I can proxy-maintain app-misc/pwsafe with you. I have no idea how pwsafe works, though, so I'll trust that you've done your homework w.r.t bumps or bugfixes :) There are currently two bugs open with pwsafe: https://bugs.gentoo.org/show_bug.cgi?id=347549 (stable req) https://bugs.gentoo.org/show_bug.cgi?id=292749 (cosmetic enhancement) You should open a bugzilla account so that I can assign these to you. However, the bugs aren't urgent, so we can tackle them when you have time. --- metadata.xml22 Mar 2009 02:35:03 - 1.5 +++ metadata.xml27 Mar 2011 20:46:54 - @@ -3,7 +3,13 @@ pkgmetadata herdno-herd/herd maintainer -emailmaintainer-nee...@gentoo.org/email + nameChristopher Head/name + emailhea...@gentoo.org/email + descriptionProxy maintainer, assign bugs/description + /maintainer + maintainer + nameNirbheek Chauhan/name +emailnirbh...@gentoo.org/email /maintainer longdescription lang=en pwsafe is a commandline password database utility compatible with -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
Am 27.03.2011 22:47, schrieb Nirbheek Chauhan: --- metadata.xml 22 Mar 2009 02:35:03 - 1.5 +++ metadata.xml 27 Mar 2011 20:46:54 - @@ -3,7 +3,13 @@ pkgmetadata herdno-herd/herd maintainer -emailmaintainer-nee...@gentoo.org/email + nameChristopher Head/name + emailhea...@gentoo.org/email That should be s/gentoo.org/gmail.com/, shouldn't it? signature.asc Description: OpenPGP digital signature
Re: Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 4:47 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: On Mon, Mar 28, 2011 at 1:50 AM, Christopher Head hea...@gmail.com wrote: --- metadata.xml 22 Mar 2009 02:35:03 - 1.5 +++ metadata.xml 27 Mar 2011 20:46:54 - @@ -3,7 +3,13 @@ pkgmetadata herdno-herd/herd maintainer - emailmaintainer-nee...@gentoo.org/email + nameChristopher Head/name + emailhea...@gentoo.org/email + descriptionProxy maintainer, assign bugs/description + /maintainer + maintainer + nameNirbheek Chauhan/name + emailnirbh...@gentoo.org/email /maintainer longdescription lang=en pwsafe is a commandline password database utility compatible with -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team - emailhea...@gentoo.org/email + emailhea...@gmail.com/email -- David Abbott (dabbott) Gentoo http://dev.gentoo.org/~dabbott/
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mon, Mar 28, 2011 at 2:14 AM, Rich Freeman ri...@gentoo.org wrote: On Sun, Mar 27, 2011 at 3:40 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: It's really simple: (a) If the package has plenty of users, there should be no problems finding a maintainer or a proxy-maintainer. Uh, I guess that's why we are flooded with people wanting to be devs... There are lots of high-use packages that could use more maintainers. I'm not aware of any teams that would turn away help. Everyone thinks all is dandy, and so no one volunteers. Why would someone volunteer their help if we don't advertise the need? Every single team I know has members that are there for historical value and don't do anything anymore. This means team member lists are inevitably artificially inflated. (b) If the package has few users and is high-maintenance, it's either already broken, or will get broken soon without a maintainer. Find one or remove it! If it doesn't build, then it can be removed. Nobody is arguing with that. If you think that someday it might not build, then just wait a few months and if you're right you can satisfy your itch to prune the tree... I think you missed my point about fewer users meaning the likelihood of bugs getting reported being low. And even if bugs get reported, who reads bug reports assigned to maintainer-nee...@gentoo.org? (c) If the package has few users and is low-maintenance, package.mask it so we can figure out who the users are, and we can get them to proxy-maintain it, it's so little work anyway, right? Uh, package.mask is not intended to be an end-user communication tool. News is slightly better in this respect, but again this is not its purpose. End-user? No. Potential developer? Yes. That's why we have a one-month package.mask period while last-riting unmaintained packages for QA problems. We shouldn't be punishing people for not becoming developers. I don't want to use a distro that throws up warning messages every few months because some package I've been using had its developer retire, and I'm a developer. If it breaks and I care enough about it, I'll rescue it. If I'm passionate about it, I'll step in before it breaks. Holding users ransom is not the solution. So you're worried that the oldness criteria in the policy should not be too strict? Cool, that's something for discussion. (d) If the package has very few or no users, what the hell is it doing unmaintained in the tree? It's just eating up disk inodes and space. Uh, and how much does the inodes, space, and bandwidth consumed by those ~700 m-n packages actually cost. Are we talking about going through wailing and gnashing of teeth so that our stakeholders can save a total of 45 cents worth of disk space across 50 mirrors and 50,000 Gentoo boxes over the next 5 years? If one person is getting use out of it, and nobody is getting hurt, and it costs a few inodes, I'm fine with that. One person who gets some use out of it, and how many who either can't compile it, or can't run it? This kind of thing affects how people see Gentoo. Besides, removal of a package from the tree doesn't mean there's no way to use it anymore. For those who still use that one package that no one else really uses anymore, local portdir_overlay configuration is really easy. We all like to boast about how gentoo has 15,000 packages, but we neglect to mention that more than 1000 of these are either unmaintained or very poorly maintained. And this is a very conservative number. I don't know anybody who uses Gentoo because of our huge repository. Sure, compared to LFS it is big. Compared to most major distros, Gentoo isn't all that large. If all somebody wants is a ton of packages they're going to run Debian or whatever. Note that most other distros have large package numbers because they split their packages into pkgname, pkgname-dev pkgname-doc, etc. I'm not sure if anyone counts source-package numbers for binary distros. Sure, we have a nice repository and we should be proud of it, but I don't think anybody is trying to over-inflate our repo size just by loading it up with junk. The thing I don't understand here is that there seems to be some perception that having stuff in the tree or in Bugzilla costs us something. Sure, at some level it does, and if 99.99% of portage were junk data, then we might have a problem. However, database records and inodes come billions for the dollar. Having a few percent more churn so that we can more gracefully handle the lifecycle of packages doesn't seem like much of a sacrifice. If you're tired of looking at junk when you search bugzilla, then you need to think about how you're searching it. These sorts of arguments come up at work all the time and unless there is some kind of regulatory issue at stake or real loss of revenue associated with lost opportunities, chasing down unnecessary database records to be tidy almost always costs far
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mon, Mar 28, 2011 at 1:47 AM, Alec Warner anta...@gentoo.org wrote: On Sun, Mar 27, 2011 at 7:40 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: Sure, that's the history. But what made sense back then doesn't make sense now. Back then we didn't have 600+ packages that no one maintains, and whose bugs go almost entirely unread. We had crazy amounts of manpower back then. We probably had more than 600 unmaintained packages because no one was removing dead packages from the tree. I also dispute your manpower logic. Gentoo has been short on developers for years. I don't see how 2011 is any different than 2007 in this aspect. The current problem is burnt-out or semi-active devs who commit occasionally, but aren't able to help with any herd-related work because they're out of touch. As such, their presence in the team gives a false indication of strength. This problem was much less severe in 2007 (afair). As we evolve, the responsibilities of the different parts of Gentoo also evolve. As such, the tree-cleaners project has evolved, and if the team isn't allowed to clean the tree, then why do we even have it anymore? The community got pissed when I deleted unmaintained packages from the tree 'just because it was unmaintained.' Thats why there were a set of criteria for removal. Maybe they changed their mind and you can convince them. Well, I bet that more than half of them retired or stopped being active. Ignoring people's opinions because they are whiners and you are Treecleaners is a thin edge to walk though; so I'd be careful. At least during my tenure there were still hundreds of unmaintained and broken packages; so I didn't much care about unmaintained but working stuff (since there was plenty of work to do.) I would argue the tree is still in a similar state. The fun part is that we really don't even know in what state those packages are w.r.t. runtime issues. I know that deigo's tinderbox keeps track of compile-time issues *extremely* well, but we have zero runtime testing. I really don't understand *why* people want to keep around unmaintained packages. If a package is not maintained, we should come up and say it outright. Trying to maintain the illusion of maintenance is really bad — for each person reporting a bug about a package, 100 people who got that same bug don't report it at all. So what happens when there are just 50 users for some packages? Half the time we won't even know that one of them is broken[1]. The rest of the time, users will get a bad impression of Gentoo saying Man, half the packages don't even work. Properly tagged I don't think there is any illusion. Maintainer-needed is maintainer-needed after all. The problem is that from the PoV of the user, everything in the tree is official. After all, that's how all the distros function. So launch gstats and get usage numbers. If no one is using a package that is a keen indicator it can be punted; however no one will get off their ass and get more data to back anything up (myself included...) If we launch gstats *today*, it'll take us at least a long time before we get decent numbers, and even after that, those numbers will be biased towards those people who are really active in following Gentoo news and developments. Unlike Firefox's usage stats, we have no way of prompting pre-existing gentoo installations with a Do want to take part in gstats? question. All of your points above assume we have a decent metric of 'how many users a package has' and about the only way we know that is when users file bugs for it (version bump, bug, feature req, etc..) Yes. But we have another (more reliable) way: p.mask it and wait for people to complain. We all like to boast about how gentoo has 15,000 packages, but we neglect to mention that more than 1000 of these are either unmaintained or very poorly maintained. And this is a very conservative number. But again this is all made up...m-n was 670-odd packages last I checked. Do we still have m-w these days? very poorly meant maintainers ignoring bugs for years, or empty herds. We have plenty of both. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
Am 27.03.2011 22:44, schrieb Rich Freeman: We shouldn't be punishing people for not becoming developers. I don't want to use a distro that throws up warning messages every few months because some package I've been using had its developer retire, and I'm a developer. If it breaks and I care enough about it, I'll rescue it. If I'm passionate about it, I'll step in before it breaks. Holding users ransom is not the solution. Well, but you need some way of communicate that certain packages are w/o a proper maintainer. Why else should someone step up? I, for instance, was quite surprised about the list of m-n packages and seeing that quite some packages I use are on that list. I would never had a look at it without this thread (or are users nowadays supposed to check metadata.xml on a regular basis?). So, why not at least add some elog-like output at the end of an emerge run like The following installed packages are without maintainer: $LIST. If you want to step up, please see $PROXY_MAINTAINER_URL. And before you state well - it is enough if someone steps up when it breaks: Even then it might get unnoticed, that the package is unmaintained. I never check thoroughly where the package gets assigned to during bug-wrangling, and I suppose that I'm not alone here. So the only thing one notices is a bug which never gets any response. And this is frustrating. Regarding the pro-active masking/removal: As a user I'd object to this. Please try a less obtrusive path first, like the info output I mentioned above. Seeing that used packages gets masked quite often spawns bad mood (at least in my experience and seeing reactions in forum threads). - René signature.asc Description: OpenPGP digital signature
Re: Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mon, Mar 28, 2011 at 2:25 AM, David Abbott dabb...@gentoo.org wrote: On Sun, Mar 27, 2011 at 4:47 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: On Mon, Mar 28, 2011 at 1:50 AM, Christopher Head hea...@gmail.com wrote: --- metadata.xml 22 Mar 2009 02:35:03 - 1.5 +++ metadata.xml 27 Mar 2011 20:46:54 - @@ -3,7 +3,13 @@ pkgmetadata herdno-herd/herd maintainer - emailmaintainer-nee...@gentoo.org/email + nameChristopher Head/name + emailhea...@gentoo.org/email + descriptionProxy maintainer, assign bugs/description + /maintainer + maintainer + nameNirbheek Chauhan/name + emailnirbh...@gentoo.org/email /maintainer longdescription lang=en pwsafe is a commandline password database utility compatible with -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team - emailhea...@gentoo.org/email + emailhea...@gmail.com/email Oops, fixed :) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On 02:39 Mon 28 Mar , Nirbheek Chauhan wrote: Where did this come from? My entire argument was based around the fact that unmaintained packages that may or may not be broken fundamentally constitute a *bad* experience for the user. If we cannot guarantee that bugs for a package will be fixed, we should not take up the responsibility of the package! Which is worse? Suddenly pulling a package from underneath the feet of users when it inevitably breaks or telling them upfront that it's *completely not* supported by us so they can do something about it before it breaks? Here's the key point: may or may not. Arbitrary criteria with no relevance to whether a package works for users are not helpful. The mere existence of a maintainer-needed package doesn't mean it should be removed. The existence of the same thing with numerous serious, unfixed bugs or tinderbox errors means something much different. We have the ability to do these kinds of intersections today, since our wonderful bug wranglers normally insert the $CAT/$PN into summaries and Diego has tinderbox bugs filed. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpjZzeJgz4hc.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On 17:34 Sun 27 Mar , Ryan Hill wrote: On Mon, 28 Mar 2011 02:55:14 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: If we launch gstats *today*, it'll take us at least a long time before we get decent numbers, and even after that, those numbers will be biased towards those people who are really active in following Gentoo news and developments. Unlike Firefox's usage stats, we have no way of prompting pre-existing gentoo installations with a Do want to take part in gstats? question. Last I checked we had a nifty news system for making announcements. And I thought we were supposed to have Smolt support like two years ago. What happened to it? I wonder the same question too, since it seems statistics is an eternally returning GSoC project. Sebastian, you worked on this in 2009. What needs to happen to get it deployed? -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpxww8cShQhy.pgp Description: PGP signature
