Re: [gentoo-dev] [news-item] Paludis 0.24

[Ciaran McCreesh]

On Sat, 5 May 2007 16:40:12 +0200
"Wulf C. Krueger" <philantrop@g.o> wrote:
> On Saturday, May 5, 2007 04:14:25 PM Ciaran McCreesh wrote:
> > > Currently, there are two news item in the Paludis overlay. Unless
> > > earlier ones were removed, those two seem to be a fairly small
> > > sample to deduce anything from.
> > They were.
>
> How many news items did you issue? (It's probably easier for you to
> say instead of me searching the entire history of the overlay. :-) )

Er, four iirc.

> Which are those "serious upgrade or compatibility problems" you're
> trying to avoid? Paludis warned about the change at runtime only. For
> "serious problems" I'm sure you'd make it error out, wouldn't you?

The serious problem is a lot of deprecation warning notices. We know
from the last couple of times that we made changes to the configuration
format (once with a news item, once without) that users are much
happier when they do get a news item.

> > > The real problem with issuing news items for trivial changes is
> > > that people will just start marking such news items read without
> > > really reading them or even stop synching news items completely.
> > This is not a trivial change.
>
> (Could you please try to argument instead of just making statements?)

It's a simple fact, not an argument.

> The old configuration format still works. Thus, from a user's point
> of view, it is a trivial change.

Using the old configuration format leads to noisy warnings. Users don't
like noisy warnings. They like explanations for this kind of change.

> > > Then, elog and friends would be fully sufficient for informing
> > > users about such configuration changes - under the circumstances
> > > of this case at least.
> > We already know from similar cases that this isn't true.
>
> Yes, you've been repeating that over and over. At least one example
> would probably help to understand the point you're trying to make.

We've done two changes of this nature previously.

The first change was for eclassdir -> eclassdirs and profile ->
profiles (with a similar backwards compatible deprecation warning, not
a breakage). We issued a news item for it. It was well received by end
users, many of whom commented that they appreciated the notice and
hoped that the delivery mechanism would be used more in the future.
There were no complaints about the news item being a waste of their
time.

The second change was in how we handled wildcarding in keywords.conf.
There was no news item, only release notes and postinst notices. Users
were upset that they weren't notified about the change, even though
they were, and it lead to a bunch of spurious support requests and bug
reports.

Hence my point: every single user who has commented upon the news items
we've delivered has done so positively, and the nature of Paludis means
we receive more accurate user feedback than maintainers of most other
packages. All evidence currently available suggests that this approach
is the best option. Once it's been tried to a wider audience there will
be more evidence available and we can and will reassess the decision to
see if there are ways of improving the process before it gets used for
something of much wider importance and scope.

The only real problem here is that GLEP 42 doesn't include a
Display-If-Upgrading-From-To: header. This was a deliberate design
decision, to avoid imposing substantially higher complexity
requirements upon the package manager -- the workaround is to use
Display-If-Installed: >=whatever and remove the news item once it is
reasonably expected to be no longer relevant. This isn't ideal, but
given the delays in Portage implementing even simple support it was
probably the right decision for a 1.0 news item specification.

-- 
Ciaran McCreesh