On Sat, 5 May 2007 16:40:12 +0200 "Wulf C. Krueger" <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
