1 |
On Monday 30 July 2001 22:17, you wrote: |
2 |
> On Mon, Jul 30, 2001 at 07:40:19PM +0300, Dan Armak wrote: |
3 |
> > Just an idea: what if users (those who agree, of course), when doing |
4 |
> > emerge rsync, transmit to the gentoo server anonymous info on which |
5 |
> > packages they have installed? If not, maybe at least the developers? |
6 |
> > |
7 |
> > The rationale: I have twice now faced a problem where a complex ebuild I |
8 |
> > built and commited quite some time ago wasn't functioning. And I said to |
9 |
> > myself, this is a very important program who's ebuild isn't working! If |
10 |
> > this was a generic problem I would be flooded with emails from the other |
11 |
> > people who use it! And I wanted to find these other people who used it, |
12 |
> > but there were none among the gentoo developers, and I couldn't contact |
13 |
> > any of the users. |
14 |
> |
15 |
> This is confusing. What I read (and probably not what you ment to say) is |
16 |
> that when ppl try to use an ebuild that doesn't work, they will not tell us |
17 |
> about it? |
18 |
They will, but not through the system I propose. |
19 |
We will at some point have a standard bug report feature/script. I proposed a |
20 |
complementary system which tells us when an ebuild *does* work - which can |
21 |
also be very important |
22 |
|
23 |
> |
24 |
> > This way, we'll know what ebuilds are *known* to work properly - at least |
25 |
> > under some h/w configurations - and most importantly, in what |
26 |
> > combinations and revisions. And it will give the users a painless way to |
27 |
> > help us. |
28 |
> |
29 |
> Many people find it quite painful to share details about their systems. |
30 |
> They tend to exagerate it into all kinds of personal invasion. Even when |
31 |
> there are perfectly good arguments that it is not. In something like this, |
32 |
> what people think it is has more weight than what it really is. |
33 |
Well, we'll juts turn it off by default, and have the user read an |
34 |
explanation and decide whether to turn it on. |
35 |
|
36 |
> |
37 |
> > Finally, we'll also know what packages are most often used, in what |
38 |
> > combinations, and thus (as far as we work for our users) what areas to |
39 |
> > concentrate upon. |
40 |
> > |
41 |
> > What do you think? |
42 |
> |
43 |
> Other than my automatic rejection to collecting info, Someone wil have to |
44 |
> spend a good deal of time building the collection system. And right now I |
45 |
> think energy could be better spent elsewhere. |
46 |
The info would be fully anonymous, as is the rsync protocol. I'd want the |
47 |
info that e.g. such and such combination of ebuilds works together in such |
48 |
and such revisions. Like getting the directory tree of /var/db/pkg without |
49 |
the files. The used make flags, etc. could also be useful. The user could |
50 |
customize what info to report. |
51 |
|
52 |
As for building the system, the user-side thing would be a couple of pages |
53 |
long at most, since we already have an rsync implementation in emerge. |
54 |
|
55 |
The server-side thing could be more or less complex, depending on how |
56 |
powerful the system would be. Making a database with dynamic online |
57 |
frontends, queries, comparisons etc. etc. would certainly be quite difficult |
58 |
but we don't necessarily need all that functionality. |
59 |
|
60 |
> |
61 |
> I can see how the information would be useful. And I would suggest a |
62 |
> script that users can run, view the collected infomation, and upload |
63 |
> somewhere over anything automatic. By putting the details into the hands |
64 |
> of the users, and letting them see exactly what they are going to send |
65 |
> (they wouldn't have to look at the contents, but we should give them the |
66 |
> chance) before they send it, people will likey be more comfortable about |
67 |
> sharing the info. |
68 |
As you say. |
69 |
|
70 |
> |
71 |
> |
72 |
> I imagin I just really confused things.... |
73 |
|
74 |
hallski posted much the same questions, see my reply to him. |
75 |
|
76 |
-- |
77 |
|
78 |
Dan Armak |
79 |
Gentoo Linux Developer, Desktop Team |
80 |
Matan, Israel |