Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
Ciaran McCreesh napsal(a): > On Sun, 6 May 2007 22:50:40 +0200 > [EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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 ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 6 May 2007 16:29:22 -0400 Dan Meltzer <[EMAIL PROTECTED]> wrote: > On Sunday 06 May 2007 4:22:44 pm Ciaran McCreesh wrote: > > On Sun, 6 May 2007 16:13:56 -0400 > > > > Dan Meltzer <[EMAIL PROTECTED]> 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. > -- > [EMAIL PROTECTED] mailing list > Regards. - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> 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- éí¢^¾§¶(® X§X¬
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 22:50:40 +0200 [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sunday 06 May 2007 4:38:16 pm Ciaran McCreesh wrote: > On Sun, 06 May 2007 22:33:55 +0200 > > Jakub Moc <[EMAIL PROTECTED]> wrote: > > Ciaran McCreesh napsal(a): > > > On Sun, 6 May 2007 16:00:56 -0400 > > > > > > Dan Meltzer <[EMAIL PROTECTED]> 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. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
Am Sonntag 06 Mai 2007 22:38 schrieb Ciaran McCreesh: > On Sun, 06 May 2007 22:33:55 +0200 > > Jakub Moc <[EMAIL PROTECTED]> wrote: > > Ciaran McCreesh napsal(a): > > > On Sun, 6 May 2007 16:00:56 -0400 > > > > > > Dan Meltzer <[EMAIL PROTECTED]> 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. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 06 May 2007 22:33:55 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh napsal(a): > > On Sun, 6 May 2007 16:00:56 -0400 > > Dan Meltzer <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
Ciaran McCreesh napsal(a): > On Sun, 6 May 2007 16:00:56 -0400 > Dan Meltzer <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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 ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sunday 06 May 2007 4:22:44 pm Ciaran McCreesh wrote: > On Sun, 6 May 2007 16:13:56 -0400 > > Dan Meltzer <[EMAIL PROTECTED]> 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. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 16:13:56 -0400 Dan Meltzer <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sunday 06 May 2007 4:06:18 pm Ciaran McCreesh wrote: > On Sun, 6 May 2007 16:00:56 -0400 > > Dan Meltzer <[EMAIL PROTECTED]> 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. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 16:00:56 -0400 Dan Meltzer <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sunday 06 May 2007 3:53:47 pm Ciaran McCreesh wrote: > On Sun, 6 May 2007 15:43:45 -0400 > > Dan Meltzer <[EMAIL PROTECTED]> 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. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 15:43:45 -0400 Dan Meltzer <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 06 May 2007 21:43:23 +0200 Vlastimil Babka <[EMAIL PROTECTED]> 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 (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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 15:37:05 -0400 Dan Meltzer <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sunday 06 May 2007 3:31:32 pm Ciaran McCreesh wrote: > On Sun, 6 May 2007 15:26:06 -0400 > > Dan Meltzer <[EMAIL PROTECTED]> wrote: > > On Sunday 06 May 2007 2:47:22 pm Ciaran McCreesh wrote: > > > On Sun, 6 May 2007 20:41:24 +0200 > > > > > > [EMAIL PROTECTED] 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? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
-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 (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- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sunday 06 May 2007 3:28:41 pm Ciaran McCreesh wrote: > On Sun, 6 May 2007 15:19:53 -0400 > > Dan Meltzer <[EMAIL PROTECTED]> wrote: > > On Sunday 06 May 2007 3:02:38 pm Ciaran McCreesh wrote: > > > On Sun, 6 May 2007 14:53:22 -0400 > > > > > > Dan Meltzer <[EMAIL PROTECTED]> 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? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 15:26:06 -0400 Dan Meltzer <[EMAIL PROTECTED]> wrote: > On Sunday 06 May 2007 2:47:22 pm Ciaran McCreesh wrote: > > On Sun, 6 May 2007 20:41:24 +0200 > > > > [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 15:19:53 -0400 Dan Meltzer <[EMAIL PROTECTED]> wrote: > On Sunday 06 May 2007 3:02:38 pm Ciaran McCreesh wrote: > > On Sun, 6 May 2007 14:53:22 -0400 > > Dan Meltzer <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sunday 06 May 2007 2:47:22 pm Ciaran McCreesh wrote: > On Sun, 6 May 2007 20:41:24 +0200 > > [EMAIL PROTECTED] 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. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sunday 06 May 2007 3:02:38 pm Ciaran McCreesh wrote: > On Sun, 6 May 2007 14:53:22 -0400 > > Dan Meltzer <[EMAIL PROTECTED]> 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! -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 14:53:22 -0400 Dan Meltzer <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 06 May 2007 20:43:08 +0200 Hans de Graaff <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sunday 06 May 2007 2:42:23 pm Ciaran McCreesh wrote: > On Sun, 6 May 2007 14:39:13 -0400 > > Dan Meltzer <[EMAIL PROTECTED]> 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. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 20:41:24 +0200 [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 14:39:13 -0400 Dan Meltzer <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, May 06, 2007 at 07:21:02PM +0100, Ciaran McCreesh wrote: > On Sun, 6 May 2007 14:17:29 -0400 > Dan Meltzer <[EMAIL PROTECTED]> 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 pgp8vRcTSlE9n.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
Am Sonntag 06 Mai 2007 20:21 schrieb Ciaran McCreesh: > On Sun, 6 May 2007 14:17:29 -0400 > > Dan Meltzer <[EMAIL PROTECTED]> 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. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sunday 06 May 2007 2:21:02 pm Ciaran McCreesh wrote: > On Sun, 6 May 2007 14:17:29 -0400 > > Dan Meltzer <[EMAIL PROTECTED]> 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? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 14:17:29 -0400 Dan Meltzer <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sunday 06 May 2007 2:11:14 pm Ciaran McCreesh wrote:
> On Sun, 6 May 2007 14:08:01 -0400
>
> Dan Meltzer <[EMAIL PROTECTED]> wrote:
> > On Sunday 06 May 2007 1:58:57 pm Ciaran McCreesh wrote:
> > > On Sun, 06 May 2007 10:38:14 -0700
> > >
> > > Mike Doty <[EMAIL PROTECTED]> 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?
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 14:08:01 -0400
Dan Meltzer <[EMAIL PROTECTED]> wrote:
> On Sunday 06 May 2007 1:58:57 pm Ciaran McCreesh wrote:
> > On Sun, 06 May 2007 10:38:14 -0700
> >
> > Mike Doty <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sunday 06 May 2007 1:58:57 pm Ciaran McCreesh wrote:
> On Sun, 06 May 2007 10:38:14 -0700
>
> Mike Doty <[EMAIL PROTECTED]> 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.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 06 May 2007 10:38:14 -0700
Mike Doty <[EMAIL PROTECTED]> wrote:
> how is that different than using e{info,warn,error}?
It stays visible until the user explicitly acknowledges reading it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
Ciaran McCreesh wrote: On Sun, 6 May 2007 19:24:11 +0200 > [EMAIL PROTECTED] 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" -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 19:16:11 +0200 Marius Mauch <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Sun, 6 May 2007 19:24:11 +0200
> [EMAIL PROTECTED] 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-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
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. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 17:27:39 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sun, 6 May 2007 18:20:31 +0200 > [EMAIL PROTECTED] 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. signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 19:24:11 +0200 [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 18:42:58 +0200 Marius Mauch <[EMAIL PROTECTED]> wrote: > On Sun, 6 May 2007 18:20:31 +0200 > [EMAIL PROTECTED] 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. signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
Am Sonntag 06 Mai 2007 18:42 schrieb Marius Mauch: > [EMAIL PROTECTED] 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". -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 18:20:31 +0200 [EMAIL PROTECTED] 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. signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 06 May 2007 18:27:09 +0200 Hans de Graaff <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 6 May 2007 18:20:31 +0200 [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
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." -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 06 May 2007 17:49:24 +0200 Hans de Graaff <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 2007-05-06 at 16:33 +0100, Ciaran McCreesh wrote: > On Sun, 06 May 2007 08:45:36 +0200 > Hans de Graaff <[EMAIL PROTECTED]> 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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
On Sun, 06 May 2007 08:45:36 +0200 Hans de Graaff <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
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 [EMAIL PROTECTED] http://www.gentoo.org Creator of BiteMe! [EMAIL PROTECTED] http://www.kfk4ever.com pgpQWP2lEnD3H.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
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 <[EMAIL PROTECTED]> > 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/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
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 signature.asc Description: OpenPGP digital signature
[gentoo-dev] GLEP 42 news item for review: Radiant upgrade
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 <[EMAIL PROTECTED]> 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/ signature.asc Description: This is a digitally signed message part
