Re: [gentoo-dev] Gentoostats, SoC 2011
On Wed, Aug 24, 2011 at 5:05 AM, Rich Freeman wrote: > On Wed, Aug 24, 2011 at 7:45 AM, Thomas Kahle wrote: >> Sorry, but NO. If you want you can make a big noise message that asks >> users to install the cron-job but opt-out is not an option here. > > Well, that's up to the Council/Trustees ultimately, but opinions (and > better still reasoning) are welcome since both would no-doubt want to > reflect the will of the community (and whatever is legal in the > jurisdictions that matter). It doesn't take a council vote nor a trustees vote to add a package to everyone's machine. In the end I'd recommend just looking at the opt-in numbers. Is the data useful from opt-in users? If the answer is no, then we can always think up other ways to get more users. Will auto-installs be on the list of ideas? You bet ;) But I think we are putting the cart before the horse. > > One option that many distros employ is a forced opt-in/out decision. > During the install process they simply ask the user, and they have to > hit either yes or no to continue. The reason most people don't opt-in > is that they don't think about it, and this forces the issue. > > The Gentoo analogue would be to put something in make.conf or whatever > that must be set one way or another. Maybe have an opt-in use flag > and an opt-out use flag and if you don't set either emerge just dies > with a notice or something. No doubt somebody could come up with a > more elegant solution. The stage3 tarball doesn't even come with a dhcp client; so I don't really see how installing a stats client makes sense from the standpoint of 'only what is necessary.' For many people, that is an important part of Gentoo (cf. python3...) Making emerge die unless you make a decision will probably break a bunch of shit (plenty of people have automatic installs in some fashion.) We would have to use an existing methodology to avoid breaking them (PROPERTIES=interactive?) > > Maybe another line of discussion that could inform the debate is what > the value of this information is? For a company, knowing what > packages are popular helps them to allocate resources. Gentoo is a > volunteer effort and devs allocate their effort based on personal > preference, though perhaps some would care about package popularity to > an extent. So, we might not benefit to the same degree from this kind > of information, since we can't crack the whip and force people to fix > some broken package that is popular. I think at present we don't know the informations value; that is part of why considering opt-out is premature ;) > > Rich > >
[gentoo-dev] Re: Gentoostats, SoC 2011
Rich Freeman posted on Wed, 24 Aug 2011 07:07:54 -0400 as excerpted: > On Wed, Aug 24, 2011 at 6:48 AM, Patrick Lauer > wrote: >> If you sneakily add something to cron.daily by default you can get >> pretty nice coverage. But I guess anyone trying that in Gentooland will >> meet some rather unpleasant resistance :) > > Well, we could always broadcast the news widely (lists, forums, > eselect news, and so on). > > I'd also make it controllable via use flag. Put the client and the > cron.daily file in a package, and then make that a use-dependency of > something everybody has (the profile if profiles support this (don't > think they do), and if not pick something that correlates well with > people who would benefit from this feature. > > Users can opt-out via use flag. > > You can also start out with it being opt-in (use flag off by default in > profiles), and then turn it on later (with notice/etc). > > The key is to not be sneaky about it. Agreed on the no-sneaky bit. The practical question is what to make it a USE flag of? Baselayout/ openrc? Portage? Personally, I'd start with a couple paragraphs in the handbook describing the package and why one really /does/ want it installed and setup but that Gentoo gives the user the option, as part of the installation section, presumably thrown in with choosing the cron and syslog daemons, etc. Then I'd do the PR thing as you mention, pointing out that it's in the handbook now, so new users will likely be installing it, and to avoid skewing the numbers toward the new installations, existing installations should consider it as well. Existing users aren't likely to want the focus to shift to packages only the noobs are likely to install, for instance. Setup a bit of a competition there, and I'd guess you're likely to get better buy-in from existing users. I'd leave the USE flag dependency out of it, at least initially. It could always be added later, if thought necessary. But I suspect that if it's presented well in the handbook, many new users will install it, and if that fact is pointed out to existing users in appropriate forum/list threads, etc, many existing users will as well, just to "keep up", statistically. Yet if it's a separate package that must be separately installed, there's no way people can say it wasn't their choice, as they might be able to if it's a USE flag they weren't paying attention to, particularly if that flag defaults on. Make it an active choice and people are far more likely to continue with it, too, than if they felt in any way that it was pushed on them, with little choice. -- 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
Re: [gentoo-dev] Gentoostats, SoC 2011
On Wed, Aug 24, 2011 at 7:45 AM, Thomas Kahle wrote: > Sorry, but NO. If you want you can make a big noise message that asks > users to install the cron-job but opt-out is not an option here. Well, that's up to the Council/Trustees ultimately, but opinions (and better still reasoning) are welcome since both would no-doubt want to reflect the will of the community (and whatever is legal in the jurisdictions that matter). One option that many distros employ is a forced opt-in/out decision. During the install process they simply ask the user, and they have to hit either yes or no to continue. The reason most people don't opt-in is that they don't think about it, and this forces the issue. The Gentoo analogue would be to put something in make.conf or whatever that must be set one way or another. Maybe have an opt-in use flag and an opt-out use flag and if you don't set either emerge just dies with a notice or something. No doubt somebody could come up with a more elegant solution. Maybe another line of discussion that could inform the debate is what the value of this information is? For a company, knowing what packages are popular helps them to allocate resources. Gentoo is a volunteer effort and devs allocate their effort based on personal preference, though perhaps some would care about package popularity to an extent. So, we might not benefit to the same degree from this kind of information, since we can't crack the whip and force people to fix some broken package that is popular. Rich
Re: [gentoo-dev] Gentoostats, SoC 2011
i am a user and i am ok with opt-out if the std data that is transferd is compleatly anonymized so no sensitive data. and if the user wants to register his/her machine pkg's more data is trasnfered thx Mario 2011/8/24 Thomas Kahle : > On 13:03 Wed 24 Aug 2011, Andreas K. Huettel wrote: >> Am Mittwoch 24 August 2011, 12:48:35 schrieb Patrick Lauer: >> > >> > If you sneakily add something to cron.daily by default you can get >> > pretty nice coverage. But I guess anyone trying that in Gentooland will >> > meet some rather unpleasant resistance :) >> > >> >> Of course, we could place it in some blatantly obvious way into a default >> configuration, together with a big fat message what it does and how to >> quickly disable it. >> >> We'd get better coverage in an opt-out system than in an opt-in system. >> >> (First idea- package is pulled in by a default-on useflag and installs >> itself into cron.daily. BEFORE it runs the first time it outputs said >> message and asks for permission to proceed (which cannot be done in the cron >> job obviously but we'd find a way).) > > Sorry, but NO. If you want you can make a big noise message that asks > users to install the cron-job but opt-out is not an option here. > > > > -- > Thomas Kahle > http://dev.gentoo.org/~tomka/ >
Re: [gentoo-dev] Gentoostats, SoC 2011
On 13:03 Wed 24 Aug 2011, Andreas K. Huettel wrote: > Am Mittwoch 24 August 2011, 12:48:35 schrieb Patrick Lauer: > > > > If you sneakily add something to cron.daily by default you can get > > pretty nice coverage. But I guess anyone trying that in Gentooland will > > meet some rather unpleasant resistance :) > > > > Of course, we could place it in some blatantly obvious way into a default > configuration, together with a big fat message what it does and how to > quickly disable it. > > We'd get better coverage in an opt-out system than in an opt-in system. > > (First idea- package is pulled in by a default-on useflag and installs itself > into cron.daily. BEFORE it runs the first time it outputs said message and > asks for permission to proceed (which cannot be done in the cron job > obviously but we'd find a way).) Sorry, but NO. If you want you can make a big noise message that asks users to install the cron-job but opt-out is not an option here. -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: Digital signature
Re: [gentoo-dev] Gentoostats, SoC 2011
On 12:48 Wed 24 Aug 2011, Patrick Lauer wrote: > On 08/24/11 12:31, Thomas Kahle wrote: > > Hi, > > > > On 18:16 Tue 23 Aug 2011, Andreas K. Huettel wrote: > >> there is one important aspect of your program that really needs to be > >> documented (and comments in the code are not enough): > >> > >> What data exactly is the client sending to the server?! > >> > >> What you need is basically an easy-to-find file / web page / ... where > >> this is explained concise and in simple words. As long as that does > >> not exist, your program will not find much acceptance. > > > > > > You may look at the files README and FAQ for Ubuntu's popularity > > contest: http://popcon.ubuntu.com/ > > > > If we could get their turnout rates, that'd be great. > > If you sneakily add something to cron.daily by default you can get > pretty nice coverage. But I guess anyone trying that in Gentooland will > meet some rather unpleasant resistance :) Oh yeah... when I used Ubuntu last 11/06 it would still ask you on install. @Vikraman: I guess you see how *important* it is to be completely open and explain everything the program does. On Gentoo it should of course be opt-in, instead of opt-out. -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: Digital signature
Re: [gentoo-dev] Gentoostats, SoC 2011
On Wed, Aug 24, 2011 at 6:48 AM, Patrick Lauer wrote: > If you sneakily add something to cron.daily by default you can get > pretty nice coverage. But I guess anyone trying that in Gentooland will > meet some rather unpleasant resistance :) Well, we could always broadcast the news widely (lists, forums, eselect news, and so on). I'd also make it controllable via use flag. Put the client and the cron.daily file in a package, and then make that a use-dependency of something everybody has (the profile if profiles support this (don't think they do), and if not pick something that correlates well with people who would benefit from this feature. Users can opt-out via use flag. You can also start out with it being opt-in (use flag off by default in profiles), and then turn it on later (with notice/etc). The key is to not be sneaky about it. Rich
Re: [gentoo-dev] Gentoostats, SoC 2011
Am Mittwoch 24 August 2011, 12:48:35 schrieb Patrick Lauer: > > If you sneakily add something to cron.daily by default you can get > pretty nice coverage. But I guess anyone trying that in Gentooland will > meet some rather unpleasant resistance :) > Of course, we could place it in some blatantly obvious way into a default configuration, together with a big fat message what it does and how to quickly disable it. We'd get better coverage in an opt-out system than in an opt-in system. (First idea- package is pulled in by a default-on useflag and installs itself into cron.daily. BEFORE it runs the first time it outputs said message and asks for permission to proceed (which cannot be done in the cron job obviously but we'd find a way).) -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Gentoostats, SoC 2011
On 08/24/11 12:31, Thomas Kahle wrote: > Hi, > > On 18:16 Tue 23 Aug 2011, Andreas K. Huettel wrote: >> there is one important aspect of your program that really needs to be >> documented (and comments in the code are not enough): >> >> What data exactly is the client sending to the server?! >> >> What you need is basically an easy-to-find file / web page / ... where >> this is explained concise and in simple words. As long as that does >> not exist, your program will not find much acceptance. > > > You may look at the files README and FAQ for Ubuntu's popularity > contest: http://popcon.ubuntu.com/ > > If we could get their turnout rates, that'd be great. If you sneakily add something to cron.daily by default you can get pretty nice coverage. But I guess anyone trying that in Gentooland will meet some rather unpleasant resistance :)
Re: [gentoo-dev] Gentoostats, SoC 2011
Hi, On 18:16 Tue 23 Aug 2011, Andreas K. Huettel wrote: > there is one important aspect of your program that really needs to be > documented (and comments in the code are not enough): > > What data exactly is the client sending to the server?! > > What you need is basically an easy-to-find file / web page / ... where > this is explained concise and in simple words. As long as that does > not exist, your program will not find much acceptance. You may look at the files README and FAQ for Ubuntu's popularity contest: http://popcon.ubuntu.com/ If we could get their turnout rates, that'd be great. > Apart from that, I like the entire project, and am curious about its > results. +1 It has come up several times that getting usage statistics would motivate developers. Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: Digital signature
[gentoo-dev] Re: Implicit system dependencies
Il giorno mer, 24/08/2011 alle 19.49 +1000, Michael ha scritto: > > Is /this/ considered to be a bug? Do I just write a patch to stop > linking > against libs that aren't needed? Yes this is a bug in gpgme, it has to RDEPEND on libassuan rather than just DEPEND on it, since it reports it to --libs. Or it should simply not report it on --libs. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: Implicit system dependencies
On Wed, Aug 24, 2011 at 12:31:29AM -0700, Tim Harder wrote: > On 2011-08-24 Wed 00:21, Diego Elio Petten?? wrote: > > Il giorno mar, 23/08/2011 alle 23.52 -0700, Tim Harder ha scritto: > > > I thought xz-utils can be assumed as well since it was added to the > > > system set almost six months ago [1]. > > > It has really very little to do with being in the system set or not. And > > the answer is no, you cannot assume that... > > So then why do bzip2 and gzip get special exceptions? Majority rule? :) Age. Making the mistake once doesn't mean we should make it twice. ;) > Anyway, I think getting implicit unpack depends based on SRC_URI > suffixes like Mike mentioned will be great. Proposals welcome; my personal preference is to see extensions mapped into some form of repository configuration... ~harring
[gentoo-dev] Re: Implicit system dependencies
Diego Elio Pettenò wrote: > Il giorno mar, 23/08/2011 alle 05.21 +1000, Michael ha scritto: >> >> Any thoughts to as how far I should go with filing bugs regarding >> this >> issue? > > Please if you're going to file bugs about this, do so only on a system > built with _forced_ --as-needed, otherwise you're going to hit a long > list of false positives (gpgstats seems to be one of those, since it > does not use symbols from libassuan or gpg-error, even though it links > to those on your system. > > Especially since I'm not sure most fo the developers would know how to > confirm your reports (hint: scanelf -n on the files on a system that is > built with forced --as-needed, I can provide such data myself from the > tinderbox). > Fair enough, sorry for the bugspam, and thanks for the tip. While I now see that gpgstats does not actually depend on libassuan or gpg- error, the build process still fails without them: x86_64-pc-linux-gnu-g++ -Wl,--hash-style=gnu -Wl,--as-needed -Wall -W error.o utils.o array.o iarray.o s.o -o gpgstats `gpgme-config --libs` /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux- gnu/bin/ld: cannot find -lassuan collect2: ld returned 1 exit status make: *** [gpgstats] Error 1 emake failed Is /this/ considered to be a bug? Do I just write a patch to stop linking against libs that aren't needed? Best regards, Michael
Re: [gentoo-dev] Re: Re: Implicit system dependencies
On 2011-08-24 Wed 00:21, Diego Elio Pettenò wrote: > Il giorno mar, 23/08/2011 alle 23.52 -0700, Tim Harder ha scritto: > > I thought xz-utils can be assumed as well since it was added to the > > system set almost six months ago [1]. > It has really very little to do with being in the system set or not. And > the answer is no, you cannot assume that... So then why do bzip2 and gzip get special exceptions? Majority rule? :) Anyway, I think getting implicit unpack depends based on SRC_URI suffixes like Mike mentioned will be great. Tim pgpG153mkT8f5.pgp Description: PGP signature
[gentoo-dev] Re: Re: Implicit system dependencies
Il giorno mar, 23/08/2011 alle 23.52 -0700, Tim Harder ha scritto: > I thought xz-utils can be assumed as well since it was added to the > system set almost six months ago [1]. It has really very little to do with being in the system set or not. And the answer is no, you cannot assume that... -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
