Re: [gentoo-dev] Re: GLEP 42?
On 10/11/06, Stephen Bennett [EMAIL PROTECTED] wrote: We also use space-delimited depend atoms everywhere else. It makes no sense to break that when a comma works equally well. I'm sorry, are you telling everyone that it's too difficult for you to write an ungreedy regex that also tests for the possibility of a list bounded by [ and ] being part of an atom? Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42?
On 10/11/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: Not an issue for me. It's an issue for random people writing scripts, for people using command line things and for people who don't want to use a full parser framework for some quick hack. There's no need to make things harder for random developers here. Wouldn't a resolver API be the better approach to solving that? We're not here to support x-random number of independent, unofficial implementations of atom parsers. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42?
On Thu, 12 Oct 2006 09:52:42 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: I'm sorry, are you telling everyone that it's too difficult for you to write an ungreedy regex that also tests for the possibility of a list bounded by [ and ] being part of an atom? No. I'm saying that it's more effort than simply tokenising by spaces, and that there's absolutely no benefit in making anyone expend that effort. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42?
On Wed, 2006-10-11 at 22:17 +0100, Ciaran McCreesh wrote: On Wed, 11 Oct 2006 22:08:31 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | On 10/11/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: | Spaces in dep atoms would be highly evil, since it'd mean they were | no longer simply space delimited. Commas [foo,-bar,baz] would be | fine... | | Write a better parser then :P Not an issue for me. It's an issue for random people writing scripts, for people using command line things and for people who don't want to use a full parser framework for some quick hack. There's no need to make things harder for random developers here. I tried to write some scripts some time ago and it was completely horrible. I wish more people would have been thinking like Ciaran earlier. btw.. I keep hearing about this paladius. Is it more script-friendly than emerge? -- Natanael Copa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42?
Brian Harring wrote: cat/pkg[use1_on,-use2_off,-use3_on] You mean use3_on, without the minus sign, right? Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: GLEP 42?
On Thu, 12 Oct 2006 10:00:05 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | On 10/11/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: | Not an issue for me. It's an issue for random people writing | scripts, for people using command line things and for people who | don't want to use a full parser framework for some quick hack. | There's no need to make things harder for random developers here. | | Wouldn't a resolver API be the better approach to solving that? Depends upon the task. There's no point forcing people to use a huge API for everything just because someone wants to use spaces rather than commas. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42?
On Thu, 12 Oct 2006 14:24:36 +0200 Natanael Copa [EMAIL PROTECTED] wrote: | btw.. I keep hearing about this paladius. Is it more script-friendly | than emerge? Once we get the Ruby interface fleshed out it will be... -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42?
On Thu, 12 Oct 2006 09:52:42 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | On 10/11/06, Stephen Bennett [EMAIL PROTECTED] wrote: | We also use space-delimited depend atoms everywhere else. It makes | no sense to break that when a comma works equally well. | | I'm sorry, are you telling everyone that it's too difficult for you to | write an ungreedy regex that also tests for the possibility of a list | bounded by [ and ] being part of an atom? We are not talking about us. We have access to a full parser that could very easily be told to handle spaces, backspaces, tabs and anything else you'd care to use. It can even go beyond the single lookahead element that's required here. No. We're talking about other developers and users who just want to do a quick script without having to care about all that. You know, not making design decisions that have no affect on the top 1% but that screw over significant parts of the remainder just for the sake of using a space over a comma. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42?
Natanael Copa wrote: btw.. I keep hearing about this paladius. Is it more script-friendly than emerge? It's paludis, and no, the API is currently C++ only, afaik. There are ruby bindings in the works, though. The other alternative, pkgcore, has a python API...as does portage itself. None of the options have an interface that's usable via a bash script. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42?
On Thu, 12 Oct 2006 11:03:41 -0500 Andrew Gaffney [EMAIL PROTECTED] wrote: It's paludis, and no, the API is currently C++ only, afaik. There are ruby bindings in the works, though. The other alternative, pkgcore, has a python API...as does portage itself. None of the options have an interface that's usable via a bash script. Paludis also has python bindings in the works. And the regular paludis command-line is usable via bash scripts, though for obvious reasons not as flexible as the other languages would be. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42?
On Wed, 11 Oct 2006, Ciaran McCreesh wrote:
On Wed, 11 Oct 2006 15:30:03 -0400 Chris Gianelloni
[EMAIL PROTECTED] wrote:
| On Wed, 2006-10-11 at 19:44 +0100, Ciaran McCreesh wrote:
| On Wed, 11 Oct 2006 13:36:16 -0500 Brian Jackson [EMAIL PROTECTED]
| wrote:
| | ${CATEGORY}/${PN}:${SLOT}.
| |
| | I thought we were eventually going to use that format to specify
| | deps with specific USE set.
|
| That's [use].
|
| I assume it is really [list of use] right?
I think cat/pkg:slot[foo][-bar][baz] or opcat/pkg-ver:slot[foo][-bar]
was what was decided upon. That's how paludis does it, but it's easy
enough to tweak if people prefer something else...
What's the point of all the square brackets? Is there some benefit over
just [foo -bar baz]?
Michael Sterrett
-Mr. Bones.-
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42?
On Wed, Oct 11, 2006 at 03:52:08PM -0400, Michael Sterrett -Mr. Bones.- wrote:
On Wed, 11 Oct 2006, Ciaran McCreesh wrote:
On Wed, 11 Oct 2006 15:30:03 -0400 Chris Gianelloni
[EMAIL PROTECTED] wrote:
| On Wed, 2006-10-11 at 19:44 +0100, Ciaran McCreesh wrote:
| On Wed, 11 Oct 2006 13:36:16 -0500 Brian Jackson [EMAIL PROTECTED]
| wrote:
| | ${CATEGORY}/${PN}:${SLOT}.
| |
| | I thought we were eventually going to use that format to specify
| | deps with specific USE set.
|
| That's [use].
|
| I assume it is really [list of use] right?
I think cat/pkg:slot[foo][-bar][baz] or opcat/pkg-ver:slot[foo][-bar]
was what was decided upon. That's how paludis does it, but it's easy
enough to tweak if people prefer something else...
What's the point of all the square brackets? Is there some benefit over
just [foo -bar baz]?
Been awhile, but the original syntax being pushed was
cat/pkg:slot1,slot2
cat/pkg[use1_on,-use2_off,-use3_on]
Somewhat prefer the spaces in use rather then commas personally also,
but implemented the syntax I recalled.
~harring
pgpd1lNRcLWeM.pgp
Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42?
On Wed, 11 Oct 2006 15:52:08 -0400 (EDT) Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] wrote: | What's the point of all the square brackets? Is there some benefit | over just [foo -bar baz]? Spaces in dep atoms would be highly evil, since it'd mean they were no longer simply space delimited. Commas [foo,-bar,baz] would be fine... -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42?
On 10/11/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: Spaces in dep atoms would be highly evil, since it'd mean they were no longer simply space delimited. Commas [foo,-bar,baz] would be fine... Write a better parser then :P We use space-delimited USE flags everywhere else. It would make a lot of sense to keep it consistent here. Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42?
On Wed, 11 Oct 2006 22:08:31 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | On 10/11/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: | Spaces in dep atoms would be highly evil, since it'd mean they were | no longer simply space delimited. Commas [foo,-bar,baz] would be | fine... | | Write a better parser then :P Not an issue for me. It's an issue for random people writing scripts, for people using command line things and for people who don't want to use a full parser framework for some quick hack. There's no need to make things harder for random developers here. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42?
On Wed, 11 Oct 2006 22:08:31 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: We use space-delimited USE flags everywhere else. It would make a lot of sense to keep it consistent here. We also use space-delimited depend atoms everywhere else. It makes no sense to break that when a comma works equally well. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (news) Round Seven
Jan Kundrát posted [EMAIL PROTECTED], excerpted below, on Fri, 06 Jan 2006 17:10:52 +0100: Ciaran McCreesh wrote: * Removed --ask message, apparently it's superfluous. Why? I haven't found any conclusion about that in the last thread. It doesn't make sense to show the message in both `emerge -p foo` and `emerge foo`, but not in `emerge -a foo`, IMHO. My thinking too, until I saw the portage dev (JStubbs?) mention it wasn't needed. I believe the thinking is that emerge --ask is basically emerge --pretend with an opportunity to continue stuck on the end, thus eliminating running the same command only without the --pretend again, therefore eliminating running portage's dep calculation step twice, once for the pretend, then again for the run. Looked at this way, -a automatically gets the same treatment as -p. Actually, -a might spit out the unread news warning twice, once as part of the pretend output, then again as part of the regular emerge once the user has said to continue. In any case, it should spit it out in at least the first instance, just as --pretend would. So, yes, it was mentioned in (one of) the previous threads. It was only a small mention, however, so you might have missed it. I might have myself, had I not commented on -a functionality myself earlier, and was therefore watching for discussion of that aspect in particular. -- 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 (news) Round Seven
Duncan wrote: My thinking too, until I saw the portage dev (JStubbs?) mention it wasn't needed. I believe the thinking is that emerge --ask is basically emerge --pretend with an opportunity to continue stuck on the end, thus eliminating running the same command only without the --pretend again, therefore eliminating running portage's dep calculation step twice, once for the pretend, then again for the run. Okay, but I'd say that Portage internals like if the the same code gets used by --ask and --pretend are not relevant for this GLEP. Why don't add a note specifying the correct behavior? Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wed, Dec 14, 2005 at 09:54:06PM +, Ciaran McCreesh wrote: On Wed, 14 Dec 2005 13:48:45 -0800 Zac Medico [EMAIL PROTECTED] wrote: | I wish you'd reconsider, because I was looking forward to multiple | repository support. Well, if Portage ever gets multiple repository support, then news clients can be updated to handle it. The GLEP says that already. Care to clarify how that transition is going to occur? Your proposal, if you know a roadblock is coming down the line I expect it to be documented in the glep (with potential suggestions how to minimize the horkage). If you're not going to do N repo, state so in the glep, state that it _will_ break down the line, and that the issue while known, are being ignored despite portage developers concerns. Only fair the council knows the exact details, that and it made clear that this was known when proposed and ignored. If you're going to create and dump a mess on us, I expect it to be in the proposal- especially since your proposal is intrinsically portage bound. Thing that's daft out of all of this time wasting is that what's being asked of you is a couple of portageq calls so that we're not screwed over by a feature. Something along the lines of... portageq get_repo_id path # helper method of getting repo_id for a path (dar) portageq match root atom [repo-id] # method of limiting matching of vdb to a specific source repo portageq newsdir repo_id # get the absolute news path for said id. Integration for that is pretty damn simple from our side of things, and you get the major blocker of your news glep resolved (meaning it has a chance of actually passing). If it's too slow, I'd suggest since it's your proposal, looking for a method to batch up the calls (modularization of portageq would be required, which is available in the dead ebd branch already). Tricks of that sort are easily implemented, and don't require specs and gleps (just requires someone to do a minor bit of work). ~harring pgpQEwhHt8ZlE.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Sun, Dec 18, 2005 at 01:07:27AM +, Ciaran McCreesh wrote: On Sat, 17 Dec 2005 16:51:05 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Transitioning from single news.unread to N is going to break clients | that expect a single. Yup. | As I said, you're going to break stuff- and you're building it into | your glep out of (aparent) stubborness. No no. I'm just not adding something ill defined and arbitrary to the GLEP to avoid introducing minor possible breakage when some ill defined and arbitrary change is made to Portage. Well, since we're toeing the line, I'll just state your glep is ill defined and arbitrary, it is inflexible and incomplete due to the fact it doesn't take into consideration the existing solutions (namely overlays). Back off the technical double speak insults unless you want others people to get nastier then they are already. | What do you want, another glep amending yours with that one little | detail? Probably won't be necessary... If you're unwilling to make your 'flexible' proposal actually flexible for anything but your stuff (eselect), either the glep is going to be fought tooth and nail or a competing glep is going to come out of this. Bluntly, stop being a tool, users want this feature, stop using it as fodder to fight. | The news glep crosses several groups, collaboration here is required, | meaning *listen* to the folk you're trying to command. Otherwise the | glep *will* go nowhere no matter how much noise you make. And I'm asking you to provide me with a specification of how multiple repositories will work. Without that, there's no way the GLEP can be made to handle multiple repositories. We have overlays already. That *is* multiple repositories. Stop trying to dodge the request by making us waste our time and produce a stand alone repository glep- overlays exist *now*, thus you *do* need to address them *now* else your glep is incomplete. | | If you're going to create and dump a mess on us, I expect it to | | be in the proposal- especially since your proposal is | | intrinsically portage bound. | | There's very little that's Portage bound. As originally requested, | I've tried to keep as much as is reasonably possible *out* of | Portage... | | It's distributed via the portage tree, it's updated by portage, the | check for new news items is *via* portage, and check for news items | prior to merging is done by portage. | | If that truly was your intention, you failed in it.. It's bound to | portage, despite the rhetoric. No no. A Portage bound solution would stick all the code and clients in Portage proper, rather than using Portage merely for hooks as far as is reasonably possible. Word games... You're dodging my point. | Word games suck, instead of playing them you *should* be trying to | address the concerns- iow, what do you *explicitly* need from | portage, What explicitly I need, *if* the GLEP is to specify multiple repository support from the outset, is a specification of how Portage will handle multiple repositories conceptually and a description of the interface that will be provided by Portage. Overlays. The only thing you need is a repo id, the only thing we need is to know what you'll be accessing, what we need to future proof from an api standpoint. | Especially since you've said we're not doing it the way you think | it should work... | | Where have I stated that? My statements thus far about multi repo | were in reference to a glep that missed the target. | | Provide quotes please, or get back to nailing down exactly what you | need portageq wise so we can state do it this way, and we'll shut | up. I'm thinking mainly about Portage externally will use user defined in relation to repository identification. Any specification on multiple repositories that comes from me will have said identifiers being repository designed, simply because I can't see a sane way of handling it otherwise. We've had this discussion once already, but I'll keep hammering the point till you follow it- external repo label is just that, what the user would specify on commandline. emerge --repo blah --rsync (fex). Internal ids are a seperate beast, and a simple solution *now* is that any repo that provides new must bundle an ID. Do that, and portage can made to use it for your news crap. Aliasing (user naming) is something *we* would add as a feature down the line. Why am I stating it as such? Because again, overlays exist now, and your glep is willfully leaving them out in the cold. | You want us to nail everything down for our request, I'd like you to | do the same (especially since we're stuck maintaining whatever you | propose/create). I can't nail down details on multiple repository support until I'm told what Portage will do. Give me a specification for what Portage will do and I'll quite happily make the GLEP work with it.
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 09:52, Ciaran McCreesh wrote: On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | newsdir=$(portageq envvar PORTDIR)/metadata/news | newsdir=$(portageq newsdir gentoo) | | Both have one level of indirection. The first has two hard coded | elements. The first has one. Where is the massive over-indirection? | | The second allows future changes. The first does not. Where does the | specification come into it? All that would be needed is to allow a | user a method to name overlays and it'd be useful straight off the | bat. The former relies upon existing, widely used functionality together with a well-defined path. The latter has some magic hard-coded name voodoo (what's a 'gentoo'?) and is still stuck only supporting a single location. What's a 'PORTDIR'? What's a 'metadata'? Outside of portage, these are also magic name voodoo. But I've grown tired of your imperfect circles. I think your design sucks and you think that my solution to making it not suck is too soon. The solution to that seems simple to me. Rather than have 'package manager' do anything, just have it provide hooks that will allow you to do your thing at the times you want. Good luck with solving the news in overlays bug when it comes in. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wed, 14 Dec 2005 21:09:02 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | What's a 'PORTDIR'? A PORTDIR is a well defined, widely used variable. | What's a 'metadata'? A metadata is a well defined, widely used directory in the tree. | Outside of portage, these are also magic name voodoo. Sure. Where in the GLEP does it say that I care about supporting Debian? | But I've grown tired of your imperfect circles. I think your design | sucks and you think that my solution to making it not suck is too | soon. The solution to that seems simple to me. Rather than have | 'package manager' do anything, just have it provide hooks that will | allow you to do your thing at the times you want. Exactly what I am doing. Hence why I'm not making Portage know any more than it really really has to about news. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Ciaran McCreesh wrote: | soon. The solution to that seems simple to me. Rather than have | 'package manager' do anything, just have it provide hooks that will | allow you to do your thing at the times you want. Exactly what I am doing. Hence why I'm not making Portage know any more than it really really has to about news. I wish you'd reconsider, because I was looking forward to multiple repository support. You may want to specify the newsdir=$(portageq envvar PORTDIR)/metadata/news bit in the glep and also note in the glep that there were dissenting opinions regarding the assumptions that you have made there. Zac -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wed, 14 Dec 2005 13:48:45 -0800 Zac Medico [EMAIL PROTECTED] wrote: | I wish you'd reconsider, because I was looking forward to multiple | repository support. Well, if Portage ever gets multiple repository support, then news clients can be updated to handle it. The GLEP says that already. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Re: GLEP 42 (Critical News Reporting) round five
Ciaran McCreesh posted [EMAIL PROTECTED], excerpted below, on Tue, 13 Dec 2005 03:20:43 +: Ok, new draft. Changes are as follows: [] * Changed /var/lib/portage to /var/lib/gentoo OK, I must have missed the reason for that, and it isn't listed in one of your a previous version notes, unless I missed that too. g Assuming the reason wasn't contrary to this (which it probably is, but...), why not /var/lib/portage/news/gentoo? If I read jstubbs' suggestion correctly, the gentoo would then serve as the repo name (in place of magic-chicken, altho as he proposed it, that would be part of the filename, not the directory the file is in) as well -- he said naming the current/default repo gentoo was sufficient. * Added emerge --ask thingie Checks for new news messages should be displayed: [] * After an ``emerge --pretend`` [] * Before an ``emerge --ask target`` sequence Wouldn't it be less confusing if the news warning appeared in the same place, relative to the package listing, in both of these? Isn't an emerge --ask just the output of pretend, with a confirmation pinned to the end? Shouldn't it continue to be that, at least in concept? * news.read is now mandatory for interactive clients, and ignored for gateway clients When a news item is read, its name should be removed from the ``news-magic-chicken.unread`` file. If a news client acts as an interactive reader rather than a gateway, it should then add the name to a ``news-magic-chicken.read`` file in the same directory with the same file format (again, ``magic-chicken`` should be a wildcard rather than hardcoded). First, the change outline doesn't state what the result actually was, in the GLEP. Mandatory would require a MUST (or a similar statement that it's mandatory), while the GLEP words it as a SHOULD. Or is should not to be taken in the usual RFC meaning, but rather as an RFC MUST? Second but related, the first time I read thru it, I somehow missed the rather than a gateway part. Upon rereading, I saw it (obviously), but the effect of the present wording is to deemphasize the gateway clause, as well as the read file. If it's truly a MUST, then the read file deserves equal treatment with the unread file, probably by introducing the two as a pair, then treating them in parallel thru most of the other references. (IOW, the read file and its requirement for interactive clients currently appears to be the afterthought it in fact was, without that fact being recognized, which doesn't particularly positively impress, quality-wise.) Third, recall from the discussion of an earlier draft, someone mentioned the multiple meaning of read (as here) vs. read (as in README). The suggestion to avoid that ambiguity was seen and unseen. Another might be (un)viewed. I'm not sure this is a big enough issue to matter much, particularly with unread there as well, to influence the context, but as I don't recall that point being addressed, I thought I'd mention it here. Read the whole thing before commenting please. I did. FWIW IMO... Your tenacity and attention to detail are both extremely good qualities to have in someone doing a GLEP. Few have the attention to detail and self-standards necessary, and I fear many that do would give up due to the barrage of criticism (hopefully all constructive g) these things get. Do keep up the good work! IMO, you are /far/ better at it than most would be, and the resulting GLEP will ultimately be the better for it! -- 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) updates
On Tuesday 13 December 2005 11:45, Andrew Muraco wrote: Jason Stubbs wrote: On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | So what are you going to do? I asked already but you didn't answer. | How are you going to find $PORTDIR/metadata/news? At present, by using portageq with a hardcoded suffix. If in the future Portage introduces new functionality, then clients and the specification can easily be updated to handle said functionality. And how can that be adapted to work with overlays, completely ignoring the possibility of distinct repositories. Overlays is something that exists already and news support for them is a request that will appear as soon as news support is added. Your Point is Moot ... Interesting use of capitals. because an overlay (at present) is going to be exprimental software, or a repository from a non-English speaking community Gentoo site... (unsupported offically anyways) and so you _should_ know what risks your taking, except if your a new non-English-speaking user utilizing such a repository. this GLEP is to warn you about supported updates/changes which you _need_ to know about. This GLEP is about getting news regarding a set of ebuilds to the user. Making it only about the Gentoo supported tree serves no purpose. Why should an overlay need to have news if the user has the consciensely update and maintain it to begin it. Because they already support package.mask, thirdpartymirrors, eclasses and just about anything else that exists in the supported tree. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:48, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:39:14 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | And how can that be adapted to work with overlays, completely | ignoring the possibility of distinct repositories. Overlays is | something that exists already and news support for them is a request | that will appear as soon as news support is added. Overlays don't contain metadata directories There's nothing preventing this. and don't get synced, As Zac pointed out, esync exists. so they don't contain news items. Neither of the points above prevent an overlay from containing news items. Supporting news from multiple sources is something that's tied to supporting packages from multiple sources, which overlay doesn't permit. Overlays are used for getting packages from multiple sources every day. The only thing preventing them from supporting getting news from multiple sources is your stubborness against adding a single level of indirection - a level of indirection that has absolutely no cost to readers. Fixing that would require fixing portage to support multiple repositories rather than using overlay, which is an issue for a different GLEP. I'll say it again. It wouldn't require a GLEP because the changes wouldn't go beyond portage. At least they wouldn't if you'd allow portage to keep its internals internal. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical News Reporting) round five
On Tue, 13 Dec 2005 05:19:27 -0700 Duncan [EMAIL PROTECTED] wrote: | Ciaran McCreesh posted [EMAIL PROTECTED], | excerpted below, on Tue, 13 Dec 2005 03:20:43 +: | | Ok, new draft. Changes are as follows: | [] | * Changed /var/lib/portage to /var/lib/gentoo | | OK, I must have missed the reason for that, and it isn't listed in | one of your a previous version notes, unless I missed that too. g It's getting ready for the glorious future when we won't be using Portage any more. I also changed most of the instances of Portage in the GLEP to the package manager. | Wouldn't it be less confusing if the news warning appeared in the same | place, relative to the package listing, in both of these? Isn't an | emerge --ask just the output of pretend, with a confirmation pinned | to the end? Shouldn't it continue to be that, at least in concept? It's a question of visibility. | First, the change outline doesn't state what the result actually was, | in the GLEP. Mandatory would require a MUST (or a similar statement | that it's mandatory), while the GLEP words it as a SHOULD. Or is | should not to be taken in the usual RFC meaning, but rather as an | RFC MUST? I'm avoiding 'must', because there's probably a legitimate exception somewhere. | Third, recall from the discussion of an earlier draft, someone | mentioned the multiple meaning of read (as here) vs. read (as in | README). The suggestion to avoid that ambiguity was seen and | unseen. Another might be (un)viewed. I'm not sure this is a big | enough issue to matter much, particularly with unread there as | well, to influence the context, but as I don't recall that point | being addressed, I thought I'd mention it here. Pfff. Email clients use it. Trying to avoid words with multiple definitions in English is pretty much futile. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Jason Stubbs wrote: [Mon Dec 12 2005, 07:51:51PM CST] | There doesn't need to be a debate. This whole proposal doesn't care | about portage compatibility whatsoever and it's exactly this style of | thinking that slows down portage development (which everybody loves | to complain about so much). Sure it does. It cares about the way Portage is currently, and it cares about any reasonable future Portage changes. Bullshit. I'm not quite sure I understand the strong response. The GLEP was clearly designed to have a minimal impact on portage. Now I'm willing to listen to arguments that it does not, in fact, do that, but certainly the well-defined, minimal coupling between the news and emerge was not accidental. (Incidentally, I've never complained about the pace of portage development. I'm not developing it, so I don't complain about those who are.) Just as an aside, it would be nice if we could keep [EMAIL PROTECTED] vulgarity-free, since it's a list that's often read at work by a good number of people. | As I said already, there will immediately be a bug asking for overlay | support. Portage already supports multiple in a form whether anybody | likes it or not. How they are supported and how they will change | should be of no concern to the glep. What should be of concern is | establishing a robust API between the readers and portage such that | future changes won't cause breakage. Wouldn't it suffice for the GLEP to simply have a statement that it will query portage for a list of repositories, once there's a way to do that, but until then the default repo will be assumed? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp9qHX6VO2Cp.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 07:12, Grant Goodyear wrote: Jason Stubbs wrote: [Mon Dec 12 2005, 07:51:51PM CST] | As I said already, there will immediately be a bug asking for overlay | support. Portage already supports multiple in a form whether anybody | likes it or not. How they are supported and how they will change | should be of no concern to the glep. What should be of concern is | establishing a robust API between the readers and portage such that | future changes won't cause breakage. Wouldn't it suffice for the GLEP to simply have a statement that it will query portage for a list of repositories, once there's a way to do that, but until then the default repo will be assumed? Modifications are required to portage anyway. Why postpone it until after several readers are written and force all of them become broken? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wed, 14 Dec 2005 08:44:39 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Modifications are required to portage anyway. Why postpone it until | after several readers are written and force all of them become broken? Because there isn't a specification saying what the future changes to Portage will be, so supporting said future changes straight off would require a massively over-generalised, over-indirected solution. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Jason Stubbs wrote: [Tue Dec 13 2005, 05:44:39PM CST] Wouldn't it suffice for the GLEP to simply have a statement that it will query portage for a list of repositories, once there's a way to do that, but until then the default repo will be assumed? Modifications are required to portage anyway. Why postpone it until after several readers are written and force all of them become broken? Okay, so what is the portage team proposing to use for a repo query API? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpKJpt3hG1A8.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 08:54, Ciaran McCreesh wrote: On Wed, 14 Dec 2005 08:44:39 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Modifications are required to portage anyway. Why postpone it until | after several readers are written and force all of them become broken? Because there isn't a specification saying what the future changes to Portage will be, so supporting said future changes straight off would require a massively over-generalised, over-indirected solution. newsdir=$(portageq envvar PORTDIR)/metadata/news newsdir=$(portageq newsdir gentoo) Both have one level of indirection. The first has two hard coded elements. The first has one. Where is the massive over-indirection? The second allows future changes. The first does not. Where does the specification come into it? All that would be needed is to allow a user a method to name overlays and it'd be useful straight off the bat. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | newsdir=$(portageq envvar PORTDIR)/metadata/news | newsdir=$(portageq newsdir gentoo) | | Both have one level of indirection. The first has two hard coded | elements. The first has one. Where is the massive over-indirection? | | The second allows future changes. The first does not. Where does the | specification come into it? All that would be needed is to allow a | user a method to name overlays and it'd be useful straight off the | bat. The former relies upon existing, widely used functionality together with a well-defined path. The latter has some magic hard-coded name voodoo (what's a 'gentoo'?) and is still stuck only supporting a single location. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
For reference, I'm quoting this snippet from earlier in the thread: Jason Stubbs wrote: On Sunday 11 December 2005 10:35, Ciaran McCreesh wrote: .. Note:: Future changes to Portage involving support for multiple repositories may require one news list per repository. Assuming repositories have some kind of unique identifier, this file could be named ``news-repoid.unread``. Repositories will definitely have a unique identifier. Perhaps it would be better to use the repository-identifing format from the beginning so that readers are forced to be forwards-compatible? Assuming the readers would then output the repository name, labeling it gentoo should work well... [...] Ciaran McCreesh wrote: On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | newsdir=$(portageq envvar PORTDIR)/metadata/news | newsdir=$(portageq newsdir gentoo) | | Both have one level of indirection. The first has two hard coded | elements. The first has one. Where is the massive over-indirection? | | The second allows future changes. The first does not. Where does the | specification come into it? All that would be needed is to allow a | user a method to name overlays and it'd be useful straight off the | bat. The former relies upon existing, widely used functionality together with a well-defined path. The latter has some magic hard-coded name voodoo (what's a 'gentoo'?) and is still stuck only supporting a single location. Apparently, 'gentoo' is meant to be the identifier for the official gentoo repository (portage tree). It corresponds to 'magic-chicken' below. Ciaran McCreesh wrote: Whenever relevant unread news items are found, the package manager will create a file named ``/var/lib/gentoo/news/news-magic-chicken.unread`` (if it does not already exist) and append the news item identifier (eg ``2005-11-01-yoursql-updates``) on a new line. Zac -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Ciaran McCreesh posted [EMAIL PROTECTED], excerpted below, on Sun, 11 Dec 2005 21:19:08 +: Does anyone really use emerge --ask? Oh, /my/ yes! The following should speak for itself. (I have a similar set of ep* commands, those in /usr/local/bin, so I can --pretend as my normal user. Yes, I do have autocompletion setup for them all, too, tho it was basically a matter of ensuring the gentoo autocompletion ran first, then using the same autocomplete functions emerge did, since these are almost all just special cases of the emerge command.) ~#cd /usr/local/sbin /usr/local/sbin#for eascript in ea* ;do echo $eascript;cat $eascript;done ea #!/bin/bash exec emerge -av --oneshot $* ea2 #!/bin/bash exec emerge -av $* eafetch #!/bin/bash exec emerge -avuDf $* eafetchworld #!/bin/bash exec emerge -avuDf world eapaK #!/bin/bash exec emerge -avk --oneshot $* eapaK2 #!/bin/bash exec emerge -avk $* eapak #!/bin/bash exec emerge -avK --oneshot $* eapak2 #!/bin/bash exec emerge -avK $* easync #!/bin/bash emerge sync eupdatedb emerge -avuDf world eatree #!/bin/bash exec emerge -avuDt --oneshot $* eatree2 #!/bin/bash exec emerge -avuDt $* eatreeworld #!/bin/bash exec emerge -avuDt world eaworld #!/bin/bash exec emerge -avuD world -- 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) updates
Jason Stubbs posted [EMAIL PROTECTED], excerpted below, on Mon, 12 Dec 2005 09:11:53 +0900: On Monday 12 December 2005 09:01, Ciaran McCreesh wrote: On Mon, 12 Dec 2005 08:44:00 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Repositories will be user-labelled. However, all that readers need be | concerned with is how to extract the repository name from the | news.unread file and how to then resolve that to a directory name, | regardless of how repositories are implemented. See, this is exactly why I'm not wanting to care about multiple repo details at this point. There's no specification of how they work and what exactly they're supposed to do, and to make matters worse the way you seem to think they'll be handled is a really really bad way of doing it. Regardless of what you think about the current plans for multiple repository support, the details that readers will need to know wont change. Ciaran hasn't stated, but it appears to me if I'm reading correctly between the lines, the reason he doesn't want to mess with specifying multiple repo details right now is that it's getting the cart before the horse in terms of nailing down certain areas of the multiple repo spec. For example, if repository-id forms a part of the path and we define path parsing now, then we are effectively defining legal characters for repository-id now. That's an entirely different glep, far out of scope and reaching into other people's territory, limiting how that might be implemented by defining a portion of the id-scope in an entirely unrelated glep. Given how heated I've seen GLEP discussion get (and I'm not saying that's /bad/, just a fact), I really can't blame Ciaran for attempting to keep the scope of the proposal, and therefore the debate, down to exactly what he's aiming to accomplish, without ending up getting into an entirely /different/ debate about how he's limiting the future flexibility of the multiple repo implementation. Once there's a concrete proposal there to work with, then and only then, he's saying (from my viewpoint), is it appropriate for consideration in relation to the news proposal. Don't unnecessarily tie the two together, complicating life for both. Let each be argued on its merits separately, and when/if multiple repo is actually close enough to deployment that there's some actual rules to work with, /then/ worry about fixing this to match. If I'm incorrect, just tell me to go back in my corner and lurk some more g, but that's what I'm getting out of this subthread so far. -- 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) updates
On Mon, 12 Dec 2005 23:49:31 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | No need for a glep as far as portage support goes anymore than Ciaran | needs a glep to change or add syntax highlighting in vim. The difference is, Vim syntax scripts are well established, and there aren't any design issues to solve. Multiple repository support clearly *isn't* obvious, because the solution you've described is the wrong one. | There doesn't need to be a debate. This whole proposal doesn't care | about portage compatibility whatsoever and it's exactly this style of | thinking that slows down portage development (which everybody loves | to complain about so much). Sure it does. It cares about the way Portage is currently, and it cares about any reasonable future Portage changes. | As I said already, there will immediately be a bug asking for overlay | support. Portage already supports multiple in a form whether anybody | likes it or not. How they are supported and how they will change | should be of no concern to the glep. What should be of concern is | establishing a robust API between the readers and portage such that | future changes won't cause breakage. Ok, give me a list of every single future enhancement to Portage and I'll make sure the GLEP will be compatible with them. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 02:16, Ciaran McCreesh wrote: On Mon, 12 Dec 2005 23:49:31 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | No need for a glep as far as portage support goes anymore than Ciaran | needs a glep to change or add syntax highlighting in vim. The difference is, Vim syntax scripts are well established, and there aren't any design issues to solve. Multiple repository support clearly *isn't* obvious, because the solution you've described is the wrong one. Blah, blah, blah. | There doesn't need to be a debate. This whole proposal doesn't care | about portage compatibility whatsoever and it's exactly this style of | thinking that slows down portage development (which everybody loves | to complain about so much). Sure it does. It cares about the way Portage is currently, and it cares about any reasonable future Portage changes. Bullshit. | As I said already, there will immediately be a bug asking for overlay | support. Portage already supports multiple in a form whether anybody | likes it or not. How they are supported and how they will change | should be of no concern to the glep. What should be of concern is | establishing a robust API between the readers and portage such that | future changes won't cause breakage. Ok, give me a list of every single future enhancement to Portage and I'll make sure the GLEP will be compatible with them. Without a list of future features, you think the best way to go must be the least agile? As Zac said, all that matters to keep full compatibility on the side of the readers is to add a level of indirection. All your reasoning above falls apart in the face of that simple *logical* request. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tue, 13 Dec 2005 10:51:51 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Without a list of future features, you think the best way to go must | be the least agile? As Zac said, all that matters to keep full | compatibility on the side of the readers is to add a level of | indirection. All your reasoning above falls apart in the face of that | simple *logical* request. Every problem can be solved by adding another layer of indirection, except for the problem of having too many layers of indirection. This layer you are proposing is not going to do anything useful. It's merely adding indirection for the sake of it. There's no more need for this than there is need for a two thousand line XML DTD which allows us to specify the author's date of birth using an ancient Sumerian calendar. Come up with a full specification of how Portage will handle multiple repositories, and get that specification agreed upon by the people who will end up having to use it. *Then* come back and ask me to add in more complexity. I'm not going to over-complicate things to deal with random hypothetical half-baked speculation. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:11, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 10:51:51 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Without a list of future features, you think the best way to go must | be the least agile? As Zac said, all that matters to keep full | compatibility on the side of the readers is to add a level of | indirection. All your reasoning above falls apart in the face of that | simple *logical* request. Every problem can be solved by adding another layer of indirection, except for the problem of having too many layers of indirection. This layer you are proposing is not going to do anything useful. It's merely adding indirection for the sake of it. There's no more need for this than there is need for a two thousand line XML DTD which allows us to specify the author's date of birth using an ancient Sumerian calendar. Come up with a full specification of how Portage will handle multiple repositories, and get that specification agreed upon by the people who will end up having to use it. *Then* come back and ask me to add in more complexity. I'm not going to over-complicate things to deal with random hypothetical half-baked speculation. So what are you going to do? I asked already but you didn't answer. How are you going to find $PORTDIR/metadata/news? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | So what are you going to do? I asked already but you didn't answer. | How are you going to find $PORTDIR/metadata/news? At present, by using portageq with a hardcoded suffix. If in the future Portage introduces new functionality, then clients and the specification can easily be updated to handle said functionality. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | So what are you going to do? I asked already but you didn't answer. | How are you going to find $PORTDIR/metadata/news? At present, by using portageq with a hardcoded suffix. If in the future Portage introduces new functionality, then clients and the specification can easily be updated to handle said functionality. And how can that be adapted to work with overlays, completely ignoring the possibility of distinct repositories. Overlays is something that exists already and news support for them is a request that will appear as soon as news support is added. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Jason Stubbs wrote: On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | So what are you going to do? I asked already but you didn't answer. | How are you going to find $PORTDIR/metadata/news? At present, by using portageq with a hardcoded suffix. If in the future Portage introduces new functionality, then clients and the specification can easily be updated to handle said functionality. And how can that be adapted to work with overlays, completely ignoring the possibility of distinct repositories. Overlays is something that exists already and news support for them is a request that will appear as soon as news support is added. -- Jason Stubbs Your Point is Moot because an overlay (at present) is going to be exprimental software, (unsupported offically anyways) and so you _should_ know what risks your taking, this GLEP is to warn you about supported updates/changes which you _need_ to know about. Why should an overlay need to have news if the user has the consciensely update and maintain it to begin it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:39:14 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | And how can that be adapted to work with overlays, completely | ignoring the possibility of distinct repositories. Overlays is | something that exists already and news support for them is a request | that will appear as soon as news support is added. Overlays don't contain metadata directories and don't get synced, so they don't contain news items. Supporting news from multiple sources is something that's tied to supporting packages from multiple sources, which overlay doesn't permit. Fixing that would require fixing portage to support multiple repositories rather than using overlay, which is an issue for a different GLEP. You can use gensync (included with gentoolkit). $ gensync --help Usage: gensync options repo-id-1 repo-id-2 ... where options is one of -a, --all-sources - sync all know sources -l, --list-sources - list known rsync sources -C, --no-color - turn off colours -h, --help - this help screen -V, --version - display version info Zac -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical News Reporting) round five
On Mon, 12 Dec 2005 22:30:52 -0500 Dan Meltzer [EMAIL PROTECTED] wrote: | Internationalisable |Being able to provide messages in multiple languages may be | beneficial. | | Not quite sure, is it required for GLEP's to be in american English or | is UK English fine? | | Pointing at Internationalizable The standard for Gentoo documentation is to use whichever variant the original author prefers. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Re: GLEP 42 (Critical News Reporting) round five
Alrighty then, good enough for me :) One other thing .. Note:: A previous draft of this GLEP allowed news items to be sent to ``gentoo-core`` instead of ``gentoo-dev``. It is possible that a situation may arise where this will be necessary (for example, a security update which must break backwards compatibility and which cannot be revealed to the public before a given date). The seems like a half complete thought, I realize you want to discourage it from happening, but maybe change it to read It is possible that a situation and in only this case may it be sent to -core instead On 12/12/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 12 Dec 2005 22:30:52 -0500 Dan Meltzer [EMAIL PROTECTED] wrote: | Internationalisable |Being able to provide messages in multiple languages may be | beneficial. | | Not quite sure, is it required for GLEP's to be in american English or | is UK English fine? | | Pointing at Internationalizable The standard for Gentoo documentation is to use whichever variant the original author prefers. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Point of Clarity, and the ``mysql-5`` database format changes. These changes actually occured in mysql 4.1, not mysql-5 On 12/10/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: Main changes since the previous edition: * File format tweaks. * Changes to the way relevance headers work to make it easy to do things like show this to gcc-3.3 users on x86 or sparc. * News items are no longer copied. This makes it considerably easier to install news items -- there's no longer a need to do clever directory syncing tricks. For those of you who can't read RST, an updated version will appear on the website sometime in the not too distant future. For those of you who can, see the attached. For the sake of keeping this vaguely sane, replies that meet any of the following criteria will be ignored: * Top or HTML posting * Lack of coherent English sentences, complete with proper punctuation and capitalisation. * The sender's first name ends in 'an', and they are not me. * Questions about why the GLEP doesn't address hypothetical vapourware concepts. * Questions about why the GLEP doesn't provide a way to tell users that there's a pissup at Reuben's house next Tuesday. * Questions about why the GLEP doesn't require integration with other systems, rather than leaving it merely as something that should be easily doable. * Anything involving XML. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Sat, 2005-12-10 at 22:31 -0500, Dan Meltzer wrote: Point of Clarity, and the ``mysql-5`` database format changes. These changes actually occured in mysql 4.1, not mysql-5 * The sender's first name ends in 'an', and they are not me. Um, your first name ends in 'an' so your reply is immaterial -- 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
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
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Monday 07 November 2005 19:11, Paul de Vrieze wrote: On Saturday 05 November 2005 06:34, Alec Warner wrote: emerge --changelog has no 'official' format. I believe echangelog actually puts the changes in the correct format for emerge -l to read, however not everyone uses echangelog. Many developers commit in an incompatable syntax causing the parsing to fail. This I believe, is an implementation issue. Obviously if someone is trying to get an upgrade guide to users they aren't going to commit in an incompatable format. I would also like to add that the changelog has too much information to be usefull as a news source. In all honesty, when I'm emerging a new version of a package I'm not interested in keyword bumps, small cosmetic changes, added auxiliary scripts or documentation. These are all documented (and should be) in the changelog. If I update my system however, I'm mainly interested in knowing whether something is going to break. News would be a way to provide this knowledge to a user in an as concise as possible way. So what's the point of the ChangeLog again? Move load from the CVS server and onto the rsync servers? (Don't answer that - just beating a dead horse ;) I'm really just against having it in emerge, especially with the current suggestion of portage just doing a little bit of maintenance work for external tools and nothing else. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
Jason Stubbs wrote: [Mon Nov 07 2005, 06:37:10AM CST] So what's the point of the ChangeLog again? Move load from the CVS server and onto the rsync servers? (Don't answer that - just beating a dead horse ;) *Grin* I'm going to answer anyway, since the answer isn't necessarily obvious to everybody. Once upon a time, the expectation was that the ChangeLog contained information about package modifications that would be of interest to users, while the CVS log would contain info mainly of interest to devs. Of course, that was when viewcvs accessed the live tree, too. Since then, there seems to have been a consensus that the CVS log should really be autogenerated from the ChangeLog, which itself is created using ``echangelog``. My view is that the ChangeLog should contain user-readable descriptions (although we also encourage some useful jargon such as version bump) of every change a package has undergone, providing a fairly complete history for that package that is much more readable than iterating through CVS diffs. Consequently, the ChangeLog has far too much information to realistically serve as a low-noise news source. (One could imagine tagging certain ChangeLog entries as being particularly important, but that forces news to be package based, and seems overly complicated, so please forget that I ever brought it up.) I'm really just against having it in emerge, especially with the current suggestion of portage just doing a little bit of maintenance work for external tools and nothing else. I'm not sure exactly what you're arguing here. Is it just that you think that the news stuff should be a post-sync hook instead of being triggered explicitly by emerge? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpsn76RkqrpW.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Tuesday 08 November 2005 01:06, Grant Goodyear wrote: Jason Stubbs wrote: [Mon Nov 07 2005, 06:37:10AM CST] I'm really just against having it in emerge, especially with the current suggestion of portage just doing a little bit of maintenance work for external tools and nothing else. I'm not sure exactly what you're arguing here. Is it just that you think that the news stuff should be a post-sync hook instead of being triggered explicitly by emerge? I just wrote several paragraphs but that got me thinking so I deleted 'em. Ok. There's two levels of APIs here. There's the post-sync stuff which utilizes portage's API. There'll never be any need for portage to utilize the post-sync stuff that I can think of; if there is, that's a reason for putting it into portage. The second layer is between the post-sync stuff and the news readers. Here we have a problem. As Brian mentioned, multiple independent repositories will be supported and each should be allowed to have it's own independent set of news items. Multiple repositories will bring new (or completely replace) portage APIs. Hence, the post-sync stuff will have to accomodate. Yet, that's going to propogate into the post-sync component's API provided for the readers. Multiple independent repositories is just one change that we know is going to throw a spanner in the works. There'll likely be others. Hmm, I think I've just discovered what's unsettling about all this. We're being asked to throw something into portage that'll do XYZ to support external tools, yet we are guaranteed to break the XYZ. I guess I'd be happy with portage doing it and responsibility for compatibility staying with portage as long as we can decide/lead how the external tools gains access to the information. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Mon, 2005-11-07 at 21:37 +0900, Jason Stubbs wrote: So what's the point of the ChangeLog again? Isn't it to record specific changes that have happened to a specific package? News items may be about changes that have not yet happened - to allow users to plan ahead and prepare appropriately. News items may also be about (possibly future) changes where there is no one corresponding package; equally a news item may be relevant for a large number of packages. In both of those circumstances, looking for news in a package-specific ChangeLog doesn't seem right to me. Feels to me to be both bad engineering and bad SCM practice. I'm really just against having it in emerge, especially with the current suggestion of portage just doing a little bit of maintenance work for external tools and nothing else. I can't think of any other place where we have every Gentoo user's attention to the same extent that we do when emerge outputs that reminder about any CONFIG_PROTECTed packages that need attention. It's the one and only place where we can reach every user. That is the whole purpose of this idea. We're trying to deliver the news to 100% of the user base, or as near as damn 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
[gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
Jason Stubbs wrote: I seem to be repeating myself... What's an example of repository-specific non-package-specific news? Why does `emerge --changelog` not suffice for package-specific news? a) maintainers don't put important news in their changelogs. there are a few exceptions. gregkh's udev bumps, for example, always come with an explanation of what changes have been made and what to watch out for. but mostly all the info you're going to get is Version bump., if that. b) there's no way to separate the wheat from the chaff. while i could (and usually do) emerge every update with -l, it's not something anyone with a life would do. the signal to noise ratio is very low, and not many people are going to go through reading the changelogs for every package on the odd chance that there might be some important nugget of info they need to know. combine this with a) and you'd have better luck playing the lottery than getting pertinent information that specifically applies to you. c) it's a passive system the user has to actually make an effort to retrieve this news. we _already_ have a number of different sources that they could be getting important info from. another is not what's needed. what we're looking for is a proactive solution where the news is dropped at their feet below a bigass neon arrow saying READ ME. d) news isn't necessarily package-based. news items could be based on a user's profile, language preference, architecture, USE flags, etc. there could also be general news to the entire community about global changes in Gentoo. --de. -- 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
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Saturday 05 November 2005 06:08, Jason Stubbs wrote: Why does `emerge --changelog` not suffice for package-specific news? From a user/sys.admin point of view let me give you an example; I maintain quite a lot Gentoo-systems. For me it's impossible to read _every_ changelog for minor release changes. For example not so long ago Apache was upgraded from 2.0.54-r15 to 2.0.54-r31. For me as a user/sys.admin based on versionnumbers this is a minor change. However the changes were rather extensive (e.g. reorganization of conf.files). When these changes occur I want to be informed _before_ I start emerge and I think that this information should be _pushed_ to users/sys.admins instead of _pulled_ from external sources (forums, website, mailinglist, etc. or changelogs). If changelogs could be extended with a priority flag and emerge would notify me when a high priority changelog is applicable to my system then this would be just fine for me. Basically all I want is; Notification that new relevant news items will be displayed via the ``emerge`` tool in a similar way to the existing configuration files need updating messages: :: * Important: 3 config files in /etc need updating. * Type emerge --help config to learn how to update config files. * Important: there are 2 security advisories released for installed packages. * Type emerge --security to see the details. * Important: there are 5 unread news items. * Type emerge --help news to learn how to read news files. If this is possible by extending the changelog I'm a happy users/sys.admin. I don't care if I need to type emerge --news or emerge --changelog as long the information is pushed. Disclaimer; I'm not 100% sure that the versionnumbers from Apache mentioned above are exact the real world examples, but you get the idea. Regards, -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Friday 04 November 2005 03:10, Nathan L. Adams wrote: Stuart Herbert wrote: On Tue, 2005-11-01 at 14:51 -0500, Chris Gianelloni wrote: Did you specifically ask them if it is because we have different news in different locations? Somehow I think you're obscuring some facts to make your own argument. That seems an unpleasant accusation to make :( The answer is that I didn't ask them if it was because we have different news in different locations. The question didn't occur to me. The only problem that we have now with our multiple mediums is that not all news is on all mediums. We should have the same information going to all of these and let the user choose which method they like for getting news. The critical difference between improving our existing mediums, and the emerge --news approach that I've proposed, is that emerge --news is the only approach that actively pushes news out to *all* users, and puts it in a place that is as guaranteed as anything else available to catch their attention. All the other approaches rely on the user going somewhere to get news, whether it's signing up to a mailing list, reading www.g.o, reading the forums, or whatever. Inevitably, this is only going to reach a smaller subsection of our user community. What I care about is that we've taken the right steps to put important information in front of *all* of our users (and our devs!). Even (especially?) the ones who are unable to keep up with the news as it is currently delivered. Making sure our users are well-informed improves the level and quality of service that we provide; it can only enhance our reputation; and it should also cut down on the amount of developer time that goes into post-upgrade support (leaving more time for package maintenance). One source: http://errata.gentoo.org/ Push that out to as many alternate sources as you like (RSS feeds, summaries in emerge --news, forums post, etc.), but make it known that the website is *the* source (your alternate sources should point back to it). Well I don't like web so much for this kind of things, so fails me. I want the info where I need it. I don't have network access from all the machines I admin. So the best possible repository for the news is with the tree, because that is allways required. And because Gentoo has the control over the tree it is very trivial and secure way to spread the news. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
Nathan L. Adams wrote: One source: http://errata.gentoo.org/ Push that out to as many alternate sources as you like (RSS feeds, summaries in emerge --news, forums post, etc.), but make it known that the website is *the* source (your alternate sources should point back to it). I beg to differ. The tree should be the central point because it's the only known place where all users can receive relevant information on and for each and every system they maintain right before they upgrade. The warning and the logic that triggers its display should be part of Portage. Sometimes, all that would need to be displayed is run foo to fix bar or Please do read http://bleh _before_ you upgrade foo. If an Upgrade guide to foo/bar for Gentoo is required, you need an author to write it, not extra code or an extra web site. -- / Xavier Neys \_ Gentoo Documentation Project / French Internationalisation Lead \ http://www.gentoo.org/doc/en /\ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Friday 04 November 2005 23:26, Xavier Neys wrote: Nathan L. Adams wrote: One source: http://errata.gentoo.org/ Push that out to as many alternate sources as you like (RSS feeds, summaries in emerge --news, forums post, etc.), but make it known that the website is *the* source (your alternate sources should point back to it). I beg to differ. The tree should be the central point because it's the only known place where all users can receive relevant information on and for each and every system they maintain right before they upgrade. The warning and the logic that triggers its display should be part of Portage. Sometimes, all that would need to be displayed is run foo to fix bar or Please do read http://bleh _before_ you upgrade foo. If an Upgrade guide to foo/bar for Gentoo is required, you need an author to write it, not extra code or an extra web site. I probably shouldn't have included the sarcastic comment in my only other reply to this thread, but the rest of it was completely serious. People are under the mistaken impression that the ebuild tree is required to use portage. This is wrong and will become more and more wrong as time goes by. If there is not a specific need for this news stuff to go into the tree then it shouldn't be there. If there is a specific need (ie. it is tied to packages) what difference is there to the existing ChangeLog? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
Jason Stubbs wrote: On Friday 04 November 2005 23:26, Xavier Neys wrote: Nathan L. Adams wrote: One source: http://errata.gentoo.org/ Push that out to as many alternate sources as you like (RSS feeds, summaries in emerge --news, forums post, etc.), but make it known that the website is *the* source (your alternate sources should point back to it). I beg to differ. The tree should be the central point because it's the only known place where all users can receive relevant information on and for each and every system they maintain right before they upgrade. The warning and the logic that triggers its display should be part of Portage. Sometimes, all that would need to be displayed is run foo to fix bar or Please do read http://bleh _before_ you upgrade foo. If an Upgrade guide to foo/bar for Gentoo is required, you need an author to write it, not extra code or an extra web site. I probably shouldn't have included the sarcastic comment in my only other reply to this thread, but the rest of it was completely serious. People are under the mistaken impression that the ebuild tree is required to use portage. This is wrong and will become more and more wrong as time goes by. If there is not a specific need for this news stuff to go into the tree then it shouldn't be there. If there is a specific need (ie. it is tied to packages) what difference is there to the existing ChangeLog? -- Jason Stubbs I am going to summarize a bit, and address your point. Summary: people want small news tidbits to be distributed to all users. Currently the suggestion is tree-based. Portage should have code to detect news elements after a sync and copy relevant elements to a uesr specified news directory. The news should be in a human readable format (XML, RST, pig latin, don't care at this point see below). Portage should post-sync, print a message noting the number of unread but relevant news messages. Users can use whatever means of reading them that they like. IMHO, emerge --news can go to hell in a handbasket, I'd rather just friggin use less, but hey, if you write the code... News messages should contain minimal information necessary to carry relevant information including affected packages, and a link to some sort of documentation, be it gentoo-wiki, or official package docs, or whatever. For those without internet access 24/7, there may be an option required to fetch these links. In the case of say, dial-up where someone only has network say, 4 hours a day, they may wish to sync their tree, and spider the docs links so they may view them locally. Machines with no outside network ( internal production servers ) may also wish to make use of this. In the case of online guides, we cannot necessarily define their content, it may be XML, it may be plain text. I do not see how conceeding that a user may need a web browser SOMEWHERE, is that big of a tradeoff, especially if the content is already locally available. As far as including news in the tree goes, news is repository bound information. Each repository may in fact have relevant news, and in preparation for multiple repositories this is how the news should be handled. It goes with the rest of the repo-specific information. That is why it should be in the tree. However, in the case of a remote tree, some extra API calls may be required. However, it is up to the class implementor to implement those calls, not the original portage team ( unless you want to support remote trees yourself, in which case that duty falls to you ). The only other thing was no tree but a binpkg repo, in which case in savior, binpkg repo should have news elements build in ( a repo, just all built packages ). In stable, news should probably be added to the binpackage if it's listed in the packages-affected. For the XML vs RST. I personally don't want to read XML files in a console, or install anything that makes it look all pretty for me, RST is plenty good enough. Since Ciaran has graciously written all the code for it already, I don't see any reason not to use it. RST is pretty simple to migrate to a new format anyhow, and a converter could be easily whipped up to transform it to guideXMl for errate.g.o if that is what is desired ( not a bad idea IMHO ). I forgot one other thing, that being perhaps a red NEWS that shows up next to affected packages during an emerge -pv package, informing you that important news is available for a package you are about to install. So yeah, this is a long thread :0 Alec Warner (Antarus) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
Jason Stubbs wrote: On Saturday 05 November 2005 03:53, Alec Joseph Warner wrote: As far as including news in the tree goes, news is repository bound information. Each repository may in fact have relevant news, and in preparation for multiple repositories this is how the news should be handled. It goes with the rest of the repo-specific information. That is why it should be in the tree. I seem to be repeating myself... What's an example of repository-specific non-package-specific news? Why does `emerge --changelog` not suffice for package-specific news? -- Jason Stubbs Ok so I'm pwned there ;) emerge --changelog has no 'official' format. I believe echangelog actually puts the changes in the correct format for emerge -l to read, however not everyone uses echangelog. Many developers commit in an incompatable syntax causing the parsing to fail. This I believe, is an implementation issue. Obviously if someone is trying to get an upgrade guide to users they aren't going to commit in an incompatable format. We had a similar discussion before and many people wanted gentoo changelogs to stay true to only gentoo changes, thus some think a gentoo changelog is an inappropriate place to look for upgrade guides and errata. Changelogs are also not easy to search through and the current syntax does not provide all the benifits of the syntax provided by GLEP 42. So the options for using emerge --changelog are basically, updating the syntax to make it useful, probably audit the changelog code in emerge to make sure it works better ( even half decent 'entries' aren't grabbed, but I haven't looked at the changelog code in months ). This of course makes emerge the newsreader you didn't want, although I'm sure the eselect module could be modified to read Changelog's just as easily. Also, nothing covers the expiration of Changelog contents vs expiration of news items, since the news items are file independent, what if a bunch of commits basically erases a relevant news item out of the changelog? Certainly I would support either way ( news or changelog ) although in the latter case there are some seperate issues that need to be worked out ( mostly policy issues ). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Tue, 2005-11-01 at 14:51 -0500, Chris Gianelloni wrote: Did you specifically ask them if it is because we have different news in different locations? Somehow I think you're obscuring some facts to make your own argument. That seems an unpleasant accusation to make :( The answer is that I didn't ask them if it was because we have different news in different locations. The question didn't occur to me. The only problem that we have now with our multiple mediums is that not all news is on all mediums. We should have the same information going to all of these and let the user choose which method they like for getting news. The critical difference between improving our existing mediums, and the emerge --news approach that I've proposed, is that emerge --news is the only approach that actively pushes news out to *all* users, and puts it in a place that is as guaranteed as anything else available to catch their attention. All the other approaches rely on the user going somewhere to get news, whether it's signing up to a mailing list, reading www.g.o, reading the forums, or whatever. Inevitably, this is only going to reach a smaller subsection of our user community. What I care about is that we've taken the right steps to put important information in front of *all* of our users (and our devs!). Even (especially?) the ones who are unable to keep up with the news as it is currently delivered. Making sure our users are well-informed improves the level and quality of service that we provide; it can only enhance our reputation; and it should also cut down on the amount of developer time that goes into post-upgrade support (leaving more time for package maintenance). 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] Re: GLEP 42 (Was: Getting Important Updates To Users)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stuart Herbert wrote: On Tue, 2005-11-01 at 14:51 -0500, Chris Gianelloni wrote: Did you specifically ask them if it is because we have different news in different locations? Somehow I think you're obscuring some facts to make your own argument. That seems an unpleasant accusation to make :( The answer is that I didn't ask them if it was because we have different news in different locations. The question didn't occur to me. The only problem that we have now with our multiple mediums is that not all news is on all mediums. We should have the same information going to all of these and let the user choose which method they like for getting news. The critical difference between improving our existing mediums, and the emerge --news approach that I've proposed, is that emerge --news is the only approach that actively pushes news out to *all* users, and puts it in a place that is as guaranteed as anything else available to catch their attention. All the other approaches rely on the user going somewhere to get news, whether it's signing up to a mailing list, reading www.g.o, reading the forums, or whatever. Inevitably, this is only going to reach a smaller subsection of our user community. What I care about is that we've taken the right steps to put important information in front of *all* of our users (and our devs!). Even (especially?) the ones who are unable to keep up with the news as it is currently delivered. Making sure our users are well-informed improves the level and quality of service that we provide; it can only enhance our reputation; and it should also cut down on the amount of developer time that goes into post-upgrade support (leaving more time for package maintenance). One source: http://errata.gentoo.org/ Push that out to as many alternate sources as you like (RSS feeds, summaries in emerge --news, forums post, etc.), but make it known that the website is *the* source (your alternate sources should point back to it). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDarUL2QTTR4CNEQARAh0pAKCi7BJpBOkRRT4iiaXUjajwbrjseACfahPV R2MVvKhkLfnid1/ADRUZAxk= =Oou4 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Tue, 2005-11-01 at 08:56 +0100, Wernfried Haas wrote: On Mon, Oct 31, 2005 at 06:52:04PM -0500, Dan Meltzer wrote: 1) Why post to forums.g.o if its on www, why would one check forums instead of www. Redundancy - to get the attention of those folks that for whatever reason visit the forums and not www.gentoo.org in a specific time interval. The more places you cover, the more likely people will see it somewhere. We've been doing that with GLSAs for quite a while now. Exactly. While I agree that we need a single source where users can get their information, I feel that the *user* should be able to choose their source. If that is the gentoo-announce mailing list, or www.gentoo.org, or the forums, it doesn't matter. The same information should be duplicated. Make them *all* a definitive source. We don't need to check all of them if any one of them gives all of the information needed. As for subscriber counts or whatever, if by adding the information to gentoo-announce (or the forums or wherever), we reach 10 more users that we wouldn't have reached before, then I consider it a success. The idea is to reach as many users as possible here. To me, that means duplicating the information everywhere. -- 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 (Was: Getting Important Updates To Users)
On Tue, 2005-11-01 at 08:56 +0100, Wernfried Haas wrote: On Mon, Oct 31, 2005 at 06:52:04PM -0500, Dan Meltzer wrote: 1) Why post to forums.g.o if its on www, why would one check forums instead of www. Redundancy - to get the attention of those folks that for whatever reason visit the forums and not www.gentoo.org in a specific time interval. The more places you cover, the more likely people will see it somewhere. We've been doing that with GLSAs for quite a while now. The users I've spoken to about our news situation have expressly stated that one of their concerns is that there are *too many* places to check for news. They're not looking for us to scatter news across many mediums - they want one place to go. 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] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Tue, 2005-11-01 at 19:32 +, Stuart Herbert wrote: On Tue, 2005-11-01 at 08:56 +0100, Wernfried Haas wrote: On Mon, Oct 31, 2005 at 06:52:04PM -0500, Dan Meltzer wrote: 1) Why post to forums.g.o if its on www, why would one check forums instead of www. Redundancy - to get the attention of those folks that for whatever reason visit the forums and not www.gentoo.org in a specific time interval. The more places you cover, the more likely people will see it somewhere. We've been doing that with GLSAs for quite a while now. The users I've spoken to about our news situation have expressly stated that one of their concerns is that there are *too many* places to check for news. Did you specifically ask them if it is because we have different news in different locations? Somehow I think you're obscuring some facts to make your own argument. Allow me to make this one. If I want to get all of my facts from gentoo-announce, do I give a damn if the same thing is *also* posted on www.gentoo.org for others to read? Does it somehow inhibit my ability to get all of the news from gentoo-announce? They're not looking for us to scatter news across many mediums - they want one place to go. The only problem that we have now with our multiple mediums is that not all news is on all mediums. We should have the same information going to all of these and let the user choose which method they like for getting news. -- 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 (Was: Getting Important Updates To Users)
On Tuesday 01 November 2005 19:32, Stuart Herbert wrote: 1) Why post to forums.g.o if its on www, why would one check forums instead of www. Redundancy - to get the attention of those folks that for whatever The users I've spoken to about our news situation have expressly stated that one of their concerns is that there are *too many* places to check for news. They're not looking for us to scatter news across many mediums - they want one place to go. This user would prefer important news in as many places as possible. Yes, scattering different types of news about the tree in different places is stupid, having the same news in 4 different places might be mildly annoying if you see it 4 times, but if 4 times as many users see it all the better. Redundancy is a Good Thing. -- Mike Williams -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
s/where headstarted by a blog post by Stuart/where headstarted by bug 11359/ To jump right in :) On 10/31/05, Chris White [EMAIL PROTECTED] wrote: Attached in plain text form is glep 42 for the discussed thread. It's rather long, but I hope it details any sort of questions that may be brought up. Chris White -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
Bah, replied to fast. Other points of note... 1) Why post to forums.g.o if its on www, why would one check forums instead of www. 2) Theoretically it could be crossposted to the forums, probably simplest to do as a direct mysql insert, which'd be messy. 3) --news, my point of reamage. This is what bug 11359 was all about, I'm not quite sure why the wheel has been brought up for reinvention, this is most likely going to be a large change, and it seems that, instead of bugging portage developers to add more stuff to 2.0 series, which is basically relegated to bugfixes, we should just let them hack away at savior, which will have this support integrated (hell, it has it already). Having a temporary hack is pointless IMNSHO. In addition, seems like this could simply be something like glsa-check, call it news-update why don't we, which simply reads from the RSS feed (oh wow, i'm a genius!). Make this part of system, convince the baselayout guys (this is a lot easier even) to make emerge an alias that calls $(news-update) after emerge, and whaddya know, we have liftoff! On 10/31/05, Dan Meltzer [EMAIL PROTECTED] wrote: s/where headstarted by a blog post by Stuart/where headstarted by bug 11359/ To jump right in :) On 10/31/05, Chris White [EMAIL PROTECTED] wrote: Attached in plain text form is glep 42 for the discussed thread. It's rather long, but I hope it details any sort of questions that may be brought up. Chris White -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Mon, Oct 31, 2005 at 06:52:04PM -0500, Dan Meltzer wrote: 1) Why post to forums.g.o if its on www, why would one check forums instead of www. Redundancy - to get the attention of those folks that for whatever reason visit the forums and not www.gentoo.org in a specific time interval. The more places you cover, the more likely people will see it somewhere. We've been doing that with GLSAs for quite a while now. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org -- gentoo-dev@gentoo.org mailing list
