Re: [gentoo-dev] glep-42-news: sparc multilib profile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty schrieb: > s/mutlilib/multilib/ Thanks, fixed. > I also don't understand why this news item needed to wait for a Portage > to go stable. It didn't need to wait for portage but portage just happened to go stable about the same time the profile was added to the tree :) Cheers, Friedrich -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklmhE8ACgkQknxn9PmJ76V+mgCeN9yAcc3rCZ6zvApX4DrLQg0a DN4Anj9iDK5lhlRDCk+lp5fRQCalP7t1 =9Pla -END PGP SIGNATURE-
Re: [gentoo-dev] glep-42-news: sparc multilib profile
Friedrich Oslage wrote: > Josh Saddler schrieb: >> Mmm, not so much. Documentation like this, that's so specific to one >> particular architecture, would be better off in project documentation -- >> that's (partly) why ya'll have project directories in the first place. >> Otherwise it becomes a maintenance burden for the GDP. It'll be easier >> on the Sparc team to maintain it if it's in their own /proj/ space. > >> What we can do, however, is list it in metadoc.xml, so that it will show >> up in /doc/en/list.xml. > > > Right, x86 or ppc users won't benefit from reading it ;) > > I moved it to the sparc space and attached the revided news item. > > Regards, > Friedrich s/mutlilib/multilib/ I also don't understand why this news item needed to wait for a Portage to go stable. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] glep-42-news: sparc multilib profile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josh Saddler schrieb: > Mmm, not so much. Documentation like this, that's so specific to one > particular architecture, would be better off in project documentation -- > that's (partly) why ya'll have project directories in the first place. > Otherwise it becomes a maintenance burden for the GDP. It'll be easier > on the Sparc team to maintain it if it's in their own /proj/ space. > > What we can do, however, is list it in metadoc.xml, so that it will show > up in /doc/en/list.xml. > Right, x86 or ppc users won't benefit from reading it ;) I moved it to the sparc space and attached the revided news item. Regards, Friedrich -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklbkUYACgkQknxn9PmJ76X6UgCeNDiKufUBOJ+L7sQPv4nvBBGM vIwAnRTVmxQOutloBVG7XIf/FJo5aG+E =qYuu -END PGP SIGNATURE- Title: Migrating to the new sparc mutlilib profile Author: Friedrich Oslage Content-Type: text/plain Posted: 2008-12-30 Revision: 1 News-Item-Format: 1.0 Display-If-Profile: default/linux/sparc/experimental/multilib Display-If-Profile: default/linux/sparc/experimental/multilib/desktop Display-If-Profile: default/linux/sparc/experimental/multilib/developer Display-If-Profile: default/linux/sparc/experimental/multilib/server When migrating to the new sparc mutlilib profile please keep in mind that it is still in an experimental state. Also note that you need to follow the migration guide [0], otherwise important packages such as gcc or glibc will fail to compile and most other packages will be installed incorrectly. [0] http://sparc.gentoo.org/multilib.xml
Re: [gentoo-dev] glep-42-news: sparc multilib profile
Jeremy Olexa wrote: > On Tue, Dec 30, 2008 at 8:04 AM, Friedrich Oslage wrote: > >> [1] http://dev.gentoo.org/~bluebird/sparc-multilib/ > > I would put it in the gentoo.org/doc/en/ domain and link to it in the > gentoo-sparc index > (http://www.gentoo.org/proj/en/base/sparc/index.xml) > > 2 cents, > Jeremy > Mmm, not so much. Documentation like this, that's so specific to one particular architecture, would be better off in project documentation -- that's (partly) why ya'll have project directories in the first place. Otherwise it becomes a maintenance burden for the GDP. It'll be easier on the Sparc team to maintain it if it's in their own /proj/ space. What we can do, however, is list it in metadoc.xml, so that it will show up in /doc/en/list.xml. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] glep-42-news: sparc multilib profile
On Tue, Dec 30, 2008 at 8:04 AM, Friedrich Oslage wrote: > [1] http://dev.gentoo.org/~bluebird/sparc-multilib/ I would put it in the gentoo.org/doc/en/ domain and link to it in the gentoo-sparc index (http://www.gentoo.org/proj/en/base/sparc/index.xml) 2 cents, Jeremy
[gentoo-dev] glep-42-news: sparc multilib profile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since yesterday we finally have a stable version of app-admin/eselect-news in the tree [0], now it's time to get some news rollin' :) The 2008.0 sparc profile uses a pure 32 bit userland and a 64 bit kernel. A few days ago I added an experimental multilib profile which uses 32 bit as default but also supports -m64. Problem is you can't simply switch your make.profile symlink, that's why we have a migration guide [1] and the purpose of this news item would be to notify users who switched to that profile that they need to read and follow that guide. Besides causing gcc and glibc to fail compilation, not reading that guide would also make a users system end up with two different libdirs: lib and lib32 (All our non-multilib profile use lib as libdir and our multilib profiles use lib32/lib64 with lib as a symlink to one of them) I'll commit this in 72 hours unless someone objects. Regards, Friedrich [0] https://bugs.gentoo.org/show_bug.cgi?id=251810 [1] http://dev.gentoo.org/~bluebird/sparc-multilib/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklaKmMACgkQknxn9PmJ76Uk/QCfUrvvCaWo+qAXHXBA+DqxrkrB 04wAoJlOYZ5+K5xS+JjbALkcDYP93Ve3 =+aPC -END PGP SIGNATURE- Title: Migrating to the new sparc mutlilib profile Author: Friedrich Oslage Content-Type: text/plain Posted: 2008-12-30 Revision: 1 News-Item-Format: 1.0 Display-If-Profile: default/linux/sparc/experimental/multilib Display-If-Profile: default/linux/sparc/experimental/multilib/desktop Display-If-Profile: default/linux/sparc/experimental/multilib/developer Display-If-Profile: default/linux/sparc/experimental/multilib/server When migrating to the new sparc mutlilib profile please keep in mind that it is still in an experimental state. Also note that you need to follow the migration guide [0], otherwise important packages such as gcc or glibc will fail to compile and most other packages will be installed incorrectly. [0] http://dev.gentoo.org/~bluebird/sparc-multilib/ 2008-12-30-sparc-multilib.en.txt.sig Description: Binary data
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
Re: [gentoo-dev] GLEP 42 news items
Stephen Bennett wrote: > Anyone have a reason why we can't start to put them in the tree? > Portage support is, I'm told, coming in a month or so, and other > package managers have supported glep42 for a while now. The format is > well specified by the GLEP, so compatibility shouldn't be an issue. > > The one thing I can see needing to be decided first is an open question > in the glep: do we want to put the news items straight into gentoo-x86, > or a seperate repository that will be merged into the tree during the > cvs->rsync process? Uh, the glep says a separate repo, there is an svn news repo I had created months ago when portage support was merged into trunk. -Alec -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news items
On 02/05/07, Stephen Bennett <[EMAIL PROTECTED]> wrote: The one thing I can see needing to be decided first is an open question in the glep: do we want to put the news items straight into gentoo-x86, or a seperate repository that will be merged into the tree during the cvs->rsync process? From reading the glep it's always been my impression that the latter would be the case: "The contents of this repository will automatically be merged with the main rsync tree, placing the items in a metadata/news/ directory." -- -Charlie -- [EMAIL PROTECTED] mailing list
[gentoo-dev] GLEP 42 news items
Anyone have a reason why we can't start to put them in the tree? Portage support is, I'm told, coming in a month or so, and other package managers have supported glep42 for a while now. The format is well specified by the GLEP, so compatibility shouldn't be an issue. The one thing I can see needing to be decided first is an open question in the glep: do we want to put the news items straight into gentoo-x86, or a seperate repository that will be merged into the tree during the cvs->rsync process? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42?
Hi Zac, This is all good news. On 10/11/06, Zac Medico <[EMAIL PROTECTED]> wrote: 2) Default USE flags at the ebuild and/or profile level [2]. This one would be very very useful for Seeds, if we can set per-ebuild USE flags at the profile level. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
On Wed, 11 Oct 2006 15:30:03 -0400 Chris Gianelloni
<[EMAIL PROTECTED]> wrote:
| On Wed, 2006-10-11 at 19:44 +0100, Ciaran McCreesh wrote:
| > On Wed, 11 Oct 2006 13:36:16 -0500 Brian Jackson <[EMAIL PROTECTED]>
| > wrote:
| > | > ${CATEGORY}/${PN}:${SLOT}.
| > |
| > | I thought we were eventually going to use that format to specify
| > | deps with specific USE set.
| >
| > That's [use].
|
| I assume it is really [list of use] right?
I think cat/pkg:slot[foo][-bar][baz] or opcat/pkg-ver:slot[foo][-bar]
was what was decided upon. That's how paludis does it, but it's easy
enough to tweak if people prefer something else...
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13
signature.asc
Description: PGP signature
Re: [gentoo-dev] GLEP 42?
On Wed, 2006-10-11 at 19:44 +0100, Ciaran McCreesh wrote:
> On Wed, 11 Oct 2006 13:36:16 -0500 Brian Jackson <[EMAIL PROTECTED]>
> wrote:
> | > ${CATEGORY}/${PN}:${SLOT}.
> |
> | I thought we were eventually going to use that format to specify
> | deps with specific USE set.
>
> That's [use].
I assume it is really [list of use] right?
--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42?
On Wed, 11 Oct 2006 13:36:16 -0500 Brian Jackson <[EMAIL PROTECTED]>
wrote:
| > ${CATEGORY}/${PN}:${SLOT}.
|
| I thought we were eventually going to use that format to specify
| deps with specific USE set.
That's [use].
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13
signature.asc
Description: PGP signature
Re: [gentoo-dev] GLEP 42?
Am Mittwoch, 11. Oktober 2006 20:36 schrieb Brian Jackson:
> On Oct 11, 2006, at 12:37 PM, Zac Medico wrote:
encies.
> > * The world and system sets allow automatic update of all installed
> > slots.
> > * DEPEND atoms support SLOT dependencies of the form
> > ${CATEGORY}/${PN}:${SLOT}.
Yay!
> I thought we were eventually going to use that format to specify deps
> with specific USE set.
Nope, that was ${CATEGORY}/${PN}[foo].
Danny
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
> Zac Medico wrote:
>> * DEPEND atoms support SLOT dependencies of the form
>> ${CATEGORY}/${PN}:${SLOT}.
>
> No way, it happened!!
>
> So when can we start actually using this feature?
We can either wait until several months after the feature is
available in release media, or else do an EAPI bump (whichever comes
sooner). Ideally, an EAPI bump will include a number of major
changes. Other features that I think we should consider for an EAPI
bump are:
1) Grouping of package atom restrictions [1].
2) Default USE flags at the ebuild and/or profile level [2].
3) Ebuild helpers as functions that die automatically [3].
4) Elimination of the implicit RDEPEND "feature" [4].
The first EAPI bump should probably be proposed as a GLEP and should
include features that have been proposed/implemented as part of
other GLEPs.
Zac
[1] http://bugs.gentoo.org/show_bug.cgi?id=4315
[2] http://bugs.gentoo.org/show_bug.cgi?id=61732
[3] http://bugs.gentoo.org/show_bug.cgi?id=138792
[4] http://bugs.gentoo.org/show_bug.cgi?id=135945
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFLT11/ejvha5XGaMRAu/EAKCh5pX5yM7OHF7uHo8e6EzSV2QzRgCeJFyg
fe6FbBk+YGLajtn+puYG8H8=
=Mp3N
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
On Oct 11, 2006, at 12:37 PM, Zac Medico wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stuart Herbert wrote:
Whatever happened to the work to implement GLEP 42? Is there anyone
actively working on this atm?
It's been on my todo list, but I haven't gotten around to it yet due
to other portage work that's kept me extremely busy. I hope to get
GLEP 42 implemented soon though.
On the bright side, portage-2.1.2 [1] has made recent progress on
quite a few important and long standing bugs. Here are descriptions
of some of the recent changes:
* Profiles support multiple inheritance.
* CONFIG_PROTECT and CONFIG_PROTECT_MASK both support files (not
just directories).
* Collision protection handles symlinks properly.
* Dependencies can be satisfied by installed packages that do not
have matching ebuilds in the portage tree or overlay.
* Emerge automatically ignores blockers that are made irrelevant by
an upgrade.
* Emerge builds a complete dependency graph in order to ensure
correct merge order and detection of circular dependencies.
* The world and system sets allow automatic update of all installed
slots.
* DEPEND atoms support SLOT dependencies of the form
${CATEGORY}/${PN}:${SLOT}.
I thought we were eventually going to use that format to specify deps
with specific USE set.
--Iggy
Zac
[1] http://bugs.gentoo.org/show_bug.cgi?id=147007
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFLSvG/ejvha5XGaMRArOGAKDNpWrM6t6yOI2UWpzdSMNZI5aDCQCeOGGr
2WPgtPacSdHZFWPzib/H4v8=
=n+s3
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
Zac Medico wrote:
> * DEPEND atoms support SLOT dependencies of the form
> ${CATEGORY}/${PN}:${SLOT}.
No way, it happened!!
So when can we start actually using this feature?
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP 42?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stuart Herbert wrote:
> Whatever happened to the work to implement GLEP 42? Is there anyone
> actively working on this atm?
It's been on my todo list, but I haven't gotten around to it yet due
to other portage work that's kept me extremely busy. I hope to get
GLEP 42 implemented soon though.
On the bright side, portage-2.1.2 [1] has made recent progress on
quite a few important and long standing bugs. Here are descriptions
of some of the recent changes:
* Profiles support multiple inheritance.
* CONFIG_PROTECT and CONFIG_PROTECT_MASK both support files (not
just directories).
* Collision protection handles symlinks properly.
* Dependencies can be satisfied by installed packages that do not
have matching ebuilds in the portage tree or overlay.
* Emerge automatically ignores blockers that are made irrelevant by
an upgrade.
* Emerge builds a complete dependency graph in order to ensure
correct merge order and detection of circular dependencies.
* The world and system sets allow automatic update of all installed
slots.
* DEPEND atoms support SLOT dependencies of the form
${CATEGORY}/${PN}:${SLOT}.
Zac
[1] http://bugs.gentoo.org/show_bug.cgi?id=147007
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFLSvG/ejvha5XGaMRArOGAKDNpWrM6t6yOI2UWpzdSMNZI5aDCQCeOGGr
2WPgtPacSdHZFWPzib/H4v8=
=n+s3
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
On Wed, 11 Oct 2006 13:59:59 +0100 Stuart Herbert <[EMAIL PROTECTED]> wrote: | Whatever happened to the work to implement GLEP 42? Is there anyone | actively working on this atm? There's a full implementation in Paludis. I believe Christel was working on backporting it to the legacy package manager. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
[gentoo-dev] GLEP 42?
Hi, Whatever happened to the work to implement GLEP 42? Is there anyone actively working on this atm? Best regards, Stu -- -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://blog.stuartherbert.com/ GnuPG key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (News) revisited
On Mon, 12 Jun 2006 23:19:10 +0100 Stephen Bennett <[EMAIL PROTECTED]> wrote: > Since GLEP 42's original author and sponsor has left the project, I've > taken it over, and would like to have another go at getting it > implemented. OK, since noone has raised any significant issues with this, I'd like to ask the Council to discuss it at the next opportunity. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (News) revisited
On Mon, 12 Jun 2006 19:26:18 -0400 Alec Warner <[EMAIL PROTECTED]> wrote: > Stephen Bennett wrote: > > * Portage must provide a way for external programs to obtain a list > > of all repository identifiers for a given system. It is assumed > > that this will be in the form of a ``portageq`` command (e.g. > > ``portageq get_repo_ids``). > > > > not done, and if we implemented it, would be a hack (although > compromisable in this scheme, would be essentially a fake portageq > command) Incorrect, I've planned this as part of modular sync code (same requirement). > > * Portage must provide a way for external programs to obtain the > > base path for a repository with a given ID. It is assumed that this > > will be in the form of a ``portageq`` command (e.g. ``portageq > > get_repo_root gentoo-x86``). > > same as above see above > > * Portage must extend ``portageq has_version`` to support > > restrictions to a given repository ID. > > and again This is the tricky one. Needs vdb adjustments (or some really ugly hacks). > > * Portage must extend ``portageq`` to implement a command which > > returns whether or not the profile used for a given repository ID > > is exactly the given profile (e.g. ``portageq profile_used > > default-linux/sparc/sparc64/2004.3 gentoo-x86``). > > and again This is almost trivial. > I have no problem with basically writing up 'fake' portageq calls. > However often people tell me overlays are important, they don't serve > as multipile repos and don't have metadata/news, so they are excluded > in this specification (intentially?). Portage doesn't do multiple > repo's so any repo-related call will be a 'fake' one, that just > returns the expected data, unless someone has a better method (looks > at other portage devs). As stated above the modular sync code I've planned for 2.2 has similar requirements to this as it includes support for syncing overlays. Marius PS: Please in the future only quote relevant parts. -- 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) revisited
On Mon, 12 Jun 2006 19:26:18 -0400 Alec Warner <[EMAIL PROTECTED]> wrote: > > * Portage must provide a way for external programs to obtain a list > > of all repository identifiers for a given system. It is assumed > > that this will be in the form of a ``portageq`` command (e.g. > > ``portageq get_repo_ids``). > > > > not done, and if we implemented it, would be a hack (although > compromisable in this scheme, would be essentially a fake portageq > command)anrRokydtysyyetntgsI > > > * Portage must provide a way for external programs to obtain the > > base path for a repository with a given ID. It is assumed that this > > will be in the form of a ``portageq`` command (e.g. ``portageq > > get_repo_root gentoo-x86``). > > same as above > > > > > * Portage must extend ``portageq has_version`` to support > > restrictions to a given repository ID. > > and again > > > > > * Portage must extend ``portageq`` to implement a command which > > returns whether or not the profile used for a given repository ID > > is exactly the given profile (e.g. ``portageq profile_used > > default-linux/sparc/sparc64/2004.3 gentoo-x86``). > > and again > > > > > These extensions are assumed during the following specification. > > > > I have no problem with basically writing up 'fake' portageq calls. > However often people tell me overlays are important, they don't serve > as multipile repos and don't have metadata/news, so they are excluded > in this specification (intentially?). Portage doesn't do multiple > repo's so any repo-related call will be a 'fake' one, that just > returns the expected data, unless someone has a better method (looks > at other portage devs). I was assuming that given Portage's current lack of multiple repository support it would simply look to existing settings for all of these. The name can be grabbed from profiles/repo_name which already exists; the path can just return $PORTDIR if the name matches and error if not; the repository restrictions for has_version can simply be ignored, and the profile can check /etc/make.profile. > I am not sure if I pointed this out before, but I feel that news > items should be of a pragmatic nature. IE they should be useful but > not frequent. It should not be overly difficult to post a news item > for a particular incident. If news items are constantly being shot > down due to "importance" or some other reason that lacks what I would > call a reasonable blocking reason ( ie bad grammar, clarity problems, > inaccuracies ) it will discourage developers from submitting them. > While I am against completely crap news items, I would rather see > more news items than very few. While I don't like to appeal to common sense, given the ability to filter displaying of items based on profile, package installed, etc, it should be fairly easy to avoid flooding people with irrelevant news items without raising the bar so high that it discourages people. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (News) revisited
On Mon, 12 Jun 2006 19:26:18 -0400 Alec Warner <[EMAIL PROTECTED]> wrote: | I have no problem with basically writing up 'fake' portageq calls. | However often people tell me overlays are important, they don't serve | as multipile repos and don't have metadata/news, so they are excluded | in this specification (intentially?). Portage doesn't do multiple | repo's so any repo-related call will be a 'fake' one, that just | returns the expected data, unless someone has a better method (looks | at other portage devs). The reason all that stuff is there is because a certain former Portage developer refused to let the GLEP through unless it had it... You should take a look back at the dozens of emails he sent demanding its addition to see the rationale. | I would prefer to hear arguments about whether news items should be | posted to announce or to a seperate ML. I would also like to see | integration via a "news" link on p.g.o. I would be willing to assist | in the latter. Those kinds of things were beyond the scope of the GLEP, other than that the GLEP is specifically designed to make implementing them easy. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (News) revisited
Stephen Bennett wrote: Since GLEP 42's original author and sponsor has left the project, I've taken it over, and would like to have another go at getting it implemented. I've just updated the version in CVS[1], which should be making its way onto the www nodes, but with any luck the full text should be attached here for convenience. So, I'd like to ask for any further input on this, and if noone has any major issues with it, I'd like to put it into the Council's queue for discussion at the next opportunity. Changes since the previous posted version: * Added details of a reference implementation. GLEP: 42 Title: Critical News Reporting Version: $Revision: 1.10 $ Author: Ciaran McCreesh <[EMAIL PROTECTED]> Last-Modified: $Date: 2006/06/12 22:03:07 $ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 31-Oct-2005 Post-History: 1-Nov-2005, 5-Nov-2005, 7-Nov-2005, 11-Dec-2005, 13-Dec-2005, 18-Dec-2005, 5-Jan-2006, 2-Mar-2006, 6-Mar-2006, 12-Jun-2006 Abstract This GLEP proposes a new way of informing users about important updates and news related to the tree. Motivation == Although most package updates are clean and require little user action, occasionally an upgrade requires user intervention. Recent examples of the latter include the ``gcc-3.4`` stabilisation on ``x86`` and the ``mysql-4.1`` database format changes. There are currently several ways of delivering important news items to our users, none of them particularly effective: * Gentoo Weekly News * The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists * The Gentoo Forums * The main Gentoo website * RSS feeds of Gentoo news * ``einfo`` and ``ewarn`` messages in ``pkg_setup`` or ``pkg_postinst`` A more reliable way of getting news of critical updates out to users is required to avoid repeats of various prior upgrade debacles. This GLEP proposes a solution based around pushing news items out to the user via the ``rsync`` tree. .. Important:: This GLEP does not seek to replace or modify ``einfo`` messages which are displayed post-install. That is a separate issue which is handled by ``elog`` [#bug-11359]_. Requirements An adequate solution must meet all of the following requirements: 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. No user subscription required It has already been demonstrated [#forums-apache2]_ that many users do not read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution that requires subscription has no advantage over current methods. No user monitoring required It has already been demonstrated [#forums-apache2]_ that many users do not read news items posted to the Gentoo website, or do not read news items until it is too late. A solution that relies upon active monitoring of a particular source has no advantage over current methods. Relevant System administrators who do not use a particular package should not have to read news items which affect purely that package. Some news items may be of relevance to most or all users, but those that are not should not be forced upon users unnecessarily. Lightweight It is not reasonable to expect all users to have an MTA, web browser, email client, cron daemon or text processing suite available on their system. Users must not be forced to install unreasonable extra software to be able to read news items. No privacy violations Users of the solution should not be required to provide information about their systems (for example, IP addresses or installed packages). Multiple delivery method support Some users may wish to view news items via email, some via a terminal and some via a web browser. A solution should either support all of these methods or (better still) make it simple to write clients for displaying news items in different ways. The following characteristics would be desirable: Internationalisable Being able to provide messages in multiple languages may be beneficial. Quality control There should be some way to ensure that badly written or irrelevant messages are not sent out, for example by inexperienced developers or those whose English language skills are below par. Simple for developers Posting news items should be as simple as is reasonably possible. Simple for users Reading relevant news items should be as simple as is reasonably possible. Compatibility with existing and future news sources A news system would ideally be able to be integrated with existing news sources (for example, Forums, GWN, the main Gentoo website) without ex
[gentoo-dev] GLEP 42 (News) revisited
Since GLEP 42's original author and sponsor has left the project, I've taken it over, and would like to have another go at getting it implemented. I've just updated the version in CVS[1], which should be making its way onto the www nodes, but with any luck the full text should be attached here for convenience. So, I'd like to ask for any further input on this, and if noone has any major issues with it, I'd like to put it into the Council's queue for discussion at the next opportunity. Changes since the previous posted version: * Added details of a reference implementation.GLEP: 42 Title: Critical News Reporting Version: $Revision: 1.10 $ Author: Ciaran McCreesh <[EMAIL PROTECTED]> Last-Modified: $Date: 2006/06/12 22:03:07 $ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 31-Oct-2005 Post-History: 1-Nov-2005, 5-Nov-2005, 7-Nov-2005, 11-Dec-2005, 13-Dec-2005, 18-Dec-2005, 5-Jan-2006, 2-Mar-2006, 6-Mar-2006, 12-Jun-2006 Abstract This GLEP proposes a new way of informing users about important updates and news related to the tree. Motivation == Although most package updates are clean and require little user action, occasionally an upgrade requires user intervention. Recent examples of the latter include the ``gcc-3.4`` stabilisation on ``x86`` and the ``mysql-4.1`` database format changes. There are currently several ways of delivering important news items to our users, none of them particularly effective: * Gentoo Weekly News * The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists * The Gentoo Forums * The main Gentoo website * RSS feeds of Gentoo news * ``einfo`` and ``ewarn`` messages in ``pkg_setup`` or ``pkg_postinst`` A more reliable way of getting news of critical updates out to users is required to avoid repeats of various prior upgrade debacles. This GLEP proposes a solution based around pushing news items out to the user via the ``rsync`` tree. .. Important:: This GLEP does not seek to replace or modify ``einfo`` messages which are displayed post-install. That is a separate issue which is handled by ``elog`` [#bug-11359]_. Requirements An adequate solution must meet all of the following requirements: 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. No user subscription required It has already been demonstrated [#forums-apache2]_ that many users do not read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution that requires subscription has no advantage over current methods. No user monitoring required It has already been demonstrated [#forums-apache2]_ that many users do not read news items posted to the Gentoo website, or do not read news items until it is too late. A solution that relies upon active monitoring of a particular source has no advantage over current methods. Relevant System administrators who do not use a particular package should not have to read news items which affect purely that package. Some news items may be of relevance to most or all users, but those that are not should not be forced upon users unnecessarily. Lightweight It is not reasonable to expect all users to have an MTA, web browser, email client, cron daemon or text processing suite available on their system. Users must not be forced to install unreasonable extra software to be able to read news items. No privacy violations Users of the solution should not be required to provide information about their systems (for example, IP addresses or installed packages). Multiple delivery method support Some users may wish to view news items via email, some via a terminal and some via a web browser. A solution should either support all of these methods or (better still) make it simple to write clients for displaying news items in different ways. The following characteristics would be desirable: Internationalisable Being able to provide messages in multiple languages may be beneficial. Quality control There should be some way to ensure that badly written or irrelevant messages are not sent out, for example by inexperienced developers or those whose English language skills are below par. Simple for developers Posting news items should be as simple as is reasonably possible. Simple for users Reading relevant news items should be as simple as is reasonably possible. Compatibility with existing and future news sources A news system would ideally be able to be integrated with existing news sources (for example, Forums, GWN, the main Gentoo website) without excessive difficulty. Similarly, easy interoperation with any future news sources should not be precl
Re: [gentoo-dev] GLEP 42 (news) Round Seven
Ciaran McCreesh wrote: > * Removed --ask message, apparently it's superfluous. Why? I haven't found any conclusion about that in the last thread. It doesn't make sense to show the message in both `emerge -p foo` and `emerge foo`, but not in `emerge -a foo`, IMHO. WKR, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP 42 (news) Round Seven
On Thursday 05 January 2006 10:11, Ciaran McCreesh wrote:
>
> I might end up being offline over the weekend (and possibly for a while
> after that too...), but I'll get around to any feedback as soon as I
> can...
While it is entirely nitpicking at this point as I understand what you meant:
Under Client Side you clearly identify ${repoid} as a variable when used for
example in the context of ``news-${repoid}.unread``. However in the following
section, News Item Clients, you refer to ``news-repoid.unread`` and
``news-repoid.read``, I'd just throw repoid in those cases into a ${} for
people reading it that weren't involed in the implementaiton so that know
that unless the repo is actually named 'repoid' no such file will exist.
Thanks and +1,
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
pgpFHo5aPMVVn.pgp
Description: PGP signature
Re: [gentoo-dev] GLEP 42 (news) Round Seven
Brian Harring wrote: +1 on this revision, although I demand a pony. +1, w/out pony. lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (news) Round Seven
On Thu, Jan 05, 2006 at 03:11:38PM +, Ciaran McCreesh wrote: > Nerry there now... Changes: > > * Due to overwhelming demand (it's the thing in this GLEP that has > generated least contention!), spaces are not allowed in repository > names. +1 on this revision, although I demand a pony. ~harring pgpaoH8casuGP.pgp Description: PGP signature
[gentoo-dev] GLEP 42 (news) Round Seven
Nerry there now... Changes:
* Due to overwhelming demand (it's the thing in this GLEP that has
generated least contention!), spaces are not allowed in repository
names.
* Colons aren't allowed in repository or file names either, since
they're not going to be allowed in package names (see previous
discussion).
* News item signing is now mandatory ('must' rather than 'should').
Keychain, format / strength etc. are left for those doing the signing
work to decide.
* Clarified Revision: wording.
* Clarified Display-If-Installed: wording.
* Removed "can be sent to -core" note. If it's ever necessary, the
people handling it should have enough sense to do what's right.
* Added "frequency of news updates syncing is unspecified" note.
* Added permissions note.
* Removed --ask message, apparently it's superfluous.
* Added "the package manager doesn't need to know about the news
client" note.
* Clarified .skip wording.
* Couple of minor typo fixes.
A rendered version will show up on the web in an hour or three.
I might end up being offline over the weekend (and possibly for a while
after that too...), but I'll get around to any feedback as soon as I
can...
--
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
GLEP: 42
Title: Critical News Reporting
Version: $Revision: $
Author: Ciaran McCreesh <[EMAIL PROTECTED]>
Last-Modified: $Date: $
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 31-Oct-2005
Post-History: 1-Nov-2005, 5-Nov-2005, 7-Nov-2005, 11-Dec-2005, 13-Dec-2005,
18-Dec-2005, 5-Jan-2006
Abstract
This GLEP proposes a new way of informing users about important updates and news
regarding tree-related items.
Motivation
==
Although most package updates are clean and require little user action,
occasionally an upgrade requires user intervention during the upgrade process.
Recent examples of the latter include the ``gcc-3.4`` stabilisation on ``x86``
and the ``mysql-4.1`` database format changes.
There are currently several ways of delivering important news items to our
users, none of them particularly effective:
* Gentoo Weekly News
* The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists
* The Gentoo Forums
* The main Gentoo website
* RSS feeds of Gentoo news
* ``einfo`` and ``ewarn`` messages in ``pkg_setup`` or ``pkg_postinst``
A more reliable way of getting news of critical updates out to users is required
to avoid repeats of the various recent upgrade debacles. This GLEP proposes a
solution based around pushing news items out to the user via the ``rsync`` tree.
.. Important:: This GLEP does not seek to replace or modify ``einfo`` messages
which are displayed post-install. That is a separate issue which is handled
by ``elog`` [#bug-11359]_.
Requirements
An adequate solution must meet all of the following requirements:
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.
No user subscription required
It has already been demonstrated [#forums-apache2]_ that many users do not
read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution which
requires subscription has no advantage over current methods.
No user monitoring required
It has already been demonstrated [#forums-apache2]_ that many users do not
read news items posted to the Gentoo website, or do not read news items
until it is too late. A solution that relies upon active monitoring of a
particular source has no advantage over current methods.
Relevant
System administrators who do not use a particular package should not have to
read news items which affect purely that package. Some news items may be of
relevance to most or all users, but those that are not should not be forced
upon users unnecessarily.
Lightweight
It is not reasonable to expect all users to have an MTA, web browser, email
client, cron daemon or text processing suite available on their system.
Users must not be forced to install unreasonable extra software to be able
to read news items.
No privacy violations
Users of the solution should not be required to provide information about
their systems (for example, IP addresses or installed packages).
Multiple delivery method support
Some users may wish to view news items via email, some via a terminal and
some via a web browser. A solution should either support all of these
methods or (better still) make it simple to write clients for displaying
news items in different ways.
The following characteristics would be desirable:
Internationalisable
Being able to provide messages in multiple languages may
Re: [gentoo-dev] glep 42 (news) round six
On Sunday 18 December 2005 05:15, Ciaran McCreesh wrote: > You are encouraged to reply to this thread saying "I agree with ciaranm > that repository IDs should not be allowed to contain spaces". I agree with ciaranm that repository IDs should not be allowed to contain spaces. Paul ps. Thanks for the perseverence on this glep. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpUJvQ16Kley.pgp Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
On Sun, Dec 18, 2005 at 04:52:23PM +, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 23:27:32 -0800 Brian Harring <[EMAIL PROTECTED]> > wrote: > | To head off the "don't make features that are easily screwed up", > | this isn't one of them- this is expecting code to behave correctly > | from the path standpoint. > > Hrm, so will we be allowing spaces in package and category names too? No, due to atoms in *depend being seperated by whitespace. Wouldn't work without introducing escaping into it- beyond that the cat/pkg standard is in place already. Your repo_id however, is not, thus it's mallable. It's irrevelant either way- as I stated, your code *needs to be* space safe. Existing repo label'ing code in saviour _already_ allows spaces (it's just a fricking name), dissallowing spaces due to a concern that someone might screw up is daft. So... don't point at other things that are already set in stone and disallow spaces for their own reasons; state why it must be disallowed here, or merely state "I hate spaces". Like I said a couple of emails back, block spaces in repo_id if you like, either way the code involved has to be space safe for paths, so it's an arbitrary restriction... Dunno. Either way, path handling *must* be space safe anyways- if you restrict repo_id to lack spaces, your choice, still going to allow external aliasing of the repo_id to have spaces. > | > I don't want to introduce any signing requirements that we don't > | > have already. When signing for everything else becomes mandatory, > | > signing for news would be too. If I make this a 'must', someone > | > will ask me to specify how we're handling the Gentoo keyring... > | > | Pawn the keyring off on others. The issues isn't an established > | trust ring, it's required signing- yes, a trust ring makes things a > | helluva lot easier on the user front, but it's useless without a > | required signing policy. > | > | We've already had this conversation also btw, in the > | beginning of glep42 iirc. Obviously I don't agree > | with your reasoning "I'll do it when it's required I do it". It's > | useful now, it becomes massively more useful when a trust ring is > | available. > > Ok, how about I change it to "must", and add a note under Backwards > Compatibility along the lines of: > > At the time of writing, there is no standardised mechanism for handling > GPG signatures in Gentoo. Until such a mechanism exists, GPG signing > cannot be considered mandatory. And provisions for going back and signing everything that was _not_ signed while you delaying waiting for a keyring? That's why I'm pushing it. Mandate it as required now, keyring down the line just makes it more useful. Make it 'suggested' (which this is, you've changed nothing but words), you've left a mess that needs to be addressed when keyring comes about. Same scenario as before, think forward- force it from the get go, less crap to deal with down the line. Mandate it, no mess- just the pre-existing problem of getting a keyring collected. Delay it, keyring + going back and trying to get folk to re-sign their releases. That and any unsigned material released during that period cannot be verified, because we're waiting for a keyring. See the gains? Might be unpalatable, but it is the path of least work long term. > Ok, how's this? > > ``Revision:`` > Initially 1. Should be incremented every time a change is made to > the news item. Changes that require a re-read of the news item (for > example, most changes that are not spelling or formatting related) > should instead use a new news item. Mandatory. Works, thank you. > | > | This isn't incredibly useful if ranged versions are ever > | > | introduced. Ammending the glep for that seems stupid, looser > | > | language might be wise. > | > > | > What's the syntax for ranged versions? And how do they differ from > | > SLOT versions? > | > | >=kde-base/kde-libs-3.0 <=kde-base/kde-libs-4.0 > | > | It's not syntax as much as a boolean and of atoms. > > Hrm, ok. Wouldn't this resolve as true if you have kde-libs-2.0 and > kde-libs-5.0 installed (assuming SLOTted kde-libs)? Note I said boolean and. Resolution of that string *should* result in 3-4 via portage processing of it; doesn't handle it perfectly, but the reason I brought it up is that via limiting it to a single atom, you block (if/when) ranged versions. > | Any signed item would need to be verified also, although fortunately > | this chunk can be done in parallel to regen run. > > Hrm, is signing verification done for tree items? *If* a component was fully signed, verification prior to dissemination should occur. Reliant on a keyring to automate it however, plus some voodoo to make as much as possible go in parallel (so as not to overrun the window). > | > | You haven't stated how the 'package manager' will trigger the > | > | user's reader of choice for these targets. Should also extend > | > | this
Re: [gentoo-dev] glep 42 (news) round six
On Sun, 18 Dec 2005 12:18:16 +0200 Marius Mauch <[EMAIL PROTECTED]> wrote: | Another new issue nobody has mentioned yet: | The GLEP doesn't say anything about file permissions/ownership as in | who will/should be able to a) read news and b) modify the news-* | files. Without thinking too much about it I'd say a) users in portage | group and b) root. My prototype hack has the news files as 664, so even non-Portage-group users can read things -- they just can't update the news-*.read files. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
On Sat, 17 Dec 2005 23:27:32 -0800 Brian Harring <[EMAIL PROTECTED]> wrote: | To head off the "don't make features that are easily screwed up", | this isn't one of them- this is expecting code to behave correctly | from the path standpoint. Hrm, so will we be allowing spaces in package and category names too? | > I don't want to introduce any signing requirements that we don't | > have already. When signing for everything else becomes mandatory, | > signing for news would be too. If I make this a 'must', someone | > will ask me to specify how we're handling the Gentoo keyring... | | Pawn the keyring off on others. The issues isn't an established | trust ring, it's required signing- yes, a trust ring makes things a | helluva lot easier on the user front, but it's useless without a | required signing policy. | | We've already had this conversation also btw, in the | beginning of glep42 iirc. Obviously I don't agree | with your reasoning "I'll do it when it's required I do it". It's | useful now, it becomes massively more useful when a trust ring is | available. Ok, how about I change it to "must", and add a note under Backwards Compatibility along the lines of: At the time of writing, there is no standardised mechanism for handling GPG signatures in Gentoo. Until such a mechanism exists, GPG signing cannot be considered mandatory. | > | > ``Revision:`` | > | > Initially 1. Incremented every time a non-trivial change is | > | > made. Changes which require a re-read of the news item should | > | > instead use a new news item file. Mandatory. | > | | > | non-trivial changes that don't require a re-read sounds like a | > | contradiction. Clarify, especially since portage will mark this | > | as read _once_ and only once. | > | > Hrm, word it as "Changes other than minor formatting tweaks", or | > remove "non-trivial"? | | It's not a wording thing, I'm pointing out sans spelling corrections | and trivial word mangling, any new info jammed in requires a new item | bump so readers can display the changes. | | In light of that, wording above needs correction. Ok, how's this? ``Revision:`` Initially 1. Should be incremented every time a change is made to the news item. Changes that require a re-read of the news item (for example, most changes that are not spelling or formatting related) should instead use a new news item. Mandatory. | > | This isn't incredibly useful if ranged versions are ever | > | introduced. Ammending the glep for that seems stupid, looser | > | language might be wise. | > | > What's the syntax for ranged versions? And how do they differ from | > SLOT versions? | | >=kde-base/kde-libs-3.0 <=kde-base/kde-libs-4.0 | | It's not syntax as much as a boolean and of atoms. Hrm, ok. Wouldn't this resolve as true if you have kde-libs-2.0 and kde-libs-5.0 installed (assuming SLOTted kde-libs)? | > Once an hour would work fine. On the other hand, the merge is just | > copying a few small files -- time-wise, it's less than generating | > the cache for a couple of ebuilds. | | More then a couple; this beast will bloat up to hundred or so files | I'd expect (remember translation serves as a multiplier). Yup, but it's just a case of copying a few small text files. | Any signed item would need to be verified also, although fortunately | this chunk can be done in parallel to regen run. Hrm, is signing verification done for tree items? | > | You haven't stated how the 'package manager' will trigger the | > | user's reader of choice for these targets. Should also extend | > | this to allow a way to disable any news notices, lest someone's | > | cronjob get hung displaying news (feature or not, it's needed). | > | > The same way the package manager handles updating config files: it | > won't. It'll just tell the user that some news items need reading. | | And you'll personally handle all of the bug spam from feature | requests that --ask trigger $news_reader? | | It's a logical extension, thus people will ask for it. What does emerge --ask do currently for config files? | We expire updates? If so, someone might want to look at the updates | from 3 years back... Yes. Once a year, Seemant shows up and says "hey, does anyone ever expire really really old updates entries?". | > | > There is an existing automated tool [#forums-glsa]_ for posting | > | > GLSAs to the forums. A similar tool can be used for these news | > | > items. | > | | > | Pawned it off on someone, or something you'll be doing? | > | > Hopefully the former. I have it on reasonably good authority that it | > won't take more than half an hour if I end up having to do it | > though... | | Get cracking then (regardless if it's pawning or coding). Eh, that one can be left until the last minute. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
On Sun, 2005-12-18 at 09:57 -0500, Philip Webb wrote: > > You are encouraged to reply to this thread > > saying "I agree with ciaranm > > that repository IDs should not be allowed to contain spaces". > > No problem at all there (smile): spaces in names are A Bad Thing for Unix, > as they conflict with the basic format of the command-line > & were introduced by M$ (Mac ?) to make things easier for idiots. So you're saying long filenames were invented by Microsoft for Windows 95? ;-) As long as programmers don't assume that filenames won't have spaces I don't see the problem > The proper procedure for Unix-type systems is to use an underline symbol. Which "standard" says that, and how silly is that? We're past the 80s, there's no reason to limit filenames to alphanumeric (as I think with the same reasoning you'd forbid unicode ...) > > Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) > Does your brain really contain that many viruses ... ? Only because it runs Windows ;-) -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] glep 42 (news) round six
051218 Ciaran McCreesh wrote: > * Change to -mm-dd for GLEP 45 compatibility. Good to see Gentoo adopting correct international date format. > You are encouraged to reply to this thread > saying "I agree with ciaranm > that repository IDs should not be allowed to contain spaces". No problem at all there (smile): spaces in names are A Bad Thing for Unix, as they conflict with the basic format of the command-line & were introduced by M$ (Mac ?) to make things easier for idiots. The proper procedure for Unix-type systems is to use an underline symbol. > Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Does your brain really contain that many viruses ... ? -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] glep 42 (news) round six
On Sun, Dec 18, 2005 at 12:18:16PM +0200, Marius Mauch wrote: > Brian Harring wrote: > >On Sun, Dec 18, 2005 at 06:23:55AM +, Ciaran McCreesh wrote: > > > >>On Sat, 17 Dec 2005 21:50:47 -0800 Brian Harring <[EMAIL PROTECTED]> > >>| You haven't stated how the 'package manager' will trigger the user's > >>| reader of choice for these targets. Should also extend this to allow > >>| a way to disable any news notices, lest someone's cronjob get hung > >>| displaying news (feature or not, it's needed). > >> > >>The same way the package manager handles updating config files: it > >>won't. It'll just tell the user that some news items need reading. > > > > > >And you'll personally handle all of the bug spam from feature requests > >that --ask trigger $news_reader? > > > >It's a logical extension, thus people will ask for it. > > I don't think so. > How many people have asked for etc-update integration? etc-update style notices are at exit of emerge. This proposal has news item warnings prior to the merge actually occuring (no specification of sleep however). Different scenario, thus etc-update isn't a good indicator. > To quote myself: > "Granted race conditions might be an issue (where the solution > complicates tools), but that's so minor I wouldn't really care about > it." > That I wouldn't care about it isn't a general recommendation to ignore > the issue. Yes, for a perfect solution it is required, but do we aim for > a perfect solution? We do if it potentially allows for 'critical' news to be unseen, at least imo. > Another new issue nobody has mentioned yet: > The GLEP doesn't say anything about file permissions/ownership as in who > will/should be able to a) read news and b) modify the news-* files. > Without thinking too much about it I'd say a) users in portage group and > b) root. *cough* good point. ;) ~harring pgpacHFQeelTO.pgp Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
Brian Harring wrote: On Sun, Dec 18, 2005 at 06:23:55AM +, Ciaran McCreesh wrote: On Sat, 17 Dec 2005 21:50:47 -0800 Brian Harring <[EMAIL PROTECTED]> | You haven't stated how the 'package manager' will trigger the user's | reader of choice for these targets. Should also extend this to allow | a way to disable any news notices, lest someone's cronjob get hung | displaying news (feature or not, it's needed). The same way the package manager handles updating config files: it won't. It'll just tell the user that some news items need reading. And you'll personally handle all of the bug spam from feature requests that --ask trigger $news_reader? It's a logical extension, thus people will ask for it. I don't think so. How many people have asked for etc-update integration? | implementation issue; you need locking on this. If portage has to | farm out to the users reader of choice, then it needs to lock the | file to keep readers/writers from screwing with each other. We do? Marius told me it wasn't worth it. I disagree. It's mainly contingent upon $news_reader being spawned via --ask, although it *also* matters heavily if the user is flipping through their news while a sync in the background is running- if the utility updates on the way out, unless their is some advisorial locking involved, you've just lost all of the new synced unread news. To quote myself: "Granted race conditions might be an issue (where the solution complicates tools), but that's so minor I wouldn't really care about it." That I wouldn't care about it isn't a general recommendation to ignore the issue. Yes, for a perfect solution it is required, but do we aim for a perfect solution? | > News items can be removed (by removing the news file from the main | > tree) when they are no longer relevant, if they are made obsolete | > by a future news item or after a long period of time. This is the | > same as the method used for ``updates`` entries. | | implementation issue; updating unread/skip crap so it doesn't bloat | is required, but time frame also matters (crap sync resulting in news | getting removed, yet it still being valid, just missing from the | local tree). Hrm. We can't take the same approach here as we do with expiring updates entries? We expire updates? If so, someone might want to look at the updates from 3 years back... Yeah, mainly me dropping old files sometimes (happened two times so far IIRC), so not a general policy documented anywhere (just doing it when I get annoyed by portage re-applying ancient entries). Another new issue nobody has mentioned yet: The GLEP doesn't say anything about file permissions/ownership as in who will/should be able to a) read news and b) modify the news-* files. Without thinking too much about it I'd say a) users in portage group and b) root. Marius -- gentoo-dev@gentoo.org mailing list
