Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
Stuart Herbert wrote: 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. 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 would just do it the other way around: do your experiment after the traditional channels are set up, and let your experiment rely on the solid base those traditional solutions give. 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. You are probably right here. So why not doing the obvious steps? Just activate now the traditional ways of getting news to the users. In the mean-time you work on getting GLEP42 implemented and accepted, and by the time it more or less works, you have a wonderful base to announce this new feature on, and sell it as "personalised sophisticated news delivery". 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". 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". 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. See above why I think that is just the wrong order, though I support your 'phased' roll out. 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. 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 with it was very bad. You'd lose a few bits of your 100% making it impossible to reach your own goal. I would seriously test this (hence not release early), if you happen to make an error and deliver all news messages at once to the user, you might end up in having the same as that very user that ignored etc-update because it had so much items to update. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking dev-python/setuptools 0.6_alpha5?
On Fri, Nov 11, 2005 at 10:01:33PM -0600, Edward Muller wrote: > 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. Just in case you haven't seen it, you should take a look at http://eggs.gentooexperimental.org/ I have also tried making an ebuild for Turbogears and it is a really tough job without a nice way to handle eggs, so you should probably grab eggs.eclass and use that. -- Anders -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y? --END GEEK CODE BLOCK-- PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0 -- 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,
[gentoo-dev] Plugin framework
I've had a go at creating a generic plugin framework for portage. The attached
patch contains:
* plugins/__init__.py that does plugin searching and loading.
* plugins/cache/__init__.py which specifies what class cache plugins must
derive from.
* cache/{anydbm,flat_hash,flat_list,metadata,sqlite}.py copied to
plugins/cache/ with imports adjusted and classes renamed to match their
filenames.
* portage.py edits to the config class to make use of the framework.
Essentially, plugins.registry gives dict access to modules under plugins/. To
give an example, the plugins.cache.anydbm.anydbm class can be accessed via
plugins.repository["cache"]["anydbm"].
In loading, I'm iterating through sys.path and chopping that out from the
detected module's path. I didn't need to do this when I was first testing the
module loader, however. After integrating it with portage I was getting
"module not found" errors. If anybody knows why that is, I'll get rid of that
iteration. To be clear, the following doesn't work only when running from
portage (regardless of the path used):
python -c '__import__("/usr/lib/portage/pym/cache")'
diff -uNr portage-orig/pym/plugins/__init__.py portage-plugin-framework/pym/plugins/__init__.py
--- portage-orig/pym/plugins/__init__.py 1970-01-01 09:00:00.0 +0900
+++ portage-plugin-framework/pym/plugins/__init__.py 2005-11-12 21:52:15.0 +0900
@@ -0,0 +1,80 @@
+class registry:
+
+ class _plugin_loader:
+
+ def __init__(self, path):
+ try:
+import sys
+for prefix in sys.path:
+ if path.startswith(prefix):
+ mod_name = path[len(prefix)+1:]
+ self._plugin = __import__(mod_name)
+ getattr(self._plugin, "plugin_class")
+ break
+ except (ImportError, AttributeError), e:
+raise ImportError
+ self._path = path
+ self._loaded = {}
+
+ def __getitem__(self, name):
+ if name in self._loaded:
+return self._loaded[name]
+ try:
+import os
+plugin_path = os.path.join(self._path, name)
+import sys
+for prefix in sys.path:
+ if plugin_path.startswith(prefix):
+ plugin_name = plugin_path[len(prefix)+1:]
+ plugin = __import__(plugin_name)
+ break
+plugin = getattr(plugin, name)
+if issubclass(plugin, self._plugin.plugin_class):
+ self._loaded[name] = plugin
+ return plugin
+ except (ImportError, AttributeError), e:
+pass
+ raise KeyError(name)
+
+ def keys(self):
+ import os
+ for name in os.listdir(self._path):
+(name, ext) = os.path.splitext(name)
+if name.startswith("_") or not ext.startswith(".py"):
+ continue
+if name not in self._loaded:
+ try:
+ self[name]
+ except KeyError:
+ pass
+ keys = self._loaded.keys()
+ keys.sort()
+ return keys
+
+ def __init__(self):
+ import os
+ self._path = os.path.dirname(__file__)
+ self._loaded = {}
+
+ def __getitem__(self, name):
+ if name not in self._loaded:
+ try:
+import os
+self._loaded[name] = self._plugin_loader(os.path.join(self._path, name))
+ except ImportError, e:
+raise KeyError, name
+ return self._loaded[name]
+
+ def keys(self):
+ import os
+ for name in os.listdir(self._path):
+ if name not in self._loaded:
+try:
+ self[name]
+except KeyError:
+ pass
+ keys = self._loaded.keys()
+ keys.sort()
+ return keys
+
+registry = registry()
diff -uNr portage-orig/pym/plugins/cache/__init__.py portage-plugin-framework/pym/plugins/cache/__init__.py
--- portage-orig/pym/plugins/cache/__init__.py 1970-01-01 09:00:00.0 +0900
+++ portage-plugin-framework/pym/plugins/cache/__init__.py 2005-11-12 21:52:15.0 +0900
@@ -0,0 +1 @@
+from cache.template import database as plugin_class
diff -uNr portage-orig/pym/plugins/cache/anydbm.py portage-plugin-framework/pym/plugins/cache/anydbm.py
--- portage-orig/pym/plugins/cache/anydbm.py 1970-01-01 09:00:00.0 +0900
+++ portage-plugin-framework/pym/plugins/cache/anydbm.py 2005-11-12 21:52:15.0 +0900
@@ -0,0 +1,75 @@
+# Copyright: 2005 Gentoo Foundation
+# Author(s): Brian Harring ([EMAIL PROTECTED])
+# License: GPL2
+# $Id: anydbm.py 1911 2005-08-25 03:44:21Z ferringb $
+
+anydbm_module = __import__("anydbm")
+try:
+ import cPickle as pickle
+except ImportError:
+ import pickle
+import os
+from cache import fs_template
+from cache import cache_errors
+
+
+class anydbm(fs_template.FsBased):
+
+ autocommits = True
+ cleanse_keys = True
+
+ def __init__(self, *args, **config):
+ super(anydbm,self).__init__(*args, **config)
+
+ default_db = config.get("dbtype","anydbm")
+ if not default_db.startswith("."):
+ default_db = '.' + default_db
+
+ self._db_path = os.path.join(self.location, fs_template.gen_label(self.location, self.label)+default_db)
+ self.__db = None
+ try:
+ self.__db = anydbm_module.open(self._db_path, "w", self._perms)
+
+ except anydbm_module.error:
+ # XXX handle this at some point
+ try:
+self._ensure_dirs()
+self._ensure_dirs(self._db_path)
+
Re: [gentoo-dev] Plugin framework
On Saturday 12 November 2005 22:11, Jason Stubbs wrote: > I've had a go at creating a generic plugin framework for portage. The > attached patch contains: Gah! Apologies again. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
On Sat, 2005-11-12 at 00:57 +, Stuart Herbert wrote: > 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 aren't talking about something that is completely foreign to people. They already have a notice about files in /etc and already know to do what portage tells them. How exactly would having a web page that the user doesn't even know exists yet confuse them when they see the "You have 5 unread news messages. Please use: "enews read all" to view them."? Remember that we're talking about the same users that currently have no idea where to go to get news. They aren't going to suddenly subscribe to gentoo-announce or check out news.gentoo.org on a whim and get confused. > 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". Ehh... I also take that most of our users are not idiots. If they see a message from emerge *in a place that isn't hidden in compiler text* then they will pay attention to it. I know that if I were to suddenly run "up2date -u" on a system and it told me that I should run "rpm --rebuildb" due to a change in RPM's database format at the end of it, I would do so, whether I was aware that Red Hat had posted this information on errata.redhat.com or not. > 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. This only happens in cases of limited financial backing. If you control the mediums on which you are advertising, you would do it differently. Especially if you are not selling any ads to anyone else. > 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). 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 t
Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two
On Sat, 2005-11-12 at 13:39 +0900, Jason Stubbs wrote: > 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? It is my opinion that the news reading application need not be integrated into portage. As far as I have understood it, the only real thing that anyone has required portage itself to do is to *automatically* spit out "You have $n unread news messages. Please use $bleh to read them" at certain times (after sync, after --pretend, before/after a merge). I don't see this as being something very complex. I would assume that some extra code would need to be written into the sync code somewhere to sort the messages. I wouldn't mind seeing something along the lines of /var/db/news directory (or something repo specific, whatever) that has a pretty simple format... -mm-dd-$blah-$lang.txt.unread -mm-dd-$blah-$lang.txt.read When you delete a message, it is gone. This means an external news reader (enews anyone?) that basically has the capability to read, skip, or delete these news items. I think this would be pretty simple to get done and covers the problem of messages being read or unread. Of course, this is all just an idea, so feel free to blow holes all in it. ;] -- 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] 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,
Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two
On Sunday 13 November 2005 00:34, Chris Gianelloni wrote: > On Sat, 2005-11-12 at 13:39 +0900, Jason Stubbs wrote: > > 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? > > It is my opinion that the news reading application need not be > integrated into portage. As far as I have understood it, the only real > thing that anyone has required portage itself to do is to > *automatically* spit out "You have $n unread news messages. Please use > $bleh to read them" at certain times (after sync, after --pretend, > before/after a merge). I don't see this as being something very > complex. I would assume that some extra code would need to be written > into the sync code somewhere to sort the messages. This, I get. What I'm wondering about is the `emerge --news` that is referred to every so often. > I wouldn't mind seeing something along the lines of /var/db/news > directory (or something repo specific, whatever) that has a pretty > simple format... > > -mm-dd-$blah-$lang.txt.unread > -mm-dd-$blah-$lang.txt.read > > When you delete a message, it is gone. This means an external news > reader (enews anyone?) that basically has the capability to read, skip, > or delete these news items. > > I think this would be pretty simple to get done and covers the problem > of messages being read or unread. Of course, this is all just an idea, > so feel free to blow holes all in it. ;] To be honest, this is the part that I don't like the most. Integrating code into portage to copy files here and there based on some predefined rules and news readers reading and renaming files based on some predefined rules... A filesystem based API just doesn't seem very robust to change. I'd prefer that either the post-sync handling code is not integrated into portage and portage just triggers some external script - or - portage exposes an API (via python and bash) for accessing and updating news items. I'd prefer the latter but I get the impression that most prefer the former. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Fwd: Re: Fwd: [gentoo-dev] Thesis on open source
Hi, Thanks to all of you who participated in the survey on open source. Those who didnt still can. It is now available online at: http://www.surveyconsole.com/console/TakeSurvey?id=136086 Thanks in advance! Hania Sabbidin - Forwarded message from Hania Sabbidin <[EMAIL PROTECTED]> - Date: Sun, 16 Oct 2005 22:18:03 +0300 From: Hania Sabbidin <[EMAIL PROTECTED]> Reply-To: Hania Sabbidin <[EMAIL PROTECTED]> Subject: Re: Fwd: [gentoo-dev] Thesis on open source To: "gentoo-dev@lists.gentoo.org" Hello, I am a student at the American University of Beirut (AUB) currently working for a Masters degree in Engineering Management. I am in the process of conducting research work on organizational aspects of the free/open source software development process. Accordingly, Ive devised a survey to which I am inviting a number of online software developers to fill out. I would thus very much appreciate your help in filling out the survey, attached herein. If you believe other developers may be willing to fill it out, kindly send them this message. If you have any comments or feedback on the content or style of survey, or if you believe you can provide other information that may be useful for my thesis, please feel free to contact me. Thank you in advance, Hania Sabbidin Engineering Management Programme American University of Beirut -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two
Chris Gianelloni wrote: On Thu, 2005-11-10 at 21:33 +, Stuart Herbert wrote: Hence emerge --news. Why? There's no "emerge --etc" or "emerge --etc-update" functionality. Why must it be "emerge --news" at all? # emerge --help config probably an emerge --help news that explains the basics of the news system and points the user to the default reader (whatever that becomes) or even just tells them where to find the news files to read in their editor of choice would be helpful. 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! The other channels to deliver news to users are already in place. Make them *all* the one authoritative source of news. If your goal is 100% coverage, then why proceed without a fallback? 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. Seconded. ;) --de. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two
Jason Stubbs wrote: To be honest, this is the part that I don't like the most. Integrating code into portage to copy files here and there based on some predefined rules and news readers reading and renaming files based on some predefined rules... A filesystem based API just doesn't seem very robust to change. I'd prefer that either the post-sync handling code is not integrated into portage and portage just triggers some external script - or - portage exposes an API (via python and bash) for accessing and updating news items. I'd prefer the latter but I get the impression that most prefer the former. - append message to /var/spool/mail/portage alternative 1 (very very sober install): - less /var/spool/mail/portage - rm /var/spool/mail/portage alternative 2 (sober install): - vi /var/spool/mail/portage alternative 3 (for those having `mail`, `mutt` or whatever that reads mbox) - mail -u portage (program allows deletion) alternative 4 (those that don't like mbox reading) - either run mbox2mail or - allow portage to write to a pipe to `mail` instead of append to /var/spool/mail/portage (would be the best solution IMHO) It doesn't have to be so complicated, IMHO. Most of the tools are already there, because traditional unix systems had this notification system built in. Imagine how nice you could benefit from a shell that tells you you've got (new) mail if you log in as root. Appending in the right format to /var/spool/mail/portage doesn't need an MTA either. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
[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
