Re: [gentoo-dev] Re: Re: GLEP 42 Critical News Reporting Round Two
On 10-11-2005 20:55:37 +, Stuart Herbert wrote: Ok, you want a reaction, because you are Feeling Blue[1], right. On Mon, 2005-11-07 at 20:11 +0100, Grobian wrote: Ciaran McCreesh wrote: That's your first misconception right there. Most users don't sign up for things. Doesn't matter. I think it does. I believe that is the root cause of our difficulty in getting news to our users. We rely on our users coming to us to find the news. If they don't do that, they don't get the news. Our aim is to put the news in front of 100% of our userbase. Not the small fractions who check each of the places where news is currently published. You describe here (and in your diary) the aim to reach 100% of our user base. Wow, nice thing. Discussions on whether you will succeed or not, are out of the question right now, it's just your aim. Good. I hope you will succeed! Besides that, I see no arguments why users don't. No proof either. No proof?!? Did you read the original blog posting which kicked this off? Or the thread in the forums where our users claim the Apache upgrade was a surprise - even though this was a well-trailed change? That's just one change. I scoured the forums a bit and looked what users were telling. I wasn't surprised. What do you expect from a user telling it all doesn't work any more, who doesn't run etc-update just because after every emerge --upgrade --world it has over 100 files to update? Such user just ignores the importance of the tool, and will most certainly ignore anything else that we try to help this user. This was just one example. It is a very humble attempt to try and help these users, but they simply chose the wrong Linux distro, because Gentoo expects you to be an system administrator, not a user. At least that's my vision on it. I think we can agree that Gentoo requires a user to know/realise more than a Fedora/SuSe/Ubuntu user. I don't understand the problem from your point of view. No, scratch that. I don't understand your point of view. You're coming across to me as someone who doesn't believe there's a problem that needs solving. I am just in the opinion that we lack a system where users can find the information they need. That would help a certain type of users, absolutely not all of them. So yes, after that, this problem needs solving, perhaps. Personalisation using portage is a sweet thing! Here comes the point where I can express my doubt about the 100%. There are unfortunately users who are too hard to help, if you get what I mean. I'm tempted to forcibly co-opt you into the PHP team before we put dev-lang/php live. This would allow you to experience the situation for yourself. Maybe that would give you another perspective? ;-) Might be a very good excercise for me (and you?). As you might guess from my comment above, I simply think _communication_ is the big problem, as I see being a problem in many places around here. Not that perfect communication solves the problem entirely, but it allows to reply in the sense of 'rtfw'. If you're serious here, feel free to contact me (off-list) to see what we can arrange. [1] http://stu.gnqs.org/diary/gentoo.php/2005/11/10/feeling_blue -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On 10-11-2005 21:33:48 +, Stuart Herbert wrote: We need to establish *one* authoritative source of news. We can't do that if we simultaneously launch several sources of news all at once. We have to launch *one* service first, give the userbase time to adjust to that, and then start making the news available via additional sources. Yep, so create that central source on the web, and fork off mailing list posts, RSS-feeds and stuff based on this central repository. Also let portage warn users based on the information in this repository. We can start creating and populating the central web resource _right now_, as all the infrastructure is there. The mailing lists shouldn't be a problem as well. It all makes sense... ... as long as you include the right handles for users to adjust their preferences. You missed my point here, when I was just trying to indicate that in our user base, there will be many different users. Different users as in different preferences. Forcing the portage solution, the mailing list solution, or which other solution upon a user is evil. People should be *free* to choose. That you define a default setting of enabling the portage feature is fine with me, but include clear directions to disable such feature and allow it to send mails if the possible infrastructure is there and the user wants it. Take all preferences into account. I don't see why you would want to achieve your 100% user coverage aim through only *one* channel. I am strongly in favour of using multiple channels to do that. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Fri, 11 Nov 2005 10:19:15 +0100 Grobian [EMAIL PROTECTED] wrote: On 10-11-2005 21:33:48 +, Stuart Herbert wrote: We need to establish *one* authoritative source of news. We can't do that if we simultaneously launch several sources of news all at once. We have to launch *one* service first, give the userbase time to adjust to that, and then start making the news available via additional sources. Yep, so create that central source on the web, and fork off mailing list posts, RSS-feeds and stuff based on this central repository. Also let portage warn users based on the information in this repository. We can start creating and populating the central web resource _right now_, as all the infrastructure is there. The mailing lists shouldn't be a problem as well. It all makes sense... No, the central repository certainly shouldn't be on the web (whatever that means in the first place), it has to be somewhere in CVS (easily accessible by all devs, though not necessarily in a direct way) and should be replicated to as many channels as possible (the website being one of them). 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 Critical News Reporting Round Two
On 11-11-2005 10:38:43 +0100, Marius Mauch wrote: No, the central repository certainly shouldn't be on the web (whatever that means in the first place), it has to be somewhere in CVS (easily accessible by all devs, though not necessarily in a direct way) and should be replicated to as many channels as possible (the website being one of them). Agreed. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Ciaran McCreesh wrote: Next draft will propose being able to append .read to a filename to mark it read without deleting it. But don't use .read, as it can be understood as both present tense (imperative) and past tense. Better use something like .seen. Benno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 42 Critical News Reporting Round Two
On Fri, 2005-11-11 at 10:03 +0100, Grobian wrote: On 10-11-2005 20:55:37 +, Stuart Herbert wrote: I am just in the opinion that we lack a system where users can find the information they need. That would help a certain type of users, absolutely not all of them. So yes, after that, this problem needs solving, perhaps. Personalisation using portage is a sweet thing! Here comes the point where I can express my doubt about the 100%. There are unfortunately users who are too hard to help, if you get what I mean. I think putting the information in front of the users eyes is all that can be asked. If they choose to ignore it there is nothing that we can do. This proposal will accomplish that and at that point we can tell Ciaran Goob Job. Same for the config updates that you mentioned above. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- Tres Melton IRC Gentoo: RiverRat signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Friday 11 November 2005 00:35, Ciaran McCreesh wrote: On Thu, 10 Nov 2005 23:12:28 + Stuart Herbert [EMAIL PROTECTED] wrote: | Should the GLEP explain how Portage will know how many unread news | items there are in /var/lib/gentoo/news? I couldn't spot where this | is covered in the text, or in the example code. Well, I was going to go with the plain but simple once you've read it, delete it approach, but some people didn't like that. Next draft will propose being able to append .read to a filename to mark it read without deleting it. Either way, it's just a case of looking for -??-??-*.??.txt, chopping off the .??.txt, removing duplicates and counting. If you don't delete it, we might still have a supersedes header that indicates that one news item overrides another one. This would also be useful for a web version that contains a full archive of all news items. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpMdlY4d2CCQ.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 43: GLEP File Hosting
On Monday 07 November 2005 22:56, Ciaran McCreesh wrote: Ok, this is a change to the GLEP process, so it itself needs to be a GLEP... All it does is propose that GLEPs be allowed to stick example code in a subdirectory rather than having to inline things or shove them off on someone's devspace. Text version attached. An HTML version will be up on the main site whenever the web nodes next sync -- may be wise to read that instead if you aren't familiar with RST :: blocks. I see no objections to this. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpK0nIuLqunI.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Thu, 2005-11-10 at 21:33 +, Stuart Herbert wrote: My personal conclusion was that there is only one place where we can have any degree of certainty that we have the attention of 100% of the userbase - or as near as damn it. I believe that place is right beneath the message that tells the user they have CONFIG_PROTECTED files that need updating. I agree that portage should have some way of showing the number of news items. Hence emerge --news. Why? There's no emerge --etc or emerge --etc-update functionality. Why must it be emerge --news at all? I think this would completely remove the portage as a news reader problem entirely. Portage would check a directory for news items. The news reader would take care of them after this. Portage would do nothing more than look at the directory for unread news items and display that number. If you have found *one* place where we are even more likely to have the attention of 100% of the userbase, please share it with us. If there's a better place, we should use that instead, and I will very happily support it. I agree that we should have news delivered by emerge --sync. I also think that we should increase the placement of important information on our site, gentoo-announce, and the forums. It is my personal opinion that we should put the news out on as many mediums as possible. If we can put something together that takes the news available through emerge --news, and pushes it out via other places (web, mailing lists, whatever), I have no real problem with that. I think this should be a requirement. But I think that there is a very good reason why it needs to come later, why now is *not* the time. Ehh... We need to establish *one* authoritative source of news. We can't do that if we simultaneously launch several sources of news all at once. We have to launch *one* service first, give the userbase time to adjust to that, and then start making the news available via additional sources. No, we really don't. Our users aren't idiots. They just aren't reading the information presented to them. While I agree that we need to have a single location for news, I also think that we must *require* this information be present in other locations. The main reason for this is that emerge --news is filtered based on the packages installed on the system. What about administrators that have lots of different systems? To them, it might be easier to receive all of the news, via gentoo-announce, and filter them via their own methods to determine what is important to them. Perhaps I want to search for an old news item. Why shouldn't I be able to go to a web site and enter my query in a search box and get all of the major news updates to dev-lang/php? If you want to reach 100% of the user base, then we should make this useful for as many situations as possible. I know that with the number of machines that I administer, it would be much easier for me to get *all* of the news in one place and determine what is valid for my machines, rather than having to read them on each individual machine based on the packages installed. Don't worry I'll shut up now as there is clearly no interest for a bit broader thinking. I find your thinking anything but broad on this topic. *cough* Pot. This is kettle. *grin* -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Fri, 2005-11-11 at 04:52 +0100, Luca Barbato wrote: Ciaran McCreesh wrote: On Thu, 10 Nov 2005 16:07:37 -0800 Mike Owen [EMAIL PROTECTED] wrote: | What about something like /etc/portage/news.read, which contains a | single news file per line. Perhaps have support for something like | =2006-01-01 in order to be able to manually mark date ranges as | read. Eh, yet another file. No real need for it really, it just adds complexity. Besides, /etc isn't for program-generated data. Modify anything within PORTDIR is wrong. I'd put a /var/db/news and a /etc/portage/news to handle that. Which should be a reasonable timeframe for the news to stay? Until deleted. Till the next gentoo release? I'd prefer the news reader have both read and delete options. I also think we would need a searchable archive of all news items. I'd really prefer it was a web page, rather than trying to search a mailing list archive. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Fri, 2005-11-11 at 10:38 +0100, Marius Mauch wrote: On Fri, 11 Nov 2005 10:19:15 +0100 Grobian [EMAIL PROTECTED] wrote: On 10-11-2005 21:33:48 +, Stuart Herbert wrote: We need to establish *one* authoritative source of news. We can't do that if we simultaneously launch several sources of news all at once. We have to launch *one* service first, give the userbase time to adjust to that, and then start making the news available via additional sources. Yep, so create that central source on the web, and fork off mailing list posts, RSS-feeds and stuff based on this central repository. Also let portage warn users based on the information in this repository. We can start creating and populating the central web resource _right now_, as all the infrastructure is there. The mailing lists shouldn't be a problem as well. It all makes sense... No, the central repository certainly shouldn't be on the web (whatever that means in the first place), it has to be somewhere in CVS (easily accessible by all devs, though not necessarily in a direct way) and should be replicated to as many channels as possible (the website being one of them). How about gentoo/news in CVS? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, 5 Nov 2005 00:58:14 + Ciaran McCreesh [EMAIL PROTECTED] wrote: Feedback from people who have something useful to say would be very much welcomed, assuming of course that they've read the GLEP. Things that I think are generally ok as is: - news item format - news item distribution (server side) Things that I'd like to be changed/I'm not completely sure about: - filtering of news items: I've already asked a similar question in another mail (in other context) without an answer, but how many news items do people believe will exist at any given time? Depending on the actual implementation it might be required to scan all existing news items which could take some time if there is a large number of them (say, more than a few hundred) It's clear that noone can present accurate numbers, just after some rough estimates here. Also it might be useful for this filtering to be an external tool using portage functions and called by portage (see also below). Although this could be considered an implementation detail as it's mostly transparent for ebuild devs/users. - local storage of news items / read attribute: I don't really the like the copy-if-new feature and handling at the fs level, I'd use a file that lists the ids of news items (potentially with a timestamp and/or status field). I don't see any benefits of having redundancy here, and accessing the news in $PORTDIR is simple enough. Granted race conditions might be an issue (where the solution complicates tools), but that's so minor I wouldn't really care about it. Another thing that's unclear: Whenever relevant unread news items are found, emerge will copy or symlink the news file into /var/lib/gentoo/news/. This Whenever ... are found is too vague, should this apply to emerge --sync, any emerge operation, any import portage call or what? This isn't just an implementation detail. PS: I'd avoid symlinks here at all costs, too easy to break them. Also as Brian and Jason have said already, the system should be able to handle multiple repositories. So to use the current GLEP as example, at least the path should be changed to /var/lib/gentoo/news/porttree - quality control: Any complaints regarding wording or clarity must be addressed before the news item goes live. Playing devils advocate here, but complaints regarding correctness are not mandatory to be adressed? As for using -core, please add a small explanation or at least a reference to the appropriate policy docs (and please save the comments about GuideXML uris ;) Things that should definitely be changed: - Integration with existing systems: This definitely should be a requirement for the GLEP to be considered final. It doesn't prevent some thing being implemented sooner than others, but multi-channel distribution (to use a buzzword) is a requirement from where I come from. 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Fri, 11 Nov 2005 18:40:53 +0100 Marius Mauch [EMAIL PROTECTED] wrote: | I've already asked a similar question in another mail (in other | context) without an answer, but how many news items do people believe | will exist at any given time? Depending on the actual implementation | it might be required to scan all existing news items which could take | some time if there is a large number of them (say, more than a few | hundred) It's clear that noone can present accurate numbers, just | after some rough estimates here. I don't expect it to be of the order of a few hundred. AFAIK there aren't huge numbers of nasty upgrades... | Also it might be useful for this filtering to be an external tool | using portage functions and called by portage (see also below). | Although this could be considered an implementation detail as it's | mostly transparent for ebuild devs/users. Yeah, I have a script which does it already. It's just rather slow because of portageq. It'll be in the next draft. | - local storage of news items / read attribute: | I don't really the like the copy-if-new feature and handling at the | fs level, I'd use a file that lists the ids of news items (potentially | with a timestamp and/or status field). I don't see any benefits of | having redundancy here, and accessing the news in $PORTDIR is simple | enough. Granted race conditions might be an issue (where the solution | complicates tools), but that's so minor I wouldn't really care about | it. I'll have to think about that one... ID lists should be easy from an implementation perspective... | Another thing that's unclear: Whenever relevant unread news items are | found, emerge will copy or symlink the news file into | /var/lib/gentoo/news/. | This Whenever ... are found is too vague, should this apply to | emerge --sync, any emerge operation, any import portage call or | what? This isn't just an implementation detail. I'd say after emerge --sync, plus after an emerge --pretend and before an emerge blah. Will there be hooks for these? | PS: I'd avoid symlinks here at all costs, too easy to break them. Probably true, especially if portdir changes... | Also as Brian and Jason have said already, the system should be able | to handle multiple repositories. So to use the current GLEP as | example, at least the path should be changed | to /var/lib/gentoo/news/porttree Pfff, if that ever happens it's just a case of adding in another directory level. As it stands though, there's no multiple repo support in portage and no way to uniquely identify a repo, so I see no point in going out of the way to handle something which may or may not ever happen. | - quality control: | Any complaints regarding wording or clarity must be addressed before | the news item goes live. Playing devils advocate here, but complaints | regarding correctness are not mandatory to be adressed? Mmm, guess I should change that to Any complaints (including, without prejudice to the aforesaid generality, those of wording, clarity or correctness) must | As for using -core, please add a small explanation or at least a | reference to the appropriate policy docs I've moved the -core stuff to a .. Note:: for the next draft. | Things that should definitely be changed: | - Integration with existing systems: | This definitely should be a requirement for the GLEP to be considered | final. It doesn't prevent some thing being implemented sooner than | others, but multi-channel distribution (to use a buzzword) is a | requirement from where I come from. I'd really rather that news.gentoo.org / news2announceemail / whatever were handled via separate GLEPs. 42 is fairly long as it is... -- Ciaran McCreesh : Gentoo Developer (Look! Shiny things!) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Marius Mauch wrote: [Fri Nov 11 2005, 11:40:53AM CST] Things that I'd like to be changed/I'm not completely sure about: - filtering of news items: I've already asked a similar question in another mail (in other context) without an answer, but how many news items do people believe will exist at any given time? Depending on the actual implementation it might be required to scan all existing news items which could take some time if there is a large number of them (say, more than a few hundred) It's clear that noone can present accurate numbers, just after some rough estimates here. The GLEP sets the bar pretty high for what should be a significant news item, so my extremely rough guess is that 30/year would be on the quite high side. Ideally this system should extend, not supplant, the normal einfo/ewarn notices. (Um, what is the status of the einfo/ewarn message system that went into CVS. Any ETA on when it's going to be back-ported to current portage? I could see where there might be a tendency to abuse the news system if the messaging stuff is still unavailable.) Also it might be useful for this filtering to be an external tool using portage functions and called by portage (see also below). Although this could be considered an implementation detail as it's mostly transparent for ebuild devs/users. I'm not quite sure what you're saying here. - local storage of news items / read attribute: I don't really the like the copy-if-new feature and handling at the fs level, I'd use a file that lists the ids of news items (potentially with a timestamp and/or status field). I don't see any benefits of having redundancy here, and accessing the news in $PORTDIR is simple enough. Granted race conditions might be an issue (where the solution complicates tools), but that's so minor I wouldn't really care about it. My impression was that ciaranm was thinking of using something akin to a Maildir mailbox to hold and handle news items, because then one can leverage an insane amount of existing stuff. *Shrug* I also wouldn't object to a flat list of pointers to relevant files. Another thing that's unclear: Whenever relevant unread news items are found, emerge will copy or symlink the news file into /var/lib/gentoo/news/. This Whenever ... are found is too vague, should this apply to emerge --sync, any emerge operation, any import portage call or what? This isn't just an implementation detail. 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). -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpO9PSqeL1kS.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: GLEP 42 Critical News Reporting Round Two
On Fri, 2005-11-11 at 10:03 +0100, Grobian wrote: Ok, you want a reaction, because you are Feeling Blue[1], right. The only reaction I want is for us to meet the goals that I have set out, instead of trying to move those goals. You describe here (and in your diary) the aim to reach 100% of our user base. Wow, nice thing. Discussions on whether you will succeed or not, are out of the question right now, it's just your aim. Good. I hope you will succeed! Thanks. I scoured the forums a bit and looked what users were telling. I wasn't surprised. What do you expect from a user telling it all doesn't work any more, who doesn't run etc-update just because after every emerge --upgrade --world it has over 100 files to update? Such user just ignores the importance of the tool, and will most certainly ignore anything else that we try to help this user. This was just one example. When we have emerge --news done, and users come along and complain that they didn't know about something, then *maybe* we have some moral high ground to stand on. Personally, I don't care for the whole approach of moral high ground on this one. Gentoo's not just a cool toy. We're also responsible to delivering the best we can for our users. I'd like to think that includes the best news. It is a very humble attempt to try and help these users, but they simply chose the wrong Linux distro, because Gentoo expects you to be an system administrator, not a user. At least that's my vision on it. I think we can agree that Gentoo requires a user to know/realise more than a Fedora/SuSe/Ubuntu user. I agree that the required knowledge level is higher than certain other distros. But I don't think experience or ability is the issue. I don't believe that experience or ability has anything to do with whether or not that person keeps up to date with important Gentoo news. Even if a user keeps up with the news, there will be lapses due to sickness, holiday, pressure of other tasks, and so on. One of the nice benefits of emerge --news is that the news will be there for them when they need it. I am just in the opinion that we lack a system where users can find the information they need. Agreed, but there's no way that every user (or even a majority of users) will take the trouble to go looking for that information. I'm making that assertion partly on common-sense, and partly on my experience of running a F/OSS project back in the mid-nineties. I think this is where it'd help if Gentoo had some way of working out the install base, and comparing that to some meaningful stats from www.g.o et al, so that we could have a discussion based on facts that could stand up to scrutiny from both sides. However, we don't really have a way atm that I know about to get either of these stats. Maybe infra could do some rsyncd log analysis to put together a rough guestimate, and maybe the GDP could post some useful stats from www.g.o as I've twice asked for now. There again, maybe we don't really want those stats. Who knows - they might show that our userbase is nowhere near the size we think it is :) Here comes the point where I can express my doubt about the 100%. There are unfortunately users who are too hard to help, if you get what I mean. I agree. But at least we will have done our best, which I'd like to think is what having that nice @gentoo.org email address is all about. As you might guess from my comment above, I simply think _communication_ is the big problem, as I see being a problem in many places around here. I think that covers a multitude of sins though. I'm not trying to fix them all. I just want to fix this one problem at a time. The one I'm concerned with is ensuring that the news we already generate reaches all of our users. That's all I care about right now. I don't actually care whether it's done by emerge --news; I will happily support a more effective solution. Not that perfect communication solves the problem entirely, but it allows to reply in the sense of 'rtfw'. rtfn, surely? :) If you're serious here, feel free to contact me (off-list) to see what we can arrange. Drop into #gentoo-apache and let's talk :) Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Fri, 2005-11-11 at 18:40 +0100, Marius Mauch wrote: I've already asked a similar question in another mail (in other context) without an answer, but how many news items do people believe will exist at any given time? We won't know for certain until people start using it. I expect that it'll eventually be used for more than just the package-upgrade-will-break-your-box type news that we plan on using it for at first. For example, there's no real reason why GLSA's couldn't been delivered via this at some point (although I'd prefer a You have X amount of security fixes to apply type message adding to emerge, and treating GLSAs as a special case). Things that should definitely be changed: - Integration with existing systems: This definitely should be a requirement for the GLEP to be considered final. It doesn't prevent some thing being implemented sooner than others, but multi-channel distribution (to use a buzzword) is a requirement from where I come from. One of the key things with successfully delivering a change programme is to not dilute the change by introducing too many at once. If we simultaneously launch emerge --news w/ (f.ex) gatewaying to gentoo-announce, I believe that it weakens the impact of introducing emerge --news. One of the objectives is to remove confusion from the minds of users about where to find the news. If we can start by pointing at one place, and saying go there, we can clear up the confusion, and then afterwards introduce multi-channel distribution when our users get it, so to speak. I'm all for making the news available via www.g.o etc etc as well - I just think doing it all at the same time will not be the most effective strategy. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Fri, 11 Nov 2005 22:37:15 + Stuart Herbert [EMAIL PROTECTED] wrote: | For example, there's no real reason why GLSA's couldn't been delivered | via this at some point (although I'd prefer a You have X amount of | security fixes to apply type message adding to emerge, and treating | GLSAs as a special case). hh! We're not supposed to be mentioning that until the thing's up and running. -- Ciaran McCreesh : Gentoo Developer (Look! Shiny things!) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Fri, 2005-11-11 at 22:37 +, Stuart Herbert wrote: Things that should definitely be changed: - Integration with existing systems: This definitely should be a requirement for the GLEP to be considered final. It doesn't prevent some thing being implemented sooner than others, but multi-channel distribution (to use a buzzword) is a requirement from where I come from. One of the key things with successfully delivering a change programme is to not dilute the change by introducing too many at once. Umm... what? If we simultaneously launch emerge --news w/ (f.ex) gatewaying to gentoo-announce, I believe that it weakens the impact of introducing emerge --news. As I stated in my last email, emerge --news is not comprehensive enough of a system to be usable by everyone. The only solution to this is to introduce a system that delivers the same information across multiple mediums. How would I know about a new update to apache if I don't have it installed on my workstation, use a remote portage tree delivered via NFS to my servers, and don't use --pretend? I notice you didn't say anything about emerge --news being fatal in any way, so if I just type in emerge -u world on said server and then hit control+a d to detach from the screen, when exactly am I going to see that the recent apache update broke the config file format we had been using? Where can I search for news on a package that might not exist on my system? Where can I find archived news to find out why I made a change previously to my configurations? One of the objectives is to remove confusion from the minds of users about where to find the news. If we can start by pointing at one place, and saying go there, we can clear up the confusion, and then afterwards introduce multi-channel distribution when our users get it, so to speak. Wouldn't it be easy to say emerge --news, news.gentoo.org, the News forum, or gentoo-announce... take your pick than to say to the user that they must run an emerge --sync to get news delivered to their machine, and only news that is relevant to the packages installed on that exact system, making it useless for people that administer multiple machines? I'm all for making the news available via www.g.o etc etc as well - I just think doing it all at the same time will not be the most effective strategy. No offense intended by this, but I haven't seen anyone agreeing with you on this point. It seems to be your own quest to have the news *only* delivered by portage. By your own admission, you want to reach 100% of the users. The only effective way to do this is to essentially carpet bomb the information into several mediums, all containing the *same* information. Think about how advertising works. The idea is to put your product, the news, in our case, in front of as many eyes as possible. This is best done by utilizing all of the media available to us. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposed changes to base profile for Gentoo/ALT
On Wed, 2005-11-02 at 16:36 +, Mike Frysinger wrote: On Wed, Nov 02, 2005 at 11:12:43AM -0500, solar wrote: On Wed, 2005-11-02 at 14:38 +, Mike Frysinger wrote: On Wed, Nov 02, 2005 at 01:11:24PM +0100, Diego 'Flameeyes' Petten? wrote: Obviously if this is going to be applied the missing packages should be added to the packages of default-linux and other linux profiles that does inherit from base. linux-based profiles should inherit default-linux rather than base anyways ... Thats a lot easier said than done and I'd rather us not inherit from default-linux for the uclibc i dont think it'd be a problem for use with uclibc ... we'd just need to drop pwdb and hdparm from our packages ... btw, why is pwdb in our system ? `scanelf -lpq -N libpwdb.so.0` on my system shows no hits ... is it a pam thing ? I am fairly sure that its legacy from the days we used pam_pwdb as main auth, so we can remove it. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
[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] GLEP 42 Critical News Reporting Round Two
On Fri, 2005-11-11 at 18:22 -0500, Chris Gianelloni wrote: It seems to be your own quest to have the news *only* delivered by portage. 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. I've managed a few change programmes over the years, and I've had the most success when a change happened in stages. The issues centre on the ability of a large body of people to understand the change that has been introduced. People find change itself confusing. If something isn't given time to bed in, people never quite understand the original change, and this undermines the benefits of introducing the change. We live and breathe Gentoo daily, and we understand this news thing because we've invested time and effort to kick it back and forward here on -dev. The vast majority of our users haven't had that luxury, and it'll take a while for them to get it. If the majority don't agree with me, not a problem; I'm not going to stop you (like I could anyway!) from putting out multi-channel from day one. But if it was my decision, I'd roll out one channel first, and the others later. By your own admission, you want to reach 100% of the users. The only effective way to do this is to essentially carpet bomb the information into several mediums, all containing the *same* information. Think about how advertising works. The idea is to put your product, the news, in our case, in front of as many eyes as possible. This is best done by utilizing all of the media available to us. That's not my experience of how advertising works. My experience with advertising is that you place your product, service, or message where your target audience is most likely to see it and be affected by it. Most bang for your buck, if you like. The placement creates the context for the advert. Most advertising carries what the marketdroids term a call to action - something that tells the reader how to buy the product, or whatever. Some advertising is about raising general brand awareness (something Orange was exceptional at), so that the reader will think of the firm and its products at a point in the future. Carpet-bombing, by comparison, goes against commonly observed human psychology. If you tell people the same thing too many times, they stop listening to you. Blitzing people just leaves them too shocked to absorb the message. But if you introduce something gradually, you can then turn up the volume, so to speak, without people being unsettled by it. There's two great stories in R. V. Jones Most Secret War where Dr. Jones used this principle to play practical jokes on people he knew during his Oxford days, for example. 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). I'm not hoping for a 100% perfect technical solution straight away. Release early, release often is the F/OSS way. Once we've agreed on something that's fit for purpose, let's implement it, deploy it, get to the tipping point, see how users react, and then improve it. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo Council meeting Tuesday, November 15th, 20:00 UTC
On Tue, 2005-11-08 at 17:30 +0100, Thierry Carrez wrote: The November Gentoo Council meeting will be held on #gentoo-council next week, Tuesday, November 15th, 20:00 UTC, presided by Seemant Kulleen. The deadline for submitting items for the meeting agenda is set to Sunday, November 13th, 20:00 UTC. Just want to be sure that GLEP41 is on the list. -- Homer Parker Gentoo/AMD64 Team Gentoo/AMD64 Arch Tester Strategic Lead Gentoo Linux Developer Relations [EMAIL PROTECTED] -- 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] Unmasking dev-python/setuptools 0.6_alpha5?
Anyone know how safe/unsafe dev-python/setuptools-0.6_alpha5 is? I am building an ebuild for Turbogears and a current version of setuptools is required. -- Edward Muller - Interlix [EMAIL PROTECTED] 417-862-0573 PGP Key: http://interlix.com/Members/edwardam/pgpkeys pgpGga3qTD25q.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: GLEP 42 Critical News Reporting Round Two
On Saturday 12 November 2005 07:19, Stuart Herbert wrote: When we have emerge --news done, I keep seeing references to emerge --news but at the same time am seeing that news readers are external. What exactly is `emerge --news` meant to do? Print out You've got news!? Manage some external database? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Bug Wrangling Event?
Hi all, Now that my job situation has settled down, I have some free time floating around, and a bit of finances to cover it. That said, I'd like to see if there would be interest in a bug wrangling event of some sort taking place in the SF area. If I get enough interest, I'll go ahead and call places and get the event setup. Here's what my plan was: 1) Bug Wrangling 2) Helping people with writing ebuilds 3) Installation 4) General questions about Gentoo I'd like to have other developers besides myself there, and I don't know if it will be a one or two day event, but that I won't know unless I get interest ;). Let me know what you all think and I'll go from there. PLEASE REPLY OFF LIST Thanks :) Chris White pgpmrTgrCSTBL.pgp Description: PGP signature
[gentoo-dev] Re: Re: GLEP 42 Critical News Reporting Round Two
Georgi Georgiev posted [EMAIL PROTECTED], excerpted below, on Sat, 12 Nov 2005 11:27:47 +0900: 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. Good point! -- 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-portage-dev] going to need a 2.0.53-rc8
Hola, Short version is that via bug 112082 plus glibc upstream doing something stupid, a lovely bug has reared it's head. Basically, users upgrading from glibc-2.3.5.200*.ebuild have libc.so-2.3.90.so, and glibc-2.3.6.ebuild has libc.so-2.3.6.so . ldconfig views 2.3.90 as greater then 2.3.6; during merge, portage views 2.3.5.200* - 2.3.6 as an upgrade, and triggers an ldconfig call. Said call, and said upstream weird lib versioning results in ld.so.6 being reset from libc-2.3.6.so to libc-2.3.90.so , which obviously gets a bit screwed up when unmerge comes around and yanks the lib. Az split off a patch for it (after lots of fun digging) to correct it; we're going to need a rc8 covering this one offhand, since it's invalid linking in certain cases. Thoughts/complaints/issues/further testing? ~harring pgpvktNhMeOtF.pgp Description: PGP signature
Re: [gentoo-portage-dev] going to need a 2.0.53-rc8
On Friday 11 November 2005 22:53, Brian Harring wrote: Hola, Short version is that via bug 112082 plus glibc upstream doing something stupid, a lovely bug has reared it's head. Basically, users upgrading from glibc-2.3.5.200*.ebuild have libc.so-2.3.90.so, and glibc-2.3.6.ebuild has libc.so-2.3.6.so . ldconfig views 2.3.90 as greater then 2.3.6; during merge, portage views 2.3.5.200* - 2.3.6 as an upgrade, and triggers an ldconfig call. Said call, and said upstream weird lib versioning results in ld.so.6 being reset from libc-2.3.6.so to libc-2.3.90.so , which obviously gets a bit screwed up when unmerge comes around and yanks the lib. Az split off a patch for it (after lots of fun digging) to correct it; we're going to need a rc8 covering this one offhand, since it's invalid linking in certain cases. Thoughts/complaints/issues/further testing? Short answer: No. Long answer: This is not a regression; you'll find the same problem in stable. It's an area where a slight error can break lots of things that are even slightly non-standard. This case where the bug is occurring is very non-standard and has not cropped up before (or at least hasn't been brought to anybody's attention) in the time since I (and you) have been with the project. Lastly, 2.3.5.200* is/was hard masked. My preference would be to put the patch into trunk and release .54_pre1 within the next 24 hours. -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
