Re: [gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
This feature should only be used for things that are directly related to the tree, and will cause mass breakage if ignored.I fully agree with this statement. I am behind the adoption of the GLEP only if it does what (I originally believed) was its purpose...to get CRITICAL news regarding package upgrades..etc. If a user wants to know what's going on with the developers..they can subscribe to this -dev list. If a user wants to know how to NOT break his system by performing an 'emerge -u world' portage should tell them. -- Mint ShowsOffice of Information TechnologyUniversity of Mississippi[EMAIL PROTECTED](662) 915-5222
Re: [gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
Mint Shows wrote: This feature should only be used for things that are directly related to the tree, and will cause mass breakage if ignored. I fully agree with this statement. I am behind the adoption of the GLEP only if it does what (I originally believed) was its purpose...to get CRITICAL news regarding package upgrades..etc. If a user wants to know what's going on with the developers..they can subscribe to this -dev list. If a user wants to know how to NOT break his system by performing an 'emerge -u world' portage should tell them. -- Mint Shows I fully agree here, or in the case of Apache, which my its self is not a critical system component, but its is a very important part of many user's systems, that is also worthy of a NEWS Item. On another note, i'm not exactly sure how this would be implemented, but perferably wouldn't the new NEWS Items be best if provided before a package upgrade? for example emerge -avu apache These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuildU ] net-www/apache-2.0.54-r31 *(1 News Item) [2.0.54-r30] +apache2 -debug -doc -ldap -mpm-leader -mpm-peruser -mpm-prefork -mpm-threadpool -mpm-worker -no-suexec (-selinux) +ssl -static-modules -threads 5,488 kB Total size of downloads: 5,488 kB Would you like to read the unread News Item? [Yes/No] Do you want me to merge these packages? [Yes/No] Of course, running emerge -vu apache shouldn't be stopped, it should continue with its own risk. Thats just one thing i would like to see. Tux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
Personally, I do not think the tree is the place for anything besides that which relates to the tree. I really do not think users would appreciate there sync being burdoned by Developer x broke his toe this week ; developer y is going to italy ; We recently recieved 3 new mirrors and have all this shown on their screen. This feature should only be used for things that are directly related to the tree, and will cause mass breakage if ignored. On 11/20/05, Stuart Herbert [EMAIL PROTECTED] wrote: On Sun, 2005-11-20 at 13:06 -0500, Chris Gianelloni wrote: Huh? I was using it as an example of something that I would not be interested in seeing in *my* tree since I wouldn't ever be able to attend. What did you think I meant by it. Did I at any point say that the UK dev meets are a bad thing? I felt that you laboured the point beyond what was reasonable. It's a mis-understanding on my part, and I apologise. The events I've been involved in organising have been events for users, and they've always been put together by both developers and users. I believe that some of our users *are* interested in exactly this type of news - and, from the enquiries I've had in the past, not just UK-based people. Not in the tree. There is already a place for this stuff. Delivering news via this mechanism allows us to reach far more people than we can via the other places. If we could already reach everyone, we wouldn't need this mechanism in the first place. It really sounds like you are wanting to make this proposal way too complex, but I'll wait for the actual GLEP text before making any more comments. I don't see the complexity here. We're proposing a capability to deliver news direct to our users, in a way that can be completely disabled or personalised. How many large corporations would kill to have something that could do that? ;-) If I can't convince you of the merits, I guess there's nothing else for it but to continue work on delivering the proposal without your support :( Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
George Prowse posted [EMAIL PROTECTED], excerpted below, on Sat, 19 Nov 2005 01:44:31 +: Having organised several Gentoo UK meetings I would like to be advised if anyone has a problem; especially if they dont come or have no idea when, where or what they are. Top posting lost the context. Anyway... As I read the upline, the original point made had nothing to do about UK meetings in particular, that was just an example. The point made was that the purpose of this feature is to get out vital do this if you don't want your system broken when you upgrade type news. Folks that want announcements of meetings and that sort of thing can subscribe to GWN -- that's what it's for. If this feature starts getting used for that, then folks will start ignoring it, because the SNR is too low to be of any use for the intended purpose. Nothing against UK meetings, or /any/ meetings, for that matter. The place to get that sort of news is GWN. GLEP 42 is, and should remain, different, as proposed, and in both my opinion and that of the original poster that had the misfortune of bringing up the UK meetings as what was supposed to be an off-hand example, and apparently hitting a sore spot. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
Chris Gianelloni posted [EMAIL PROTECTED], excerpted below, on Sat, 12 Nov 2005 10:26:08 -0500: I hope that the technical solution will allow users to choose to see news about packages that are not installed - so that we can deliver news that isn't strictly package related, such as new Gentoo LiveCDs, or a Gentoo event, or so that we can deliver news where the package isn't yet in the tree (f.ex. announcing a new overlay, or Gentoo-hosted project). This is where I disagree with you completely. As a Gentoo user, I could give a damn about a few developers getting together in the UK, and would be pretty pissed off if Gentoo had this sort of garbage mixed in with the critical information. This entire thing came about due to the need to get *critical* information to our users. If users are interested in non-critical information, there's already a mechanism in place for them to get such things. They can join the mailing lists. Do we not already have a gentoo-events list? We also have a gentoo-releng list, or gentoo-announce. Wow! No kidding! I too am off the (strong) opinion that those that /want/ social news and the like can already get it from GWN and the various lists. We do NOT need portage spamming us with non-critical announcements, or the channel will get so noisy folks will start ignoring it. BTW, I just had an experience that would have been a perfect match for critical news! I just merged the new glibc-2.3.6, over the 2.3.5.2005mmdd snapshot I was running due to the gcc4 fixes, and got clobbered over the head with portages's symlink bug! There's a message in red in the ebuild, that I happened to glance at just in time to see it move offscreen, but it said the problem was unsuccessful merges with current portage, which I took to mean /stable/ portage. No problem, I thought, I'm running ~arch, so it should be fine, and if it's not, it'll just break the emerge and I'll worry about it then. THE MESSAGE DIDN'T SAY IT WOULD MERGE JUST FINE, THEN ON THE OLD VERSION UNMERGE, WOULD PRETTY MUCH KILL MY SYSTEM!! =8^P Luckily I already had a couple mc sessions going, and having read the caution about doing symlinks in a single step when updating glibc, in O'Reilly's Running Linux, way back when I got serious about Linux and decided I was going to switch from MSWormOS, /and/ having caught just enough of the notice to get me thinking in that direction, I recognized the issue immediately, and was able to use the already running midnight commander instances to browse the portage database and restore enough symlinks manually, to be able to run bunzip2 again, and open up the binpkg (FEATURES=buildpkg) in mc's virtualfs and copy over the rest of the symlinks. Even if not, that's why I have snapshotted root dirs, so I could have rebooted into one of those to fix it. However, as I said, this would have made the /perfect/ candidate for a critical news warning! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
Grobian posted [EMAIL PROTECTED], excerpted below, on Sat, 12 Nov 2005 09:49:11 +0100: Stuart Herbert wrote: I thought I'd been very clear in the email that you've replied to that I support making the news available via other ways. It's the timing that I'm a bit worried about. And that worries me. Because you more or less suggest to postpone implementing (just activating) traditional solutions, being used by many equivalent others in our field (works for them, more or less) in favour of an experimental new thing. I agree to some extent with both viewpoints, here. I think the viewpoint of the portage first side is that we already have the traditional stuff, the announce and dev list, the GWN, the forums, and system changing announcements generally make it to most if not all those already, but it's not working for some folks, and we want to see if there's anything more that can be done, thus, the news-thru-portage proposal. This viewpoint holds that since the portage angle is going to form the core of things, since that's the main /new/ feature, implementing it should be first, with the system designed around that, /then/ the additional automated notifiers can be put into effect after the main infrastructure is complete. Valid viewpoint with some strong points supporting it. The traditional side first viewpoint recognizes that getting portage set up and a new version rolled out to stable, after the usual level of testing, with all these new features, is going to take awhile. This viewpoint says nail down the reference format, create the dir in the portage tree, set up the vetting process, and get started putting the notices in the tree ASAP. This won't require rolling out a new version of portage, since current portage will just sync the new dir, and ignore it. At this point, we won't even have local portage doing the filtering, the stuff will just be delivered in the portage tree sync and stay there, but that's fine. Once the supply side of the infrastructure is set up, that will allow user submitted tools, outside of portage, a chance to go to it. Since these separate tools don't have the Gentoo-vital duties that emerge/portage does, these tools could be deployed relatively quickly, with rather less testing. Likely, there'd fairly quickly be a couple of unofficial ebuilds available on the user list and forums, much like the several implementations of eclean, the one of which has now been chosen to put into portage and is now in ~arch. At the same time and also rather more rapidly than portage could evolve and be tested, various devs could be working on the automated scripts that would post the notices to the forums, announce and probably user lists, and a web page, perhaps hanging off of packages.gentoo.org. Portage's functionality, meanwhile, would come along in due time, likely rather after several other delivery implementations are active, because of the time required to implement it in an already functional and vital program, without breaking anything, AND to properly test to be SURE nothing broke. This too is a valid viewpoint, with its strong points, the biggest weak point being that because other delivery implementations will be using the standard before portage gets nicely tested with it, it's possible something unforeseen will come up with the reference format that makes it more difficult to implement in what was after all the whole reason it was put together in the first place -- portage. With other stuff already using the format, it'd be far more difficult to tweak it if needed by the portage implementation, without breaking the other stuff. Noting of course that I'm here, and I'm reading announce, and GWN, therefore the proposal, while useful for me, isn't directly targeted at me, and further noting that I'm not the one that's gotta do the implementation, I can never-the-less post my druthers on the subject. If I were implementing it, I'd probably go this second way. It'll get stuff out there and working faster than the first way, and provided appropriate care is taken in drafting the reference format and implementing the initial delivery into the tree infrastructure, the risk of disturbing portage's development in the area is relatively low. We get the release early, release often going right away, and the other stuff will naturally follow. Another good reason to start with the 'common' things. The traditional ways some of your 100% of our users will be common with. Nothing new there for them. The portage way *is* new, and has never been done, hence they might have difficulties to get it. I don't see that happening. Folks using Gentoo are already programmed to use emerge for all their updates and to get new packages. There's little else to get. Please remember that many of your 100% of our users hates software that doesn't work. It wouldn't be the first time a user decides never to use a piece of software again, because his/her first experience
Re: [gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
On Sat, 2005-11-12 at 04:32 -0700, Duncan wrote: I agree to some extent with both viewpoints, here. I think the viewpoint of the portage first side is that we already have the traditional stuff, the announce and dev list, the GWN, the forums, and system changing announcements generally make it to most if not all those already, but it's not working for some folks, and we want to see if there's anything more that can be done, thus, the news-thru-portage proposal. This viewpoint holds that since the portage angle is going to form the core of things, since that's the main /new/ feature, implementing it should be first, with the system designed around that, /then/ the additional automated notifiers can be put into effect after the main infrastructure is complete. I think I'd prefer a more simultaneous rollout. The reason is fairly simple, and I have stated it before and nobody has refuted it, only ignored it. What about packages not installed? Also, it's going to take a while to go stable. During this time, users could also be using the other resources that would become available. Sure, we won't hit everyone, but it'll still be an increase from what we have now. Once the newer portage version with this feature goes stable, the number would go up again. I also agree that the meat of this proposal is portage-delivered news. Valid viewpoint with some strong points supporting it. The traditional side first viewpoint recognizes that getting portage set up and a new version rolled out to stable, after the usual level of testing, with all these new features, is going to take awhile. This viewpoint says nail down the reference format, create the dir in the portage tree, set up the vetting process, and get started putting the notices in the tree ASAP. This won't require rolling out a new version of portage, since current portage will just sync the new dir, and ignore it. At this point, we won't even have local portage doing the filtering, the stuff will just be delivered in the portage tree sync and stay there, but that's fine. Correct. Once the supply side of the infrastructure is set up, that will allow user submitted tools, outside of portage, a chance to go to it. Since these separate tools don't have the Gentoo-vital duties that emerge/portage does, these tools could be deployed relatively quickly, with rather less testing. Likely, there'd fairly quickly be a couple of unofficial ebuilds available on the user list and forums, much like the several implementations of eclean, the one of which has now been chosen to put into portage and is now in ~arch. Actually, gentoolkit but correct otherwise. At the same time and also rather more rapidly than portage could evolve and be tested, various devs could be working on the automated scripts that would post the notices to the forums, announce and probably user lists, and a web page, perhaps hanging off of packages.gentoo.org. Portage's functionality, meanwhile, would come along in due time, likely rather after several other delivery implementations are active, because of the time required to implement it in an already functional and vital program, without breaking anything, AND to properly test to be SURE nothing broke. Again, correct. This is why I don't think it is possible to wait for it to get into portage before launching it anywhere else. This too is a valid viewpoint, with its strong points, the biggest weak point being that because other delivery implementations will be using the standard before portage gets nicely tested with it, it's possible something unforeseen will come up with the reference format that makes it more difficult to implement in what was after all the whole reason it was put together in the first place -- portage. With other stuff already using the format, it'd be far more difficult to tweak it if needed by the portage implementation, without breaking the other stuff. Noting of course that I'm here, and I'm reading announce, and GWN, therefore the proposal, while useful for me, isn't directly targeted at me, and further noting that I'm not the one that's gotta do the implementation, I can never-the-less post my druthers on the subject. If I were implementing it, I'd probably go this second way. It'll get stuff out there and working faster than the first way, and provided appropriate care is taken in drafting the reference format and implementing the initial delivery into the tree infrastructure, the risk of disturbing portage's development in the area is relatively low. We get the release early, release often going right away, and the other stuff will naturally follow. Another good reason to start with the 'common' things. The traditional ways some of your 100% of our users will be common with. Nothing new there for them. The portage way *is* new, and has never been done, hence they might have difficulties to get it. I don't see that happening.
[gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
Dan Meltzer wrote: Forever. How about, as long as relevant? ;) --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
Grant Goodyear posted [EMAIL PROTECTED], excerpted below, on Fri, 11 Nov 2005 15:09:58 -0600: I was going to say that the only way new news items could appear is during an emerge --sync, but of course that's not true for people who either add an overlay or use CVS. I'd be comfortable with making it run only at --sync time, or if it were triggered explicitly (--check-news, or some such). I don't believe that meets the emerging g consensus on the requirements: get news to as many as possible that don't get it now, and that won't go out and look for it. Others have pointed out that emerge sync is often unattended, as a cron job, so that won't get it in front of the 100% we're looking for. An explicit --check-news, while it might be nice, doesn't accomplish the task either, because that requires people to do something explicit to get it. Rather, Ciaran's take, from a post to a different subthread: I'd say after emerge --sync, plus after an emerge --pretend and before an emerge blah. Will there be hooks for these? We might put some sort of enews command in a new version of gentools covering current portage, before a new portage version with all the plumbing for news notifications at the times above built-in is released, but it should only be a stopgap measure. IMO it would also be wise to make the functionality feature controlled. Make a FEATURES=news, then turn it on by default, or go the negative route that is so distasteful to some on USE flags, and make it a FEATURES=nonews, emphasizing that Gentoo thinks it should /really/ be on by default. OTOH, the same thing could be accomplished by not making it a direct choice but simply allowing the existing rsync-exclude mechanism to do its thing, if folks set it to exclude the news subtree. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
maillog: 11/11/2005-05:48:50(-0700): Duncan types Perhaps $PORTDIR/news, with seen and unseen subdirs (and appropriate no-sync settings on the subdirs) Remember that $PORTDIR can be shared between machines. That's why world is kept in /var/lib/portage. -- \Georgi Georgiev \ Ignorance is bliss. -- Thomas Gray Fortune \ / [EMAIL PROTECTED]/ updates the great quotes, #42: BLISS is/ \ http://www.gg3.net/ \ ignorance. \ -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
Stuart Herbert posted [EMAIL PROTECTED], excerpted below, on Sun, 06 Nov 2005 20:37:14 +: On Sat, 2005-11-05 at 13:58 +0100, Grobian wrote: A lot Gentoo users I know read gentoo-announce and the GWN. But *many* more don't. That's what we learned from the Apache package refresh, and what we've also learned from the PHP5 work. While I agree with the point you make, I don't believe the apache upgrade issues were announced on the announce list. The news in the tree thing is a good idea, IMO, but it'll take some time to implement. Earth changing (for some Gentoo users) announcements can and should go to announce -- that's what it's there for. If I'm wrong about the apache upgrade, and it /was/ on announce, and I just forgot about seeing it /there/ as I had already seen it discussed here, which I /do/ remember, great! I just don't recall seeing it there, and tho I don't run apache myself, am of the opinion changes as big as those described for apache /should/ have been on announce. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
On Sun, 06 Nov 2005 14:38:47 -0700 Duncan [EMAIL PROTECTED] wrote: | While I agree with the point you make, I don't believe the apache | upgrade issues were announced on the announce list. The news in the | tree thing is a good idea, IMO, but it'll take some time to | implement. Earth changing (for some Gentoo users) announcements | can and should go to announce -- that's what it's there for. Why should every user have to sign up to be spammed with irrelevant GLSAs and news items for packages which they do not use? -- Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpdc639kxuBP.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
On Sunday 06 November 2005 13:38, Duncan wrote: I don't believe the apache upgrade issues were announced on the announce list. For the record, it was sent to the announce list on 2004-12-24. Message-Id: [EMAIL PROTECTED] Subject: [gentoo-announce] Apache packages refresh on 8th January 2005 pgpEpoIKfKkeT.pgp Description: PGP signature
