[gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Hans de Graaff]

[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]

Hi,

I realize that we are in the middle of a huge discussion on GLEP 42 news
items, but I think I have a need for such a news item at the moment, and
getting more items to discuss may help move the discussion forward. I'm
appending the news item below.

That said, unfortunately GLEP 42 is not going to be useful for the
intended purpose... The reason for this is that it does not take into
account if the specific user can actually upgrade because it does not
take stable/testing into account. So a user on stable will see the
message once the new package hits the tree but can't upgrade yet, and
will probably have forgotten if the package moves to stable after one or
several months. 

What I would like to happen is that the message is added to the tree
once, shown to users who have dev-ruby/radiant in testing immediately,
and only shown to other users of dev-ruby/radiant when they move radiant
to testing or radiant itself becomes stable for them. I don't see a
mechanism to avoid this with the current GLEP, but perhaps I overlooked
something? I guess this is what the Display-If-Upgrading-From-To: that
Ciaran mentioned would do, but I'm wondering if GLEP 42 makes any sense
without it.

Granted, for Radiant specifically this point is moot since there is only
a version in testing, but the general point remains.

Kind regards,

Hans


Title: Radiant upgrade from 0.5.2 to 0.6.*
Author: Hans de Graaff <graaff@gentoo.org>
Content-Type: text/plain
Posted: 06-May-2007
Revision: 1
Display-If-Installed: =dev-ruby/radiant-0.5.2

Radiant 0.6.* is in many cases not a seamless update from 0.5.2, and
if you are currently running your site based on the gem then the
upgrade will break your site. Apart from a number of minor
configuration changes, the plugin system has been removed and changed
to a new extension system with slightly different semantics.

If you have any plugins installed in your Radiant installation you
will need to find replacement extensions first or rewrite the plugins
to use the extension system.

More information about upgrading can be found here:

  http://dev.radiantcms.org/radiant/wiki/HowToUpgrade05xTo06

and an overview of the changes including instructions to update
plugins here:

  http://seancribbs.com/tech/2007/04/18/whats-new-in-radiant-0-6/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

Hans de Graaff kirjoitti:
> 
> What I would like to happen is that the message is added to the tree
> once, shown to users who have dev-ruby/radiant in testing immediately,
> and only shown to other users of dev-ruby/radiant when they move radiant
> to testing or radiant itself becomes stable for them. I don't see a
> mechanism to avoid this with the current GLEP, but perhaps I overlooked
> something? I guess this is what the Display-If-Upgrading-From-To: that
> Ciaran mentioned would do, but I'm wondering if GLEP 42 makes any sense
> without it.
>

I guess we need a Display-If-Not-Masked: header.

Regards,
Petteri



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

Petteri Räty kirjoitti:
> Hans de Graaff kirjoitti:
>> What I would like to happen is that the message is added to the tree
>> once, shown to users who have dev-ruby/radiant in testing immediately,
>> and only shown to other users of dev-ruby/radiant when they move radiant
>> to testing or radiant itself becomes stable for them. I don't see a
>> mechanism to avoid this with the current GLEP, but perhaps I overlooked
>> something? I guess this is what the Display-If-Upgrading-From-To: that
>> Ciaran mentioned would do, but I'm wondering if GLEP 42 makes any sense
>> without it.
>>
> 
> I guess we need a Display-If-Not-Masked: header.
> 
> Regards,
> Petteri
> 

If filtering doesn't happen only once then we can do the following:
First start the news item with Display-If-Keyword: ~arch and then when
it goes stable lower it to arch. But I would guess that this way of
doing it is not supported by the current implementation and would need
to change the GLEP to state this so we could as well go with
Display-If-Not-Masked that takes into account local configuration etc.

Regards,
Petteri

PS. No-one has so far been able to tell me how the filtering is supposed
to work based on the GLEP so it should be made more explicit I think.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Hans de Graaff]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]

On Sun, 2007-05-06 at 11:48 +0300, Petteri Räty wrote:
> Hans de Graaff kirjoitti:
> > 
> > What I would like to happen is that the message is added to the tree
> > once, shown to users who have dev-ruby/radiant in testing immediately,
> > and only shown to other users of dev-ruby/radiant when they move radiant
> > to testing or radiant itself becomes stable for them. I don't see a
> > mechanism to avoid this with the current GLEP, but perhaps I overlooked
> > something? I guess this is what the Display-If-Upgrading-From-To: that
> > Ciaran mentioned would do, but I'm wondering if GLEP 42 makes any sense
> > without it.
> >
> 
> I guess we need a Display-If-Not-Masked: header.

I'm not sure what this header would do since you don't describe that,
but from the sound of it I'm not sure if this will help. The masking
isn't the problem by itself, but it makes that people will need to see
this message at different times, depending on when the package goes
stable and depending on what people do with their own package.keywords
file.

What I would like to happen from a user perspective is that the user is
presented with this particular news item whenever he would upgrade to
the new version of Radiant with 'emerge -D'.

Kind regards,

Hans

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]



Hans de Graaff kirjoitti:
> On Sun, 2007-05-06 at 11:48 +0300, Petteri Räty wrote:
>> Hans de Graaff kirjoitti:
>>> What I would like to happen is that the message is added to the tree
>>> once, shown to users who have dev-ruby/radiant in testing immediately,
>>> and only shown to other users of dev-ruby/radiant when they move radiant
>>> to testing or radiant itself becomes stable for them. I don't see a
>>> mechanism to avoid this with the current GLEP, but perhaps I overlooked
>>> something? I guess this is what the Display-If-Upgrading-From-To: that
>>> Ciaran mentioned would do, but I'm wondering if GLEP 42 makes any sense
>>> without it.
>>>
>> I guess we need a Display-If-Not-Masked: header.
> 
> I'm not sure what this header would do since you don't describe that,
> but from the sound of it I'm not sure if this will help. The masking
> isn't the problem by itself, but it makes that people will need to see
> this message at different times, depending on when the package goes
> stable and depending on what people do with their own package.keywords
> file.
> 
> What I would like to happen from a user perspective is that the user is
> presented with this particular news item whenever he would upgrade to
> the new version of Radiant with 'emerge -D'.
> 

Exactly that as ~arch means it's masked for stable users.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Dan Meltzer]

On Sunday 06 May 2007 4:48:33 am Petteri Räty wrote:
> Hans de Graaff kirjoitti:
> > What I would like to happen is that the message is added to the tree
> > once, shown to users who have dev-ruby/radiant in testing immediately,
> > and only shown to other users of dev-ruby/radiant when they move radiant
> > to testing or radiant itself becomes stable for them. I don't see a
> > mechanism to avoid this with the current GLEP, but perhaps I overlooked
> > something? I guess this is what the Display-If-Upgrading-From-To: that
> > Ciaran mentioned would do, but I'm wondering if GLEP 42 makes any sense
> > without it.
>
> I guess we need a Display-If-Not-Masked: header.

I'd think naming it Display-if-Visible would be a bit clearer, but the intent 
sounds right.
>
> Regards,
> Petteri


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[expose]

Hans de Graaff wrote:
> Hi,
>
> I realize that we are in the middle of a huge discussion on GLEP 42 news
> items, but I think I have a need for such a news item at the moment, and
> getting more items to discuss may help move the discussion forward. I'm
> appending the news item below.
>
> That said, unfortunately GLEP 42 is not going to be useful for the
> intended purpose... The reason for this is that it does not take into
> account if the specific user can actually upgrade because it does not
> take stable/testing into account. So a user on stable will see the
> message once the new package hits the tree but can't upgrade yet, and
> will probably have forgotten if the package moves to stable after one or
> several months.
>
> What I would like to happen is that the message is added to the tree
> once, shown to users who have dev-ruby/radiant in testing immediately,
> and only shown to other users of dev-ruby/radiant when they move radiant
> to testing or radiant itself becomes stable for them. I don't see a
> mechanism to avoid this with the current GLEP, but perhaps I overlooked
> something? I guess this is what the Display-If-Upgrading-From-To: that
> Ciaran mentioned would do, but I'm wondering if GLEP 42 makes any sense
> without it.
++

Considering the news item below, it does clearly show the difference to the 
paludis item, as it is indeed critical: There seems to be no foolproof method 
to fix this in a matter of seconds.
It fits into the group of new items which you dont even need to read, to know 
that you will likely need more than a few minutes to work through this and 
get things back working, just because it is a news item and nothing else.
I'd like those items to be the standard, not those which dont even break 
anything in the first place, and even further can be fixed in a matter of 
seconds using a foolproof method.
Additionally, the wording of the GLEP as far as I know it seems to support 
this, personal preference to or fro.
Corrections welcome.
> Title: Radiant upgrade from 0.5.2 to 0.6.*
> Author: Hans de Graaff <graaff@gentoo.org>
> Content-Type: text/plain
> Posted: 06-May-2007
> Revision: 1
> Display-If-Installed: =dev-ruby/radiant-0.5.2
>
> Radiant 0.6.* is in many cases not a seamless update from 0.5.2, and
> if you are currently running your site based on the gem then the
> upgrade will break your site. Apart from a number of minor
> configuration changes, the plugin system has been removed and changed
> to a new extension system with slightly different semantics.
>
> If you have any plugins installed in your Radiant installation you
> will need to find replacement extensions first or rewrite the plugins
> to use the extension system.
>
> More information about upgrading can be found here:
>
>   http://dev.radiantcms.org/radiant/wiki/HowToUpgrade05xTo06
>
> and an overview of the changes including instructions to update
> plugins here:
>
>   http://seancribbs.com/tech/2007/04/18/whats-new-in-radiant-0-6/
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Maurice van der Pot]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

On Sun, May 06, 2007 at 08:45:36AM +0200, Hans de Graaff wrote:
>   http://seancribbs.com/tech/2007/04/18/whats-new-in-radiant-0-6/

"The server is temporarily unable to service your request due to
maintenance downtime or capacity problems. Please try again later."

-- 
Maurice van der Pot

Gentoo Linux Developer   griffon26@gentoo.org     http://www.gentoo.org
Creator of BiteMe!       griffon26@kfk4ever.com   http://www.kfk4ever.com


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

On Sun, 06 May 2007 08:45:36 +0200
Hans de Graaff <graaff@gentoo.org> wrote:
> I guess this is what the Display-If-Upgrading-From-To: that Ciaran
> mentioned would do, but I'm wondering if GLEP 42 makes any sense
> without it.

Nope. Display-If-Upgrading-From-To: wouldn't trigger until the upgrade
actually happened. You want Display-If-Installed:, because users that
have earlier versions will be affected at some point in the future.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Hans de Graaff]

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

On Sun, 2007-05-06 at 16:33 +0100, Ciaran McCreesh wrote:
> On Sun, 06 May 2007 08:45:36 +0200
> Hans de Graaff <graaff@gentoo.org> wrote:
> > I guess this is what the Display-If-Upgrading-From-To: that Ciaran
> > mentioned would do, but I'm wondering if GLEP 42 makes any sense
> > without it.
> 
> Nope. Display-If-Upgrading-From-To: wouldn't trigger until the upgrade
> actually happened. 

Since this header is not documented anywhere yet let me ask the
following questions about it:

Will the news item be shown before or after the package gets merged?
If before, will the user have to acknowledge the news item (i.e. will
the merge process block until the user has been able to read the item?)

> You want Display-If-Installed:, because users that
> have earlier versions will be affected at some point in the future.

I'm afraid that this is not correct, because the semantics of
Display-If-Installed don't match the use case I described. Specifically,
it will cause the news item to be shown way to early for users on a
stable profile.

Kind regards,

Hans

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

On Sun, 06 May 2007 17:49:24 +0200
Hans de Graaff <graaff@gentoo.org> wrote:
> > Nope. Display-If-Upgrading-From-To: wouldn't trigger until the
> > upgrade actually happened. 
> 
> Since this header is not documented anywhere yet let me ask the
> following questions about it:
> 
> Will the news item be shown before or after the package gets merged?

After. For before, use Display-If-Installed: on a lower version.

> > You want Display-If-Installed:, because users that
> > have earlier versions will be affected at some point in the future.
> 
> I'm afraid that this is not correct, because the semantics of
> Display-If-Installed don't match the use case I described.
> Specifically, it will cause the news item to be shown way to early
> for users on a stable profile.

Thus giving them lots of notice, which is one of the things the GLEP
was designed to do.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[expose]

Ciaran McCreesh wrote:
> After. For before, use Display-If-Installed: on a lower version.
See below.

Ciaran McCreesh wrote:
> > > You want Display-If-Installed:, because users that
> > > have earlier versions will be affected at some point in the future.
> >
> > I'm afraid that this is not correct, because the semantics of
> > Display-If-Installed don't match the use case I described.
> > Specifically, it will cause the news item to be shown way to early
> > for users on a stable profile.
>
> Thus giving them lots of notice, which is one of the things the GLEP
> was designed to do.
If either the news item is shown once, it is bad because the user might forget 
about if until that package actually hits the stable branch.
If the news item is shown more than once - where I currently see no evidence 
for except one possible way "giving them lots of notice" could be 
interpreted, although this is in contrast to the GLEP as I understand it, it 
is bad because people will sooner or later be annoyed by this kind of 
behaviour when reading "ABI will break" for a zillion of times...

The only solution I currently see is an additional field in the header, a 
change in behaviour and therefore the GLEP itself.
In particular, this field could be my previous understanding 
of "Display-If-Upgrading-From-To" namely "Display-Before-Upgrading-From-To" 
which would fit the requirements defined by the GLEP:

"Preemptive
Users should be told of changes before they break a system, not after the 
damage has already been done. Ideally, the system administrator would be 
given ample warning to plan difficult upgrades and changes, rather than only 
being told just before action is necessary."
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

On Sun, 6 May 2007 18:20:31 +0200
expose@luftgetrock.net wrote:
> > Thus giving them lots of notice, which is one of the things the GLEP
> > was designed to do.
>
> If either the news item is shown once, it is bad because the user
> might forget about if until that package actually hits the stable
> branch.

The 'eselect news' module that ships with Paludis solves that problem.

> The only solution I currently see is an additional field in the
> header, a change in behaviour and therefore the GLEP itself.
> In particular, this field could be my previous understanding 
> of "Display-If-Upgrading-From-To" namely
> "Display-Before-Upgrading-From-To" which would fit the requirements
> defined by the GLEP:

It doesn't fit the preemptive requirement. That wouldn't be preemptive,
it would be last minute. One of the reasons for the GLEP is to remove
the need for last-minute pkg_setup die notices.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

On Sun, 6 May 2007 17:27:39 +0100
Ciaran McCreesh <ciaranm@ciaranm.org> wrote:

> On Sun, 6 May 2007 18:20:31 +0200
> expose@luftgetrock.net wrote:
> > The only solution I currently see is an additional field in the
> > header, a change in behaviour and therefore the GLEP itself.
> > In particular, this field could be my previous understanding 
> > of "Display-If-Upgrading-From-To" namely
> > "Display-Before-Upgrading-From-To" which would fit the requirements
> > defined by the GLEP:
> 
> It doesn't fit the preemptive requirement. That wouldn't be
> preemptive, it would be last minute. One of the reasons for the GLEP
> is to remove the need for last-minute pkg_setup die notices.

Assuming it would trigger on _available_ updates (and not only when
the actual upgrade is about to be performed) the relevant notice would
be shown at --sync and --pretend time, no? Then the user has the
opportunity to delay the update until he's prepared for the change, I
wouldn't call that last-minute.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

On Sun, 6 May 2007 19:16:11 +0200
Marius Mauch <genone@gentoo.org> wrote:
> Assuming it would trigger on _available_ updates (and not only when
> the actual upgrade is about to be performed) the relevant notice would
> be shown at --sync and --pretend time, no? Then the user has the
> opportunity to delay the update until he's prepared for the change, I
> wouldn't call that last-minute.

On available updates would be yet another different header. But that
particular situation is probably better solved by the proposed
pkg_pretend_post functionality...

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Hans de Graaff]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

On Sun, 2007-05-06 at 17:27 +0100, Ciaran McCreesh wrote:

> > If either the news item is shown once, it is bad because the user
> > might forget about if until that package actually hits the stable
> > branch.
> 
> The 'eselect news' module that ships with Paludis solves that problem.

I'm not familiar with either Paludis or the eselect news module. Could
you please explain in a few sentences how this problem is solved?

> 
> > The only solution I currently see is an additional field in the
> > header, a change in behaviour and therefore the GLEP itself.
> > In particular, this field could be my previous understanding 
> > of "Display-If-Upgrading-From-To" namely
> > "Display-Before-Upgrading-From-To" which would fit the requirements
> > defined by the GLEP:
> 
> It doesn't fit the preemptive requirement. That wouldn't be preemptive,
> it would be last minute. One of the reasons for the GLEP is to remove
> the need for last-minute pkg_setup die notices.

My intention would be to show these right after 'emerge --sync' or
'emerge --pretend', not when the package is about to be merged.

Hans

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

On Sun, 06 May 2007 20:43:08 +0200
Hans de Graaff <graaff@gentoo.org> wrote:
> On Sun, 2007-05-06 at 17:27 +0100, Ciaran McCreesh wrote:
> > > If either the news item is shown once, it is bad because the user
> > > might forget about if until that package actually hits the stable
> > > branch.
> > 
> > The 'eselect news' module that ships with Paludis solves that
> > problem.
> 
> I'm not familiar with either Paludis or the eselect news module. Could
> you please explain in a few sentences how this problem is solved?

Try it. It's easier to get a feel for the whole thing by using a
reference implementation than by reading a few sentences of description.

> > > The only solution I currently see is an additional field in the
> > > header, a change in behaviour and therefore the GLEP itself.
> > > In particular, this field could be my previous understanding 
> > > of "Display-If-Upgrading-From-To" namely
> > > "Display-Before-Upgrading-From-To" which would fit the
> > > requirements defined by the GLEP:
> > 
> > It doesn't fit the preemptive requirement. That wouldn't be
> > preemptive, it would be last minute. One of the reasons for the
> > GLEP is to remove the need for last-minute pkg_setup die notices.
> 
> My intention would be to show these right after 'emerge --sync' or
> 'emerge --pretend', not when the package is about to be merged.

Then you want the non-existent pkg_pretend_post() feature, not GLEP 42.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Vlastimil Babka]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
>> My intention would be to show these right after 'emerge --sync' or
>> 'emerge --pretend', not when the package is about to be merged.
> 
> Then you want the non-existent pkg_pretend_post() feature, not GLEP 42.

glep 42:

Checks for new news messages should be displayed:

    * After an emerge sync
    * After an emerge --pretend
    * Before an emerge <target> (which may also include a red warning
message)

- --
Vlastimil Babka (Caster)
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGPi/atbrAj05h3oQRAuueAKCjT25oLVyZ5BUpxoNUkcLeQXfDnQCcD+8L
RILu6tBvDbEBNDa8c9YzztY=
=PxQZ
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

On Sun, 06 May 2007 21:43:23 +0200
Vlastimil Babka <caster@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> >> My intention would be to show these right after 'emerge --sync' or
> >> 'emerge --pretend', not when the package is about to be merged.
> > 
> > Then you want the non-existent pkg_pretend_post() feature, not GLEP
> > 42.
> 
> glep 42:
> 
> Checks for new news messages should be displayed:
> 
>     * After an emerge sync
>     * After an emerge --pretend
>     * Before an emerge <target> (which may also include a red warning
> message)

*sigh*

The messages wouldn't be marked as 'to be read' at any of those points
for the situation being discussed.

Again, try out a reference implementation if you're having trouble
understanding the system and its implications.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

On Sun, 6 May 2007 18:20:31 +0200
expose@luftgetrock.net wrote:

> In particular, this field could be my previous understanding 
> of "Display-If-Upgrading-From-To" namely
> "Display-Before-Upgrading-From-To" which would fit the requirements
> defined by the GLEP:

Which is the same as a combination of Display-If-Installed and
Display-If-Visible but IMO not as ugly.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

On Sun, 6 May 2007 18:42:58 +0200
Marius Mauch <genone@gentoo.org> wrote:

> On Sun, 6 May 2007 18:20:31 +0200
> expose@luftgetrock.net wrote:
> 
> > In particular, this field could be my previous understanding 
> > of "Display-If-Upgrading-From-To" namely
> > "Display-Before-Upgrading-From-To" which would fit the requirements
> > defined by the GLEP:
> 
> Which is the same as a combination of Display-If-Installed and
> Display-If-Visible but IMO not as ugly.

Should correct that: I meant the combination of If-Installed and
If-Visible is IMO not as ugly as If/Before-Upgrading-From-To.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[expose]

Am Sonntag 06 Mai 2007 18:42 schrieb Marius Mauch:
> expose@luftgetrock.net wrote:
> > In particular, this field could be my previous understanding
> > of "Display-If-Upgrading-From-To" namely
> > "Display-Before-Upgrading-From-To" which would fit the requirements
> > defined by the GLEP:
>
> Which is the same as a combination of Display-If-Installed and
> Display-If-Visible but IMO not as ugly.

Not exactly the same. In fact, your combination is better, as it solves the 
issue mentioned by Ciaran when saying:
> That wouldn't be preemptive,
> it would be last minute.

So, in the case of the combination, the user would see the item directly, in 
the case of Display-If-Upgrading-From-To the user would only see it if he 
really wants to upgrade, which is "last minute".
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Sun, 6 May 2007 19:24:11 +0200
expose@luftgetrock.net wrote:
> So, in the case of the combination, the user would see the item
> directly, in the case of Display-If-Upgrading-From-To the user would
> only see it if he really wants to upgrade, which is "last minute".

No no no no no. When using Display-If-Upgrading-From-To, the user would
see it *after* the upgrade.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Mike Doty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sun, 6 May 2007 19:24:11 +0200
> expose@luftgetrock.net wrote:
>> So, in the case of the combination, the user would see the item
>> directly, in the case of Display-If-Upgrading-From-To the user would
>> only see it if he really wants to upgrade, which is "last minute".
> 
> No no no no no. When using Display-If-Upgrading-From-To, the user would
> see it *after* the upgrade.
> 
how is that different than using e{info,warn,error}?

- --
=======================================================
Mike Doty                      kingtaco -at- gentoo.org
Gentoo Council
Gentoo Infrastructure
Gentoo/AMD64 Strategic Lead
GPG: E1A5 1C9C 93FE F430 C1D6  F2AF 806B A2E4 19F4 AE05
=======================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)

iQCVAwUBRj4ShYBrouQZ9K4FAQJOPwQAwJqeukXzYx+3y2QILNeYwn82S26YwbP3
D75qq2CZS0T/H3efeJ5DLb9xWbfrj+wNJudbLHxXAoa1CmDy4j0oU6M5RcRoAUUe
smA5rVkGuKnOJXlzoEBAMJmbb4FONRvY/sX58U9xpKlbPliwO42g5diYeWdptXVk
naiU2HlYvww=
=reoq
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[expose]

Ciaran McCreesh wrote:
On Sun, 6 May 2007 19:24:11 +0200
> expose@luftgetrock.net wrote:
>> So, in the case of the combination, the user would see the item
>> directly, in the case of Display-If-Upgrading-From-To the user would
>> only see it if he really wants to upgrade, which is "last minute".
>
> No no no no no. When using Display-If-Upgrading-From-To, the user would
> see it *after* the upgrade.
I meant display-before-upgrading-from-to of course, as this is what's being 
responded to in this sub-thread.

Replying here, as I lost the "nonono-mail"
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

On Sun, 06 May 2007 10:38:14 -0700
Mike Doty <kingtaco@gentoo.org> wrote:
> how is that different than using e{info,warn,error}?

It stays visible until the user explicitly acknowledges reading it.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Dan Meltzer]

On Sunday 06 May 2007 1:58:57 pm Ciaran McCreesh wrote:
> On Sun, 06 May 2007 10:38:14 -0700
>
> Mike Doty <kingtaco@gentoo.org> wrote:
> > how is that different than using e{info,warn,error}?
>
> It stays visible until the user explicitly acknowledges reading it.

which elog could easily be extended to do.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

On Sun, 6 May 2007 14:08:01 -0400
Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> On Sunday 06 May 2007 1:58:57 pm Ciaran McCreesh wrote:
> > On Sun, 06 May 2007 10:38:14 -0700
> >
> > Mike Doty <kingtaco@gentoo.org> wrote:
> > > how is that different than using e{info,warn,error}?
> >
> > It stays visible until the user explicitly acknowledges reading it.
> 
> which elog could easily be extended to do.

But which elog does not do by default, and for good reason.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Dan Meltzer]

On Sunday 06 May 2007 2:11:14 pm Ciaran McCreesh wrote:
> On Sun, 6 May 2007 14:08:01 -0400
>
> Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > On Sunday 06 May 2007 1:58:57 pm Ciaran McCreesh wrote:
> > > On Sun, 06 May 2007 10:38:14 -0700
> > >
> > > Mike Doty <kingtaco@gentoo.org> wrote:
> > > > how is that different than using e{info,warn,error}?
> > >
> > > It stays visible until the user explicitly acknowledges reading it.
> >
> > which elog could easily be extended to do.
>
> But which elog does not do by default, and for good reason.

and what good reason would that be?


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

On Sun, 6 May 2007 14:17:29 -0400
Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > > which elog could easily be extended to do.
> >
> > But which elog does not do by default, and for good reason.
> 
> and what good reason would that be?

That elog is designed for post-install messages that aren't necessarily
relevant to many users.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Dan Meltzer]

On Sunday 06 May 2007 2:21:02 pm Ciaran McCreesh wrote:
> On Sun, 6 May 2007 14:17:29 -0400
>
> Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > > > which elog could easily be extended to do.
> > >
> > > But which elog does not do by default, and for good reason.
> >
> > and what good reason would that be?
>
> That elog is designed for post-install messages that aren't necessarily
> relevant to many users.

No, its designed to save messages for users to read.  It was implemented 
because important information scrolled off the screen in major updates.  If a 
user chooses not to read warn level messages from elog then they are 
responsible for the breakage, why abuse news for it?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

On Sun, 6 May 2007 14:39:13 -0400
Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> No, its designed to save messages for users to read.  It was
> implemented because important information scrolled off the screen in
> major updates.  If a user chooses not to read warn level messages
> from elog then they are responsible for the breakage, why abuse news
> for it?

One of the reasons GLEP 42 was necessary was because users *don't* read
things delivered by other methods.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Dan Meltzer]

On Sunday 06 May 2007 2:42:23 pm Ciaran McCreesh wrote:
> On Sun, 6 May 2007 14:39:13 -0400
>
> Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > No, its designed to save messages for users to read.  It was
> > implemented because important information scrolled off the screen in
> > major updates.  If a user chooses not to read warn level messages
> > from elog then they are responsible for the breakage, why abuse news
> > for it?
>
> One of the reasons GLEP 42 was necessary was because users *don't* read
> things delivered by other methods.

And they are magically going to read the news?

I doubt it if it continues to be as trivial as the first suggested item.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

On Sun, 6 May 2007 14:53:22 -0400
Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > One of the reasons GLEP 42 was necessary was because users *don't*
> > read things delivered by other methods.
> 
> And they are magically going to read the news?

Experience with a reference implementation strongly suggests that yes,
people will read the news.

> I doubt it if it continues to be as trivial as the first suggested
> item.

Paludis users do not consider that news item trivial.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Dan Meltzer]

On Sunday 06 May 2007 3:02:38 pm Ciaran McCreesh wrote:
> On Sun, 6 May 2007 14:53:22 -0400
>
> Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > > One of the reasons GLEP 42 was necessary was because users *don't*
> > > read things delivered by other methods.
> >
> > And they are magically going to read the news?

Experience being two news items about one package.  Expand this to a tree 
size, where the user has around 400-500 packages.  If they get news about 
changes that will increase their experience for each one of these, they are 
looking at reading the New York Times of gentoo every day.   It's not going 
to happen.
>
> Experience with a reference implementation strongly suggests that yes,
> people will read the news.
>
> > I doubt it if it continues to be as trivial as the first suggested
> > item.
>
> Paludis users do not consider that news item trivial.

If I was a paludis user I would considder this trivial.  The same information 
is availible a) from the package itself. b) from the changelog, and c) it 
still works without the change!
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

On Sun, 6 May 2007 15:19:53 -0400
Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> On Sunday 06 May 2007 3:02:38 pm Ciaran McCreesh wrote:
> > On Sun, 6 May 2007 14:53:22 -0400
> > Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > > > One of the reasons GLEP 42 was necessary was because users
> > > > *don't* read things delivered by other methods.
> > >
> > > And they are magically going to read the news?
> 
> Experience being two news items about one package.  Expand this to a
> tree size, where the user has around 400-500 packages.  If they get
> news about changes that will increase their experience for each one
> of these, they are looking at reading the New York Times of gentoo
> every day.   It's not going to happen.

And, if that happens (which it won't), we'll have more experience and
we can evaluate future news items based upon that. A more realistic
view for your typical user is less than a news item per week.

> > Paludis users do not consider that news item trivial.
> 
> If I was a paludis user I would considder this trivial.  The same
> information is availible a) from the package itself. b) from the
> changelog, and c) it still works without the change!

But you aren't, and those who are disagree.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Dan Meltzer]

On Sunday 06 May 2007 3:28:41 pm Ciaran McCreesh wrote:
> On Sun, 6 May 2007 15:19:53 -0400
>
> Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > On Sunday 06 May 2007 3:02:38 pm Ciaran McCreesh wrote:
> > > On Sun, 6 May 2007 14:53:22 -0400
> > >
> > > Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > > > > One of the reasons GLEP 42 was necessary was because users
> > > > > *don't* read things delivered by other methods.
> > > >
> > > > And they are magically going to read the news?
> >
> > Experience being two news items about one package.  Expand this to a
> > tree size, where the user has around 400-500 packages.  If they get
> > news about changes that will increase their experience for each one
> > of these, they are looking at reading the New York Times of gentoo
> > every day.   It's not going to happen.
>
> And, if that happens (which it won't), we'll have more experience and
> we can evaluate future news items based upon that. A more realistic
> view for your typical user is less than a news item per week.

And what are you basing this on?
>
> > > Paludis users do not consider that news item trivial.
> >
> > If I was a paludis user I would considder this trivial.  The same
> > information is availible a) from the package itself. b) from the
> > changelog, and c) it still works without the change!
>
> But you aren't, and those who are disagree.

I've yet to here from the "those who are" otherwise yet.

Would the thoses who are be the same ones that you called idiots for writing 
horrible hooks that broke their system? or would this be a different group of 
those who ares?  
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

On Sun, 6 May 2007 15:37:05 -0400
Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > And, if that happens (which it won't), we'll have more experience
> > and we can evaluate future news items based upon that. A more
> > realistic view for your typical user is less than a news item per
> > week.
> 
> And what are you basing this on?

Knowledge of the tree, and several years experience using it and
observing how often things change that would require news items. This
was part of the original GLEP 42 design.

> > > > Paludis users do not consider that news item trivial.
> > >
> > > If I was a paludis user I would considder this trivial.  The same
> > > information is availible a) from the package itself. b) from the
> > > changelog, and c) it still works without the change!
> >
> > But you aren't, and those who are disagree.
> 
> I've yet to here from the "those who are" otherwise yet.

Then you haven't actually bothered to read the threads, nor listen for
feedback anywhere else where Paludis users talk to Paludis developers.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Neil Walker]

Ciaran McCreesh wrote:
> Paludis users do not consider that news item trivial.
>
>   
The reason I, and many others I know, are EX-users of Paludis, is the 
arrogance of the Paludis team in assuming they know what Paludis (and 
Gentoo) users actually want.


Be lucky,

Neil



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[expose]

Am Sonntag 06 Mai 2007 20:21 schrieb Ciaran McCreesh:
> On Sun, 6 May 2007 14:17:29 -0400
>
> Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > > > which elog could easily be extended to do.
> > >
> > > But which elog does not do by default, and for good reason.
> >
> > and what good reason would that be?
>
> That elog is designed for post-install messages that aren't necessarily
> relevant to many users.

Ciaran, if you where a bit more verbose you could save time.
Instead of saying
> But which elog does not do by default, and for good reason.
you could have said
> That elog is designed for post-install messages that aren't necessarily
> relevant to many users.
immediately.

Things like this happened at least a few times in the recent discussion.
I, for instance, still wait for an answer to the question "How?"
concerning you "answer"
> The 'eselect news' module that ships with Paludis solves that problem.
which I'd still like to hear.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

On Sun, 6 May 2007 20:41:24 +0200
expose@luftgetrock.net wrote:
> Ciaran, if you where a bit more verbose you could save time.

If people read the rest of the thread and the GLEP we'd all save a lot
more, and if people also tried out a reference implementation then none
of these threads would need more than about three posts...

> Things like this happened at least a few times in the recent
> discussion. I, for instance, still wait for an answer to the question
> "How?" concerning you "answer"
>
> > The 'eselect news' module that ships with Paludis solves that
> > problem.
>
> which I'd still like to hear.

Perhaps you should... you know... try it. Then you'd be able to provide
much more useful input to the discussion.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Dan Meltzer]

On Sunday 06 May 2007 2:47:22 pm Ciaran McCreesh wrote:
> On Sun, 6 May 2007 20:41:24 +0200
>
> expose@luftgetrock.net wrote:
> > Ciaran, if you where a bit more verbose you could save time.
>
> If people read the rest of the thread and the GLEP we'd all save a lot
> more, and if people also tried out a reference implementation then none
> of these threads would need more than about three posts...

You say this, but every time someone quotes a relevant refuting part of the 
GLEP, you ignore it.  

Try this one:

"News items must only be for important changes that may cause serious upgrade 
or compatibility problems. Ordinary upgrade messages and non-critical news 
items should remain in einfo notices. The importance of the message to its 
intended audience should be justified with the proposal."

Now, the news item in this thread seems relevant to that.  WIthout doing what 
it says one will have a fairly major headache on their hands after upgrading.

The other example news item does not fit these criteria, there will be no 
major headache, there will be a warning that can be quickly fixed.
>
> > Things like this happened at least a few times in the recent
> > discussion. I, for instance, still wait for an answer to the question
> > "How?" concerning you "answer"
> >
> > > The 'eselect news' module that ships with Paludis solves that
> > > problem.
> >
> > which I'd still like to hear.
>
> Perhaps you should... you know... try it. Then you'd be able to provide
> much more useful input to the discussion.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

On Sun, 6 May 2007 15:26:06 -0400
Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> On Sunday 06 May 2007 2:47:22 pm Ciaran McCreesh wrote:
> > On Sun, 6 May 2007 20:41:24 +0200
> >
> > expose@luftgetrock.net wrote:
> > > Ciaran, if you where a bit more verbose you could save time.
> >
> > If people read the rest of the thread and the GLEP we'd all save a
> > lot more, and if people also tried out a reference implementation
> > then none of these threads would need more than about three posts...
> 
> You say this, but every time someone quotes a relevant refuting part
> of the GLEP, you ignore it.  
> 
> Try this one:

Read the rest of the threads. I've already answered that several times.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Dan Meltzer]

On Sunday 06 May 2007 3:31:32 pm Ciaran McCreesh wrote:
> On Sun, 6 May 2007 15:26:06 -0400
>
> Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > On Sunday 06 May 2007 2:47:22 pm Ciaran McCreesh wrote:
> > > On Sun, 6 May 2007 20:41:24 +0200
> > >
> > > expose@luftgetrock.net wrote:
> > > > Ciaran, if you where a bit more verbose you could save time.
> > >
> > > If people read the rest of the thread and the GLEP we'd all save a
> > > lot more, and if people also tried out a reference implementation
> > > then none of these threads would need more than about three posts...
> >
> > You say this, but every time someone quotes a relevant refuting part
> > of the GLEP, you ignore it.
> >
> > Try this one:
>
> Read the rest of the threads. I've already answered that several times.

No, I've read the other threads.  You've not explained how this is a critical 
update that requires a news item.  You've said repeatedly in response to 
related questions that your experience with news for one package in one 
overlay used by a small subset of users that uses said package recieved good 
feedback, and that they would like to be informed of changes in the future.  
You were informed that elog can do just that, and you said repeatedly that 
elog is not sufficient because its not loggged by default.   You could easily 
make elog logged by default in paludis, and that would achieve the same 
result as a news item.  What did I forget?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

On Sun, 6 May 2007 15:43:45 -0400
Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> No, I've read the other threads.  You've not explained how this is a
> critical update that requires a news item.  You've said repeatedly in
> response to related questions that your experience with news for one
> package in one overlay used by a small subset of users that uses said
> package recieved good feedback, and that they would like to be
> informed of changes in the future. You were informed that elog can do
> just that, and you said repeatedly that elog is not sufficient
> because its not loggged by default.   You could easily make elog
> logged by default in paludis, and that would achieve the same result
> as a news item.  What did I forget?

Er, making elog logged by default would not solve the "requires an
explicit read" problem. Making elog require an explicit read would
be far too annoying because most elog notices are noise. We've been
over this already.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Dan Meltzer]

On Sunday 06 May 2007 3:53:47 pm Ciaran McCreesh wrote:
> On Sun, 6 May 2007 15:43:45 -0400
>
> Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > No, I've read the other threads.  You've not explained how this is a
> > critical update that requires a news item.  You've said repeatedly in
> > response to related questions that your experience with news for one
> > package in one overlay used by a small subset of users that uses said
> > package recieved good feedback, and that they would like to be
> > informed of changes in the future. You were informed that elog can do
> > just that, and you said repeatedly that elog is not sufficient
> > because its not loggged by default.   You could easily make elog
> > logged by default in paludis, and that would achieve the same result
> > as a news item.  What did I forget?
>
> Er, making elog logged by default would not solve the "requires an
> explicit read" problem. Making elog require an explicit read would
> be far too annoying because most elog notices are noise. We've been
> over this already.

Not if one filters it properly.  ELOG_CLASSES="warn error" sounds like a sane 
default to me.  
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

On Sun, 6 May 2007 16:00:56 -0400
Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > Er, making elog logged by default would not solve the "requires an
> > explicit read" problem. Making elog require an explicit read would
> > be far too annoying because most elog notices are noise. We've been
> > over this already.
> 
> Not if one filters it properly.  ELOG_CLASSES="warn error" sounds
> like a sane default to me.  

So you want users to have to explicitly acknowledge all ewarn notices?
Now *that*'s a way of making the system useless by overusing it.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Dan Meltzer]

On Sunday 06 May 2007 4:06:18 pm Ciaran McCreesh wrote:
> On Sun, 6 May 2007 16:00:56 -0400
>
> Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > > Er, making elog logged by default would not solve the "requires an
> > > explicit read" problem. Making elog require an explicit read would
> > > be far too annoying because most elog notices are noise. We've been
> > > over this already.
> >
> > Not if one filters it properly.  ELOG_CLASSES="warn error" sounds
> > like a sane default to me.
>
> So you want users to have to explicitly acknowledge all ewarn notices?
> Now *that*'s a way of making the system useless by overusing it.

Err, warn notices are supposed to be important warnings.  If they are not it 
sounds like a good job for QA.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

On Sun, 6 May 2007 16:13:56 -0400
Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > So you want users to have to explicitly acknowledge all ewarn
> > notices? Now *that*'s a way of making the system useless by
> > overusing it.
> 
> Err, warn notices are supposed to be important warnings.  If they are
> not it sounds like a good job for QA.

That's a completely different degree of importance.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Dan Meltzer]

On Sunday 06 May 2007 4:22:44 pm Ciaran McCreesh wrote:
> On Sun, 6 May 2007 16:13:56 -0400
>
> Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > > So you want users to have to explicitly acknowledge all ewarn
> > > notices? Now *that*'s a way of making the system useless by
> > > overusing it.
> >
> > Err, warn notices are supposed to be important warnings.  If they are
> > not it sounds like a good job for QA.
>
> That's a completely different degree of importance.

Sounds like its the right degree of importants for deprecated things upstream 
to me.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ferris McCormick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 1410 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 6 May 2007 16:29:22 -0400
Dan Meltzer <hydrogen@notyetimplemented.com> wrote:

> On Sunday 06 May 2007 4:22:44 pm Ciaran McCreesh wrote:
> > On Sun, 6 May 2007 16:13:56 -0400
> >
> > Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > > > So you want users to have to explicitly acknowledge all ewarn
> > > > notices? Now *that*'s a way of making the system useless by
> > > > overusing it.
> > >
> > > Err, warn notices are supposed to be important warnings.  If they are
> > > not it sounds like a good job for QA.
> >
> > That's a completely different degree of importance.
> 
> Sounds like its the right degree of importants for deprecated things upstream 
> to me.

Dan, Ciaran,
   Perhaps I'll come across as a spoil sport here, but is there any
chance you could take your conversation to IRC (or to whatever)?  It
would go faster, and if you can reach some common level of agreement,
then you can usefully post that to this list.

> -- 
> gentoo-dev@gentoo.org mailing list
> 

Regards.
- -- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6-ecc01.6 (GNU/Linux)

iD8DBQFGPkM9Qa6M3+I///cRAi1mAKCjjlYDckKoENeGFLjLkaWwH1ynFQCgkOq/
+WdqXmqhJpbiuFFgEJQeSyI=
=zykl
-----END PGP SIGNATURE-----
éí¢‡^¾\a§¶Š(®	šŠX§‚X¬

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

Ciaran McCreesh napsal(a):
> On Sun, 6 May 2007 16:00:56 -0400
> Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
>>> Er, making elog logged by default would not solve the "requires an
>>> explicit read" problem. Making elog require an explicit read would
>>> be far too annoying because most elog notices are noise. We've been
>>> over this already.
>> Not if one filters it properly.  ELOG_CLASSES="warn error" sounds
>> like a sane default to me.  
> 
> So you want users to have to explicitly acknowledge all ewarn notices?
> Now *that*'s a way of making the system useless by overusing it.

Why would you acknowledge them? They are a different feature (plus,
seriously no mail gets automagically marked as read, if you use the mail
elog feature e.g. Maybe you should actually try to use the stuff before
recycling your 'our experience shows' and 'elog sucks' scratched record
once again.)

Plus, why's this thread been hijacked again for the paludis upgrade
stuff that doesn't need any news at all and that's been committed in
breach of GLEP42 itself?!

- paludis already loudly warns about the deprecated syntax whenever used;
- drop this "users like it" and "experience has shown" stuff. Experience
based on 4 news items is no experience at all; experience based on
one-package overlay is irrelevant wrt a repository with thousands of
ebuilds; and "users like it" may be nice for one package overlay, and a
genuine PITA for a tree with thousands of ebuilds at the same time.
Repeating it doesn't go anywhere, nor will it make any of your point
more valid.


Thanks.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]

On Sun, 06 May 2007 22:33:55 +0200
Jakub Moc <jakub@gentoo.org> wrote:
> Ciaran McCreesh napsal(a):
> > On Sun, 6 May 2007 16:00:56 -0400
> > Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> >>> Er, making elog logged by default would not solve the "requires an
> >>> explicit read" problem. Making elog require an explicit read would
> >>> be far too annoying because most elog notices are noise. We've
> >>> been over this already.
> >> Not if one filters it properly.  ELOG_CLASSES="warn error" sounds
> >> like a sane default to me.  
> > 
> > So you want users to have to explicitly acknowledge all ewarn
> > notices? Now *that*'s a way of making the system useless by
> > overusing it.
> 
> Why would you acknowledge them? They are a different feature (plus,
> seriously no mail gets automagically marked as read, if you use the
> mail elog feature e.g. Maybe you should actually try to use the stuff
> before recycling your 'our experience shows' and 'elog sucks'
> scratched record once again.)

Maybe you should reread the context I've quoted. Dan is proposing
making elog require explicit acknowledgements.

> Plus, why's this thread been hijacked again for the paludis upgrade
> stuff that doesn't need any news at all and that's been committed in
> breach of GLEP42 itself?!

Because some people won't stop looking for any available excuse to rant
about anything that has or can be made to have 'paludis' in it, and
they don't bother to read the rest of the discussion before they do so.

> - drop this "users like it" and "experience has shown" stuff.
> Experience based on 4 news items is no experience at all; experience
> based on one-package overlay is irrelevant wrt a repository with
> thousands of ebuilds; and "users like it" may be nice for one package
> overlay, and a genuine PITA for a tree with thousands of ebuilds at
> the same time. Repeating it doesn't go anywhere, nor will it make any
> of your point more valid.

And yet it's infinitely more experience than anyone else has at this
point. When there's a better collection of data available we'll use
that instead.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[expose]

Am Sonntag 06 Mai 2007 22:38 schrieb Ciaran McCreesh:
> On Sun, 06 May 2007 22:33:55 +0200
>
> Jakub Moc <jakub@gentoo.org> wrote:
> > Ciaran McCreesh napsal(a):
> > > On Sun, 6 May 2007 16:00:56 -0400
> > >
> > > Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > >>> Er, making elog logged by default would not solve the "requires an
> > >>> explicit read" problem. Making elog require an explicit read would
> > >>> be far too annoying because most elog notices are noise. We've
> > >>> been over this already.
> > >>
> > >> Not if one filters it properly.  ELOG_CLASSES="warn error" sounds
> > >> like a sane default to me.
> > >
> > > So you want users to have to explicitly acknowledge all ewarn
> > > notices? Now *that*'s a way of making the system useless by
> > > overusing it.
> >
> > Why would you acknowledge them? They are a different feature (plus,
> > seriously no mail gets automagically marked as read, if you use the
> > mail elog feature e.g. Maybe you should actually try to use the stuff
> > before recycling your 'our experience shows' and 'elog sucks'
> > scratched record once again.)
>
> Maybe you should reread the context I've quoted. Dan is proposing
> making elog require explicit acknowledgements.
>
> > Plus, why's this thread been hijacked again for the paludis upgrade
> > stuff that doesn't need any news at all and that's been committed in
> > breach of GLEP42 itself?!
>
> Because some people won't stop looking for any available excuse to rant
> about anything that has or can be made to have 'paludis' in it, and
> they don't bother to read the rest of the discussion before they do so.
Talking about yourself again?

> > - drop this "users like it" and "experience has shown" stuff.
> > Experience based on 4 news items is no experience at all; experience
> > based on one-package overlay is irrelevant wrt a repository with
> > thousands of ebuilds; and "users like it" may be nice for one package
> > overlay, and a genuine PITA for a tree with thousands of ebuilds at
> > the same time. Repeating it doesn't go anywhere, nor will it make any
> > of your point more valid.
>
> And yet it's infinitely more experience than anyone else has at this
> point. When there's a better collection of data available we'll use
> that instead.

It might be infinitely more, yet it still isnt worth anything for the reasons 
already explained which you, I guess, have accidently overlooked again.
I bet your users wont like reading zillions of - for gods sake - very very 
trivial news items for each and every package that hits the tree or they 
upgrade or what so ever else.
And if your expierence shows they will do like this, just write all the news 
items, and put them up your own repository, at let your happy users read them 
from there.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

On Sun, 6 May 2007 22:50:40 +0200
expose@luftgetrock.net wrote:
> It might be infinitely more, yet it still isnt worth anything for the
> reasons already explained which you, I guess, have accidently
> overlooked again. I bet your users wont like reading zillions of -
> for gods sake - very very trivial news items for each and every
> package that hits the tree or they upgrade or what so ever else.

And they won't get zillions. Read the thread.

> And if your expierence shows they will do like this, just write all
> the news items, and put them up your own repository, at let your
> happy users read them from there.

Also already been covered. Read the thread.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

Ciaran McCreesh napsal(a):
> On Sun, 6 May 2007 22:50:40 +0200
> expose@luftgetrock.net wrote:
>> It might be infinitely more, yet it still isnt worth anything for the
>> reasons already explained which you, I guess, have accidently
>> overlooked again. I bet your users wont like reading zillions of -
>> for gods sake - very very trivial news items for each and every
>> package that hits the tree or they upgrade or what so ever else.
> 
> And they won't get zillions. Read the thread.

Sure they will gets zillions of them if everyone starts abusing this
feature the same way as you suggest. Imagine an average install w/ ~700
packages notifying users about config file changes and similar stuff.

>> And if your expierence shows they will do like this, just write all
>> the news items, and put them up your own repository, at let your
>> happy users read them from there.
> 
> Also already been covered. Read the thread.

Haven't noticed either, maybe you could point us to where has this been
covered?


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Dan Meltzer]

On Sunday 06 May 2007 4:38:16 pm Ciaran McCreesh wrote:
> On Sun, 06 May 2007 22:33:55 +0200
>
> Jakub Moc <jakub@gentoo.org> wrote:
> > Ciaran McCreesh napsal(a):
> > > On Sun, 6 May 2007 16:00:56 -0400
> > >
> > > Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > >>> Er, making elog logged by default would not solve the "requires an
> > >>> explicit read" problem. Making elog require an explicit read would
> > >>> be far too annoying because most elog notices are noise. We've
> > >>> been over this already.
> > >>
> > >> Not if one filters it properly.  ELOG_CLASSES="warn error" sounds
> > >> like a sane default to me.
> > >
> > > So you want users to have to explicitly acknowledge all ewarn
> > > notices? Now *that*'s a way of making the system useless by
> > > overusing it.
> >
> > Why would you acknowledge them? They are a different feature (plus,
> > seriously no mail gets automagically marked as read, if you use the
> > mail elog feature e.g. Maybe you should actually try to use the stuff
> > before recycling your 'our experience shows' and 'elog sucks'
> > scratched record once again.)
>
> Maybe you should reread the context I've quoted. Dan is proposing
> making elog require explicit acknowledgements.

Thats news to me.  I was proposing using elog where it was logical, you were 
the one who appended the "explicitly aknowledged" to it.
>
> > Plus, why's this thread been hijacked again for the paludis upgrade
> > stuff that doesn't need any news at all and that's been committed in
> > breach of GLEP42 itself?!
>
> Because some people won't stop looking for any available excuse to rant
> about anything that has or can be made to have 'paludis' in it, and
> they don't bother to read the rest of the discussion before they do so.
>
> > - drop this "users like it" and "experience has shown" stuff.
> > Experience based on 4 news items is no experience at all; experience
> > based on one-package overlay is irrelevant wrt a repository with
> > thousands of ebuilds; and "users like it" may be nice for one package
> > overlay, and a genuine PITA for a tree with thousands of ebuilds at
> > the same time. Repeating it doesn't go anywhere, nor will it make any
> > of your point more valid.
>
> And yet it's infinitely more experience than anyone else has at this
> point. When there's a better collection of data available we'll use
> that instead.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

On Sun, May 06, 2007 at 07:21:02PM +0100, Ciaran McCreesh wrote:
> On Sun, 6 May 2007 14:17:29 -0400
> Dan Meltzer <hydrogen@notyetimplemented.com> wrote:
> > > > which elog could easily be extended to do.
> > >
> > > But which elog does not do by default, and for good reason.
> > 
> > and what good reason would that be?
> 
> That elog is designed for post-install messages that aren't necessarily
> relevant to many users.

Elog is a general mechanism; einfo/ewarn/enotice (etc) are designed to 
seperate what's "relevant to users"- so you'll need a better reason :)

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Hans de Graaff]

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

On Sun, 2007-05-06 at 16:51 +0100, Ciaran McCreesh wrote:

> > Will the news item be shown before or after the package gets merged?
> 
> After. For before, use Display-If-Installed: on a lower version.

Ok, so this is more like elog stuff. One benefit I can see with this
version is that it makes it easier to version the messages. Some ebuilds
currently in the tree have many messages, all tied to different upgrade
paths and it's hard to make out which ones are relevant. This can be
solved with elog by more carefully wording the messages and always
include version numbers, but even then the user has to parse things.

And you were right, this is not what I'm after.

> > I'm afraid that this is not correct, because the semantics of
> > Display-If-Installed don't match the use case I described.
> > Specifically, it will cause the news item to be shown way to early
> > for users on a stable profile.
> 
> Thus giving them lots of notice, which is one of the things the GLEP
> was designed to do.
> 

I'm afraid that many users will have forgotten by the time the upgrade
is actually possible for them, especially when this period is longer
than a month. It feels a bit like crying wolf to me: "here's a bunch of
changes you'll need to deal with at some point on the future, but you
can't have them now and we don't know when they'll be ready, and if they
are ready we won't warn you again"

To me it seems to make more sense to show the message when the upgrade
it actually available. Then the user can decide if this is the right
time to tackle the issue and get at it right away, or wait until a later
time.

Kind regards,

Hans

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

On Sun, 06 May 2007 18:27:09 +0200
Hans de Graaff <graaff@gentoo.org> wrote:
> I'm afraid that many users will have forgotten by the time the upgrade
> is actually possible for them, especially when this period is longer
> than a month. It feels a bit like crying wolf to me: "here's a bunch
> of changes you'll need to deal with at some point on the future, but
> you can't have them now and we don't know when they'll be ready, and
> if they are ready we won't warn you again"

It's not like the news item disappears completely after you read it.

> To me it seems to make more sense to show the message when the upgrade
> it actually available.

Then you're looking for a different feature. Probably the one that's
designed to do configuration checks after --pretend... pkg_pretend_post
or whatever it was going to be called.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade

[expose]

I think we can see different aspects here:
0) Being able to display items for packages which might become available to 
the stable branch after unknown time. (available yet)

1) Being able to show items right before merging, the one last "last 
minute" "warning", that is "Display-Before-Upgrade-From-To"

2) Being able to show items when the pkg becomes available, that 
is "Display-If-Visible" or "Display-If-Unmasked"

3) Combinations of the above.
-- 
gentoo-dev@gentoo.org mailing list