Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Gentoostats, SoC 2011
Date: Wed, 24 Aug 2011 13:05:04
Message-Id: pan.2011.08.24.13.03.19@cox.net
In Reply to: Re: [gentoo-dev] Gentoostats, SoC 2011 by Rich Freeman
1 Rich Freeman posted on Wed, 24 Aug 2011 07:07:54 -0400 as excerpted:
2
3 > On Wed, Aug 24, 2011 at 6:48 AM, Patrick Lauer <patrick@g.o>
4 > wrote:
5 >> If you sneakily add something to cron.daily by default you can get
6 >> pretty nice coverage. But I guess anyone trying that in Gentooland will
7 >> meet some rather unpleasant resistance :)
8 >
9 > Well, we could always broadcast the news widely (lists, forums,
10 > eselect news, and so on).
11 >
12 > I'd also make it controllable via use flag. Put the client and the
13 > cron.daily file in a package, and then make that a use-dependency of
14 > something everybody has (the profile if profiles support this (don't
15 > think they do), and if not pick something that correlates well with
16 > people who would benefit from this feature.
17 >
18 > Users can opt-out via use flag.
19 >
20 > You can also start out with it being opt-in (use flag off by default in
21 > profiles), and then turn it on later (with notice/etc).
22 >
23 > The key is to not be sneaky about it.
24
25 Agreed on the no-sneaky bit.
26
27 The practical question is what to make it a USE flag of? Baselayout/
28 openrc? Portage?
29
30 Personally, I'd start with a couple paragraphs in the handbook describing
31 the package and why one really /does/ want it installed and setup but
32 that Gentoo gives the user the option, as part of the installation
33 section, presumably thrown in with choosing the cron and syslog daemons,
34 etc.
35
36 Then I'd do the PR thing as you mention, pointing out that it's in the
37 handbook now, so new users will likely be installing it, and to avoid
38 skewing the numbers toward the new installations, existing installations
39 should consider it as well. Existing users aren't likely to want the
40 focus to shift to packages only the noobs are likely to install, for
41 instance. Setup a bit of a competition there, and I'd guess you're
42 likely to get better buy-in from existing users.
43
44 I'd leave the USE flag dependency out of it, at least initially. It
45 could always be added later, if thought necessary. But I suspect that if
46 it's presented well in the handbook, many new users will install it, and
47 if that fact is pointed out to existing users in appropriate forum/list
48 threads, etc, many existing users will as well, just to "keep up",
49 statistically. Yet if it's a separate package that must be separately
50 installed, there's no way people can say it wasn't their choice, as they
51 might be able to if it's a USE flag they weren't paying attention to,
52 particularly if that flag defaults on. Make it an active choice and
53 people are far more likely to continue with it, too, than if they felt in
54 any way that it was pushed on them, with little choice.
55
56 --
57 Duncan - List replies preferred. No HTML msgs.
58 "Every nonfree program has a lord, a master --
59 and if you use the program, he is your master." Richard Stallman