Gentoo Archives: gentoo-dev

From: Ciaran McCreesh <ciaranm@×××××××.org>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [news-item] Paludis 0.24
Date: Sat, 05 May 2007 15:07:28
Message-Id: 20070505160330.0a1c2b4f@snowflake
In Reply to: Re: [gentoo-dev] [news-item] Paludis 0.24 by "Wulf C. Krueger"
1 On Sat, 5 May 2007 16:40:12 +0200
2 "Wulf C. Krueger" <philantrop@g.o> wrote:
3 > On Saturday, May 5, 2007 04:14:25 PM Ciaran McCreesh wrote:
4 > > > Currently, there are two news item in the Paludis overlay. Unless
5 > > > earlier ones were removed, those two seem to be a fairly small
6 > > > sample to deduce anything from.
7 > > They were.
8 >
9 > How many news items did you issue? (It's probably easier for you to
10 > say instead of me searching the entire history of the overlay. :-) )
11
12 Er, four iirc.
13
14 > Which are those "serious upgrade or compatibility problems" you're
15 > trying to avoid? Paludis warned about the change at runtime only. For
16 > "serious problems" I'm sure you'd make it error out, wouldn't you?
17
18 The serious problem is a lot of deprecation warning notices. We know
19 from the last couple of times that we made changes to the configuration
20 format (once with a news item, once without) that users are much
21 happier when they do get a news item.
22
23 > > > The real problem with issuing news items for trivial changes is
24 > > > that people will just start marking such news items read without
25 > > > really reading them or even stop synching news items completely.
26 > > This is not a trivial change.
27 >
28 > (Could you please try to argument instead of just making statements?)
29
30 It's a simple fact, not an argument.
31
32 > The old configuration format still works. Thus, from a user's point
33 > of view, it is a trivial change.
34
35 Using the old configuration format leads to noisy warnings. Users don't
36 like noisy warnings. They like explanations for this kind of change.
37
38 > > > Then, elog and friends would be fully sufficient for informing
39 > > > users about such configuration changes - under the circumstances
40 > > > of this case at least.
41 > > We already know from similar cases that this isn't true.
42 >
43 > Yes, you've been repeating that over and over. At least one example
44 > would probably help to understand the point you're trying to make.
45
46 We've done two changes of this nature previously.
47
48 The first change was for eclassdir -> eclassdirs and profile ->
49 profiles (with a similar backwards compatible deprecation warning, not
50 a breakage). We issued a news item for it. It was well received by end
51 users, many of whom commented that they appreciated the notice and
52 hoped that the delivery mechanism would be used more in the future.
53 There were no complaints about the news item being a waste of their
54 time.
55
56 The second change was in how we handled wildcarding in keywords.conf.
57 There was no news item, only release notes and postinst notices. Users
58 were upset that they weren't notified about the change, even though
59 they were, and it lead to a bunch of spurious support requests and bug
60 reports.
61
62 Hence my point: every single user who has commented upon the news items
63 we've delivered has done so positively, and the nature of Paludis means
64 we receive more accurate user feedback than maintainers of most other
65 packages. All evidence currently available suggests that this approach
66 is the best option. Once it's been tried to a wider audience there will
67 be more evidence available and we can and will reassess the decision to
68 see if there are ways of improving the process before it gets used for
69 something of much wider importance and scope.
70
71 The only real problem here is that GLEP 42 doesn't include a
72 Display-If-Upgrading-From-To: header. This was a deliberate design
73 decision, to avoid imposing substantially higher complexity
74 requirements upon the package manager -- the workaround is to use
75 Display-If-Installed: >=whatever and remove the news item once it is
76 reasonably expected to be no longer relevant. This isn't ideal, but
77 given the delays in Portage implementing even simple support it was
78 probably the right decision for a 1.0 news item specification.
79
80 --
81 Ciaran McCreesh

Attachments

File name MIME type
signature.asc application/pgp-signature