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 |