Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
Jason Stubbs 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. Expanding on this a little further then, we would have a file in a standard location such as /var/lib/portage-news/repos.desc that maps repository identifiers to the absolute paths of news directories (no hard coding of metadata/news/). This will provide a layer of indirection so that the portage news add-on will be able to direct news readers to the proper locations, regardless of repository implementation details. Even before multiple respositories are properly supported, I guarantee bugs about support for this in portage overlays. With the above, we would be able to add that support. Without it, all we can do is put a big CANTFIX. [...] the data should probably not be in /var/lib/portage I would also prefer that /var/lib/portage/ be reserved for core portage functionality (package management) and that non-essential add-ons store their data elsewhere. Zac -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Mon, 12 Dec 2005 23:29:00 +0900 Jason Stubbs <[EMAIL PROTECTED]> wrote: | Incorrect. There needs to be no GLEP regarding multiple repository | support in portage. There may need to be a GLEP regarding splitting | up the portage tree into separate repositories, but that is nothing | to do with the issue I'm talking about. Sure. You could go ahead and implement it without a GLEP in the really really bad way you're proposing currently. Or you could take the GLEP route and let other developers help you come up with a design that doesn't royally suck. | Again, why I really don't like this design. You're asking portage to | do crap to support external tools without looking to provide | compatibilty with future portages. How are you planning to find the | metadata directory in the first place? Not at all. There's an "it will probably be handled like this" note in the GLEP. I can't get any more detailed than that until there's a proper specification for what Portage is going to do in the future. | > | Nope, which is why news.read shouldn't be specified. | > | > news.read is specified because there was demand for it the last time | > around. It's staying specified because the reasons given were based | > upon convincing use cases rather than random speculation. | | Can you show a use case that crosses several readers? Look back to the original thread. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sun, Dec 11, 2005 at 02:53:34PM -0800, John Myers wrote: > On Sunday 11 December 2005 14:07, Diego 'Flameeyes' Pettenò wrote: > > On Sunday 11 December 2005 22:57, Ciaran McCreesh wrote: > > > You forgot d) a pain in the ass to parse, e) inconsistent with > > > everything else, f) a pain in the ass to sort, g) massive overkill. > > > > I find ISO 8601 simple to sort > Well, if you take the entire spec with all its variations, then ciaranm's > points there are indeed correct (week number formats, day of the year > formats, punctuationless formats, etc.) I specifically said an "ISO-8601 compatible" - I have no intentions of using the most verbose format. ./Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgplNPjQvOEpM.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Monday 12 December 2005 09:20, Ciaran McCreesh wrote: > On Mon, 12 Dec 2005 09:11:53 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | Regardless of what you think about the current plans for multiple > | repository support, the details that readers will need to know wont > | change. > > Incorrect. Right now, readers should ignore news-blah.unread and only > pay attention to news.unread. Readers will have to be updated to deal > with multiple repositories whenever the multiple repositories GLEP is > approved. Incorrect. There needs to be no GLEP regarding multiple repository support in portage. There may need to be a GLEP regarding splitting up the portage tree into separate repositories, but that is nothing to do with the issue I'm talking about. > | > | Even before multiple respositories are properly supported, I > | > | guarantee bugs about support for this in portage overlays. With > | > | the above, we would be able to add that support. Without it, all > | > | we can do is put a big CANTFIX. > | > > | > Overlay is not the same as multiple repository support. > | > | There's no difference as far as readers go. > > Sure there is. there's no metadata/ directory in overlays. Again, why I really don't like this design. You're asking portage to do crap to support external tools without looking to provide compatibilty with future portages. How are you planning to find the metadata directory in the first place? > | Nope, which is why news.read shouldn't be specified. > > news.read is specified because there was demand for it the last time > around. It's staying specified because the reasons given were based > upon convincing use cases rather than random speculation. Can you show a use case that crosses several readers? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Mon, 12 Dec 2005 09:11:53 +0900 Jason Stubbs <[EMAIL PROTECTED]> wrote: | Regardless of what you think about the current plans for multiple | repository support, the details that readers will need to know wont | change. Incorrect. Right now, readers should ignore news-blah.unread and only pay attention to news.unread. Readers will have to be updated to deal with multiple repositories whenever the multiple repositories GLEP is approved. | > | Even before multiple respositories are properly supported, I | > | guarantee bugs about support for this in portage overlays. With | > | the above, we would be able to add that support. Without it, all | > | we can do is put a big CANTFIX. | > | > Overlay is not the same as multiple repository support. | | There's no difference as far as readers go. Sure there is. there's no metadata/ directory in overlays. | Nope, which is why news.read shouldn't be specified. news.read is specified because there was demand for it the last time around. It's staying specified because the reasons given were based upon convincing use cases rather than random 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] GLEP 42 (Critical news reporting) updates
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. > | Even before multiple respositories are properly supported, I > | guarantee bugs about support for this in portage overlays. With the > | above, we would be able to add that support. Without it, all we can > | do is put a big CANTFIX. > > Overlay is not the same as multiple repository support. There's no difference as far as readers go. > | In that case, the data should probably not be in /var/lib/portage and > | definitely not specified in the GLEP. It has nothing to do with > | portage (the app) and isn't a requirement on readers. What if a > | reader wants to keep track of what date an item was read on? Or any > | other metadata? A new file would need to be created anyway due to > | format constrainst placed on news.read... > > Hrm. Does the GLEP need to cover how news readers that want to keep > track of whether or not the sysadmin was wearing pants last tuesday > should work too? Nope, which is why news.read shouldn't be specified. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
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. | Even before multiple respositories are properly supported, I | guarantee bugs about support for this in portage overlays. With the | above, we would be able to add that support. Without it, all we can | do is put a big CANTFIX. Overlay is not the same as multiple repository support. | In that case, the data should probably not be in /var/lib/portage and | definitely not specified in the GLEP. It has nothing to do with | portage (the app) and isn't a requirement on readers. What if a | reader wants to keep track of what date an item was read on? Or any | other metadata? A new file would need to be created anyway due to | format constrainst placed on news.read... Hrm. Does the GLEP need to cover how news readers that want to keep track of whether or not the sysadmin was wearing pants last tuesday should work too? -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Monday 12 December 2005 02:43, Ciaran McCreesh wrote: > On Sun, 11 Dec 2005 13:32:05 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | 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... > > *shrug* If someone creates metadata/repository_id (or whatever), I'll > go with that. Otherwise, I'm not in favour of attempting to guess how > the thing will be implemented. 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. Even before multiple respositories are properly supported, I guarantee bugs about support for this in portage overlays. With the above, we would be able to add that support. Without it, all we can do is put a big CANTFIX. > | > When a news item is read, its name should be removed from the > | > ``news.unread`` file. News clients may add the name to a > | > ``news.read`` file in the same directory with the same file format. > | > | news.read should either be mandatory or not created at all. Should a > | user change from a reader that creates and uses the file to one that > | doesn't and then change back again the results will be unexpected. > > I'm not sure that that's the case. With a news to email forwarder, for > example, it wouldn't make sense to keep track of news.read. In that case, the data should probably not be in /var/lib/portage and definitely not specified in the GLEP. It has nothing to do with portage (the app) and isn't a requirement on readers. What if a reader wants to keep track of what date an item was read on? Or any other metadata? A new file would need to be created anyway due to format constrainst placed on news.read... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sunday 11 December 2005 23:53, John Myers wrote: > Well, if you take the entire spec with all its variations, then ciaranm's > points there are indeed correct (week number formats, day of the year > formats, punctuationless formats, etc.) Well as long as you always use the same format, the sort is quite natural... -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpIl0Y1xkiDN.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sunday 11 December 2005 14:07, Diego 'Flameeyes' Pettenò wrote: > On Sunday 11 December 2005 22:57, Ciaran McCreesh wrote: > > You forgot d) a pain in the ass to parse, e) inconsistent with > > everything else, f) a pain in the ass to sort, g) massive overkill. > > I find ISO 8601 simple to sort Well, if you take the entire spec with all its variations, then ciaranm's points there are indeed correct (week number formats, day of the year formats, punctuationless formats, etc.) -- # # electronerd, the electronerdian from electronerdia # pgpizA6OEOzoY.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
Ciaran McCreesh wrote: Does anyone really use emerge --ask? Yes. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sunday 11 December 2005 13:19, Ciaran McCreesh wrote: > On Sun, 11 Dec 2005 04:57:23 -0700 Lares Moreau > | * Before an ``emerge --ask`` 'yes||no' response > > Does anyone really use emerge --ask? I do. Almost always in fact. When I want to install a package, I use --ask with --verbose so I get the --pretend output, and if I agree with the proposed list of dependencies and USE-flags, I allow it to proceed with just two keystrokes instead of having to go back up, change the command, and wait the extra time for it to recalculate the dependencies. Not a huge savings, but I do use it, and I would expect news items to be displayed right before the prompt where I can't miss them -- # # electronerd, the electronerdian from electronerdia # pgptDtCHOWvHW.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sunday 11 December 2005 22:57, Ciaran McCreesh wrote: > You forgot d) a pain in the ass to parse, e) inconsistent with > everything else, f) a pain in the ass to sort, g) massive overkill. I find ISO 8601 simple to sort -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpYInhF7jnyM.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sun, 11 Dec 2005 22:41:30 +0100 Henrik Brix Andersen <[EMAIL PROTECTED]> wrote: | As noted in the original GLEP 42 discussion, I strongly feel we should | use an ISO-8601 compliant date string representation as this is both | a) international, b) easy to read and c) machine parsable. You forgot d) a pain in the ass to parse, e) inconsistent with everything else, f) a pain in the ass to sort, g) massive overkill. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sun, Dec 11, 2005 at 04:57:23AM -0700, Lares Moreau wrote: > A couple things I noted: > (1) > In News Item Identities we have the following date format, > > Each news item will have a unique identifier. This identifier will be > > in the form ``-mm-dd-short-name`` > > Later in "News Item Headers" we have an other in order to be compatable > with GLEP 1. > > ``Posted:`` > > Date of posting, in ``dd-mmm-`` format (e.g. 14-Aug-2001) > > Is there any reason why we can't keep all the dates in the GLEP 1 date > format? IMHO this helps prevent confusion. As noted in the original GLEP 42 discussion, I strongly feel we should use an ISO-8601 compliant date string representation as this is both a) international, b) easy to read and c) machine parsable. See http://en.wikipedia.org/wiki/ISO_8601 or date(1) for more information. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgp95L7SuD6xg.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
Ciaran McCreesh wrote: Does anyone really use emerge --ask? Yes. -- Sandro -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sun, 11 Dec 2005 04:57:23 -0700 Lares Moreau <[EMAIL PROTECTED]> wrote: | Is there any reason why we can't keep all the dates in the GLEP 1 date | format? IMHO this helps prevent confusion. Yes. It makes sorting news items far harder. | * Before an ``emerge --ask`` 'yes||no' response Does anyone really use emerge --ask? | Could you be more verbose in the 'News Item Removal' section. I ask | because what would be considered "no longer relevant". I think the | case where a router(or similar) box is not updated for >6mths must be | considered. The Admin may have very well forgot about some particular | News Item, and if it is removed, this box will 'miss' the News Item. A news item is no longer relevant when there's no reasonable way in which it could apply. Six months is still relevant... Updates go back to 3Q-2002, for example. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
A couple things I noted: (1) In News Item Identities we have the following date format, > Each news item will have a unique identifier. This identifier will be > in the form ``-mm-dd-short-name`` Later in "News Item Headers" we have an other in order to be compatable with GLEP 1. > ``Posted:`` > Date of posting, in ``dd-mmm-`` format (e.g. 14-Aug-2001) Is there any reason why we can't keep all the dates in the GLEP 1 date format? IMHO this helps prevent confusion. (2) > Checks for new news messages should be displayed: > > * After an ``emerge sync`` > * After an ``emerge --pretend`` Add: * Before an ``emerge --ask`` 'yes||no' response I don't know if this is implied but I think it should be explicitly stated > * Before an ``emerge `` (which may also include a red warning message) (3) Could you be more verbose in the 'News Item Removal' section. I ask because what would be considered "no longer relevant". I think the case where a router(or similar) box is not updated for >6mths must be considered. The Admin may have very well forgot about some particular News Item, and if it is removed, this box will 'miss' the News Item. May I suggest only removing news Items after all the packages in the Display-If-(Installed|Profile) slots are no longer in the tree. Just a lowely ATs opinion -- Lares Moreau <[EMAIL PROTECTED]> | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
Ciaran McCreesh wrote: > GLEP: 42 > Title: Critical News Reporting +1 . -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sun, 11 Dec 2005 17:46:01 +0100 Wernfried Haas <[EMAIL PROTECTED]> wrote: | > There are currently several ways of delivering important news items | > to our users, none of them particularly effective: | | I'd suggest changing this to something more constructive - calling our | current efforts "none of them particularly effective" isn't exactly | a constructive way of critizing things. They're not particularly effective. If they were, there would be no need for this GLEP. | > A more reliable way of getting news of critical updates out to | > users is required to avoid repeats of the various recent upgrade | > debacles. | | As it was mentioned above, gcc 3.4 went pretty well on x86, can't | comment on mysql as i don't use it myself. I didn't say anywhere that the gcc 3.4 upgrade was a debacle. | I'd suggest changing this | text for something more diplomatic as i don't see much sense in having | council approved GLEPs talking about council approved upgrade | debacles. What, we're not allowed to admit that not everything we do works? | > .. Important:: This GLEP does not seek to replace or modify | > ``einfo`` messages which are displayed post-install. That is a | > separate issue which is handled by ``elog`` [#bug-11359]_. | | Thanks for clearing this quite important point up. That was added after the GLEP was wildly misreported in GWN the last time around... | I'd suggest extending the process of creating a news item to also | create a text to be posted to www.gentoo.org, the | announce-mailinglist, the forums, RSS feeds, GWN, etc. Of course | depending on the importance it may be decided to e.g. not post it | on announce but only www.gentoo.org. | | Do you think this can be done within this GLEP or rather outside? That's beyond the scope of the GLEP. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sun, 11 Dec 2005 13:32:05 +0900 Jason Stubbs <[EMAIL PROTECTED]> wrote: | 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... *shrug* If someone creates metadata/repository_id (or whatever), I'll go with that. Otherwise, I'm not in favour of attempting to guess how the thing will be implemented. | > When a news item is read, its name should be removed from the | > ``news.unread`` file. News clients may add the name to a | > ``news.read`` file in the same directory with the same file format. | | news.read should either be mandatory or not created at all. Should a | user change from a reader that creates and uses the file to one that | doesn't and then change back again the results will be unexpected. I'm not sure that that's the case. With a news to email forwarder, for example, it wouldn't make sense to keep track of news.read. | > * Important: there are 5 unread news items. | > * Type emerge --help news to learn how to read news files. | [...] | > An ``eselect`` [#eselect]_ module shall be created as the | > 'suggested' display tool; other display tools (for example, a news | > to email forwarder, which would be ideal for users who sync on a | > ``cron``) are left as options for those who desire them. | | By "suggested" you mean that it should be referenced in the news help? News help, handbook etc, yes. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
Luca Barbato wrote: > Ciaran McCreesh wrote: >> >> * Anything involving XML. >> > > What about incidentally make the format yaml compatible? > > yaml.org Only if we (you?) are able to extract a considerably simpler subset of the specification, as is it's really overkill. > > /me runs where ? gentoo devs are everywhere ... mwhuaahahahah -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On 12/11/05, Wernfried Haas <[EMAIL PROTECTED]> wrote: > On Sun, Dec 11, 2005 at 01:35:50AM +, Ciaran McCreesh wrote: > > Although most package updates are clean and require little user action, > > occasionally an upgrade requires user intervention during the upgrade > > process. > > Recent examples of the latter include the ``gcc-3.4`` stabilisation on > > ``x86`` > > and the ``mysql-5`` database format changes. > > > > There are currently several ways of delivering important news items to our > > users, none of them particularly effective: > > I'd suggest changing this to something more constructive - calling our > current efforts "none of them particularly effective" isn't exactly > a constructive way of critizing things. > > > * Gentoo Weekly News > > * The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists > > * The Gentoo Forums > > * The main Gentoo website > > * RSS feeds of Gentoo news > > Einfo is currently being used for that purpose as well - even if the > GLEP will leave it for less important news in the future. So i guess > it should be listed here. > > > A more reliable way of getting news of critical updates out to users is > > required > > to avoid repeats of the various recent upgrade debacles. > > As it was mentioned above, gcc 3.4 went pretty well on x86, can't > comment on mysql as i don't use it myself. I'd suggest changing this > text for something more diplomatic as i don't see much sense in having > council approved GLEPs talking about council approved upgrade debacles. > I'd suggest: > "A more reliable way of getting news of critical updates out to users is > required > to prevent problems during upgrades." My opinion? The gcc-3.4 upgrade has appeared to go fairly well because it doesn't automagically upgrade, it requires manual intervention before it is used. People see this and investigate. This is not something that always happens (apache anyone?, baselayout ~arch anyone?) And due to this, I don't believe we can judge success on the gcc upgrade alone. > > > .. Important:: This GLEP does not seek to replace or modify ``einfo`` > > messages > >which are displayed post-install. That is a separate issue which is > > handled > >by ``elog`` [#bug-11359]_. > > Thanks for clearing this quite important point up. > > > Thus, at least 72 hours before a proposed news item is committed, it must be > > posted to the ``gentoo-dev`` mailing list and ``Cc:``\ed to [EMAIL > > PROTECTED] > > (exceptions may be made in exceptional circumstances). Any complaints ??? > > for > > example regarding wording, clarity or accuracy ??? **must** be addressed > > before > > the news item goes live. > > I know you think it is beyond the scope of this GLEP, but i believe > having a new tool with rules for publication and OTOH all the > old tools mentioned above without clear guidelines/hints how to use > them doesn't make perfect sense. The gcc upgrade on x86 has shown so > far that combining our efforts does work quite well. Even if not > within this GLEP there should be some documentation how to make use of > all available tools to inform users. Otherwise we just have another > tool that gets more or less acceptance within the community. > > I'd suggest extending the process of creating a news item to also > create a text to be posted to www.gentoo.org, the > announce-mailinglist, the forums, RSS feeds, GWN, etc. Of course > depending on the importance it may be decided to e.g. not post it > on announce but only www.gentoo.org. > > Do you think this can be done within this GLEP or rather outside? > > 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 > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sun, Dec 11, 2005 at 01:35:50AM +, Ciaran McCreesh wrote: > Although most package updates are clean and require little user action, > occasionally an upgrade requires user intervention during the upgrade process. > Recent examples of the latter include the ``gcc-3.4`` stabilisation on ``x86`` > and the ``mysql-5`` database format changes. > > There are currently several ways of delivering important news items to our > users, none of them particularly effective: I'd suggest changing this to something more constructive - calling our current efforts "none of them particularly effective" isn't exactly a constructive way of critizing things. > * Gentoo Weekly News > * The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists > * The Gentoo Forums > * The main Gentoo website > * RSS feeds of Gentoo news Einfo is currently being used for that purpose as well - even if the GLEP will leave it for less important news in the future. So i guess it should be listed here. > A more reliable way of getting news of critical updates out to users is > required > to avoid repeats of the various recent upgrade debacles. As it was mentioned above, gcc 3.4 went pretty well on x86, can't comment on mysql as i don't use it myself. I'd suggest changing this text for something more diplomatic as i don't see much sense in having council approved GLEPs talking about council approved upgrade debacles. I'd suggest: "A more reliable way of getting news of critical updates out to users is required to prevent problems during upgrades." > .. Important:: This GLEP does not seek to replace or modify ``einfo`` messages >which are displayed post-install. That is a separate issue which is handled >by ``elog`` [#bug-11359]_. Thanks for clearing this quite important point up. > Thus, at least 72 hours before a proposed news item is committed, it must be > posted to the ``gentoo-dev`` mailing list and ``Cc:``\ed to [EMAIL PROTECTED] > (exceptions may be made in exceptional circumstances). Any complaints ??? for > example regarding wording, clarity or accuracy ??? **must** be addressed > before > the news item goes live. I know you think it is beyond the scope of this GLEP, but i believe having a new tool with rules for publication and OTOH all the old tools mentioned above without clear guidelines/hints how to use them doesn't make perfect sense. The gcc upgrade on x86 has shown so far that combining our efforts does work quite well. Even if not within this GLEP there should be some documentation how to make use of all available tools to inform users. Otherwise we just have another tool that gets more or less acceptance within the community. I'd suggest extending the process of creating a news item to also create a text to be posted to www.gentoo.org, the announce-mailinglist, the forums, RSS feeds, GWN, etc. Of course depending on the importance it may be decided to e.g. not post it on announce but only www.gentoo.org. Do you think this can be done within this GLEP or rather outside? 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
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
Ciaran McCreesh wrote: * Anything involving XML. What about incidentally make the format yaml compatible? yaml.org /me runs lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sunday 11 December 2005 10:35, Ciaran McCreesh wrote: > Whenever relevant unread news items are found, the package manager will > create a file named ``/var/lib/portage/news/news.unread`` (if it does not > already exist) and append the news item identifier (eg > ``2005-11-01-yoursql-updates``) on a new line. > > .. 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... > When a news item is read, its name should be removed from the > ``news.unread`` file. News clients may add the name to a ``news.read`` file > in the same directory with the same file format. news.read should either be mandatory or not created at all. Should a user change from a reader that creates and uses the file to one that doesn't and then change back again the results will be unexpected. > * Important: there are 5 unread news items. > * Type emerge --help news to learn how to read news files. [...] > An ``eselect`` [#eselect]_ module shall be created as the 'suggested' > display tool; other display tools (for example, a news to email forwarder, > which would be ideal for users who sync on a ``cron``) are left as options > for those who desire them. By "suggested" you mean that it should be referenced in the news help? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP 42 (Critical news reporting) updates
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 GLEP: 42 Title: Critical News Reporting Version: $Revision: $ Author: Ciaran McCreesh <[EMAIL PROTECTED]> Last-Modified: $Date: $ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 31-Oct-2005 Post-History: 1-Nov-2005, 5-Nov-2005, 7-Nov-2005, 11-Dec-2005 Abstract This GLEP proposes a new way of informing users about important updates and news regarding tree-related items. Motivation == Although most package updates are clean and require little user action, occasionally an upgrade requires user intervention during the upgrade process. Recent examples of the latter include the ``gcc-3.4`` stabilisation on ``x86`` and the ``mysql-5`` database format changes. There are currently several ways of delivering important news items to our users, none of them particularly effective: * Gentoo Weekly News * The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists * The Gentoo Forums * The main Gentoo website * RSS feeds of Gentoo news A more reliable way of getting news of critical updates out to users is required to avoid repeats of the various recent upgrade debacles. This GLEP proposes a solution based around pushing news items out to the user via the ``rsync`` tree. .. Important:: This GLEP does not seek to replace or modify ``einfo`` messages which are displayed post-install. That is a separate issue which is handled by ``elog`` [#bug-11359]_. Requirements An adequate solution must meet all of the following requirements: Preemptive Users should be told of changes *before* they break a system, not after the damage has already been done. Ideally, the system administrator would be given ample warning to plan difficult upgrades and changes, rather than only being told just before action is necessary. No user subscription required It has already been demonstrated [#forums-apache2]_ that many users do not read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution which requires subscription has no advantage over current methods. No user monitoring required It has already been demonstrated [#forums-apache2]_ that many users do not read news items posted to the Gentoo website, or do not read news items until it is too late. A solution that relies upon active monitoring of a particular source has no advantage over current methods. Relevant System administrators who do not use a particular package should not have to read news items which affect purely that package. Some news items may be of relevance to most or all users, but those that are not should not be forced upon users unnecessarily. Lightweight It is not reasonable to expect all users to have an MTA, web browser, email client, cron daemon or text processing suite available on their system. Users must not be forced to install unreasonable extra software to be able to read news items. No privacy violations Users of the solution should not be required to provide information about their systems (for example, IP addresses or installed packages). Multiple delivery method support Some users may wish to view news items via email, some via a terminal and some via a web browser. A solution should either support all of these methods or (better still) make it simple to write clients for displaying news items in different ways. The following characteristics would be desirable: Internationalisable Being able to provide messages in multiple languages may be beneficial. Quality control There should be some way to ensure that badly written or irrelevan
