Re: [gentoo-dev] Re: Improving Gentoo User Relations
On 07-04-2006 11:07:28 +0100, Ciaran McCreesh wrote: I mean, as a purely hypothetical example... Could you imagine just how many dumb feature requests, questions and requests for code from the unwashed masses someone would get if they admitted to having an early alpha of an alternative to Portage that didn't require Python? Having to deal with the noise would be more than enough to ensure that no more development would ever get done... This is ofcourse a purely hypothetical prediction for a hypothetical example. Another hypothesis might be that noone would care about the hypothetical alternative to Portage, hence no developer obstruction would take place at all. Yet another hypothesis might be that there would actually exist a few smart users that give some smart comments on the, in this case hypothetical, product. Maybe user-rel should, together with GWN bridge this problem by keeping the source of news anonymous? Just to use it as teasers of what kind of things are being done in Gentoo's kitchen? Of course this only holds for new projects like in your hypothetical example. Existing projects, like KDE and GCC probably already deal with questions from users, and giving a status update once a month would in my opinion help them to keep users both informed and interested, which is what the original poster meant I think. From a user-rel perspective the information is used to inform the users that they're not waiting in vain for something not to happen, as well as why they are waiting, for example. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Gentoo wants YOU! (for GNUstep)
On 19-03-2006 11:16:10 +0100, Grobian wrote: I would really like to see a new GNUstep maintainer [...] Gentoo is now officially looking for people interested to maintain, expand (*and FIX* :) ) GNUstep applications on Gentoo. We expect interested persons to be willing to maintain GNUstep in a long lasting relationship with the project. ;) Interested participants can have a look at our staffing needs page [1], and continue from there. Interest to get GNUstep apps compiling/running on other platforms than GNU/Linux is a pre. [1] http://www.gentoo.org/proj/en/devrel/staffing-needs/ -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Global logrotate use flag
Have a look at these: http://thread.gmane.org/gmane.linux.gentoo.devel/27451 http://thread.gmane.org/gmane.linux.gentoo.devel/30090 On 21-03-2006 14:19:31 +0100, Jeroen Roovers wrote: Hi everyone, I noticed 'logrotate' is becoming quite generic as a use flag: -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Savannah CVS changes and the missing GNUStep herd
Unless somebody else wants to do it, I am about to step in here to keep GNUstep in the tree. I already did some research on it, and it seems it needs an update, and the previous maintainer masked a few of the CVS ebuilds, so that eases things a bit. Seems many of the packages can use an upgrade, so I'll give it a try today to see if I can get it working again. I'm going to look into more detail to it today, so if someone has objections, please state them now. I would really like to see a new GNUstep maintainer, but I'm not in the desktop herd or something, neither a frequent user of GNUstep any more. On 19-03-2006 03:23:26 +0100, Fabian Borschel wrote: Hi Devs, On 2006-03-18 12:53:09 +0100 Henrik Brix Andersen [EMAIL PROTECTED] wrote: However, since the GNUStep herd is void, no one has stepped up to fix those ebuilds - meaning we have a bunch of useless, non-functional, live CVS ebuilds laying around in portage, see the list below. Did you look into bugs.gentoo.org? There are new ebuild (which don't use CVS). Maybe not for all GNUstep ebuilds, but there are users who are interested in GNUstep stuff (take me for an example). If you search a new maintainer I would do the job. But I'm no Gentoo-Dev yet. Regards, Fabian -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] x86-fbsd keyword in main tree?
On 09-03-2006 12:30:33 -0500, Alec Warner wrote: Regardless, I'd like to reach a conclusion about this, was GLEP 47 submitted to the council for the next meeting? As far as I know: no. I didn't myself because I'm having a problem with ppc-macos and the upcoming x86-macos (they will probably have a lot in common) and am not completely sure whether what Diego and I proposed is actually flexible enough. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Emanuele Giaquin (exg)
At last... :) Welcome Emanuele! On 06-03-2006 20:41:28 +0100, [EMAIL PROTECTED] wrote: Hi all. Slightly late but never the less I'd like to introduce Emanuele Giaquinta (exg) who joined the team a few weeks ago. Emanuele will be working on Gentoo/OSX and ppc stuff when he's not making up weird potions :) Before joining Gentoo Emanuele has contributed to gentoo, rxvt-unicode and other free software/open source projects. Emanuele is a 23 year old student in computer science at the university of Catania, in Italy. Besides spending time on Gentoo he's fond of manga/anime, listening/playing music, poetry and mysticism. Welcome to the team Emanuele :) Regards, Bryan Østergaard -- Fabian Groffen Gentoo for Mac OS X Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On 02-03-2006 20:19:19 +, Ciaran McCreesh wrote: On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | I'm also convinced that deliberate circumvention is easy to detect. In that case, please provide a list of cases where !arch? flags are being used to circumvent repoman warnings, where the correct solution Circumvent? Can you elaborate on that? repoman does have a problem with this, while portage does not. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On 13-02-2006 21:02:28 +0100, Carsten Lohrke wrote: On Monday 13 February 2006 20:29, Grobian wrote: Maybe that has to change then? Like getting more bug wranglers that also handle canned responses as a first-line helpdesk? Wrangle bugs a few months and you'll see how hard it can be to stay friendly sometimes... That's what I said two posts ago. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On 11-02-2006 20:05:58 +, Ciaran McCreesh wrote: On Sat, 11 Feb 2006 08:28:34 +0100 Grobian [EMAIL PROTECTED] wrote: | kfreebsd-gnu is, in effect, one example you're using already. You'd | have x86 as the arch, FreeBSD as the kernel and GNU as the userland. | | Yes, but you're actually mixing two things here now. The right hand | side of the 2-tuple is not a kernel or userland, it is an OS, which | includes this in itself. Mm. I'm not convinced that that justifies creating weird codes for the weird cases... Ok. If we're on the same wave length here, then I think the real question is here whether we do allow hyphens to be in the os part or not. If yes, the part till the first hyphen is the arch, and everything from the hyphen (exclusive) till the end of string is the os part. If no, an 'escape' method must be defined for the os part. In both cases it is necessary to state that the arch cannot contain hyphens in it, and if such restriction is defined, it might be handy to immediately add spaces and the like to the list. -- Fabian Groffen Gentoo/Alt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On 09-02-2006 23:50:08 +, Ciaran McCreesh wrote: On Thu, 9 Feb 2006 22:48:32 +0100 Grobian [EMAIL PROTECTED] wrote: Instead of proposing a 4-tuple [3]_ keyword, a 2-tuple keyword is chosen for archs that require them. Provision should be made for future ports that require more than two keywords. There's no particular reason to artificially limit this to two at this stage. Can you come up with an example? Unlike Diego, I think this limitation is good, because it defines the format, which makes parsing and such easy. I can't think of an example that doesn't fit in 2-tuple keywords, and if there would be, perhaps that makes this whole GLEP 'unstable', and hence should be replaced completely then. Last but not least, if it doesn't fit in a 2-tuple, then the keyword is probably misused for something it wasn't meant for -- at least as far as I can see right now. Examples of how this lot is to be used in DEPEND= etc would be good for clarity. Ok, I assume you just want to see something like: DEPEND=ppc-macos? ( dev-libs/libpcre ) or DEPEND=x86? ( dev-libs/libpcre ) If not, then I don't understand where you're aiming at. You should clarify the env map behaviour when multiple matches all occur (first match, last match or merge?). This is a good point that deserves an example and some careful thoughts, as I'm not sure now if it makes sense to have such situation. In any case, it should be precisely defined. You should probably clarify whether the map is part of Portage itself or in the tree. If it has to be part of Portage, explain why. I think Diego said something about this already, but I'll give it some thoughts. There're various English issues too where things don't scan clearly to a native reader, but it's probably not worth fixing them at this stage. Let me know when you reach the point where using precise language is important and I'll make a list. I'll first go through a couple of iterations, then we'll see where we end up. Thanks for the offer anyway. -- Fabian Groffen Gentoo/Alt -- Under a Mackintosh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On 10-02-2006 00:38:47 +, Ciaran McCreesh wrote: On Thu, 09 Feb 2006 19:26:11 -0500 Alec Warner [EMAIL PROTECTED] wrote: Assuming the CHOST variable is 'safe' is not a good thing, users can over-ride this variable. Can you specify some behavior when it's set to something bogus ( invalid form ) or something thats not in the mapping? Users that override CHOST to something outside of one of the safe forms (or at all, on many archs) won't be able to compile anything anyway. On 10-02-2006 01:38:54 +0100, Diego 'Flameeyes' Petten wrote: Users can change CHOST, but if they do in the wrong way, they can do way more damage than just this. Indeed. But this reason is worth a note in the GLEP. I'll add it as grounding why we assume CHOST is 'safe'. -- Fabian Groffen Gentoo/Alt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On 10-02-2006 11:00:33 +0100, Diego 'Flameeyes' Petten wrote: On Friday 10 February 2006 09:00, Kevin F. Quinn (Gentoo) wrote: Could you add a definition of 'safe' to the GLEP? It's not clear what this means at the moment. Variables that can be counted on, as users can't change them in unexpectable ways without hacking the tree :) I'll try to deal with it in the same part that deals with the CHOST assumption. -- Fabian Groffen Gentoo/Alt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 47: Creating 'safe' environment variables
On 10-02-2006 01:30:40 -0700, Duncan wrote: Grobian posted [EMAIL PROTECTED], excerpted below, on Thu, 09 Feb 2006 22:48:32 +0100: .. [3] For the purpose of readability, we will refer to 1, 2 and 4-tuples, even though tuple in itself suggest a field consisting of two values. For clarity: a 1-tuple describes a single value field, while a 4-tuple decribes a field consisting out of four values. OK, despite the given reasoning, I found this distracting. Perhaps this is one of Ciaran's English readability suggestions, but is there a reason not to s/segment/tuple/g ? That seems to me more accurate, segment is more accessible English to non-programmers than tuple, and it should cure the distraction problem I experienced. Of course, it could be just me... I assume you meant to replace 'tuple' with 'segment'. First of all, I might be biased, as for me everything is a binary association table. However, I don't think a segment is the same in this case. 'part' would be better, perhaps. In the end I think GLEPs are targetted at programmers: those of Gentoo, as such it is not targetted at a broad (and generic) audience at all. I prefer to stick with 'tuples' for now. If the current usage, and thus the footnote, is retained, there's a typo in the last line quoted. s/decribes/describes/ (which I only caught when the spellchecker hilighted it in the quote as I replied). Thanks, got it. -- Fabian Groffen Gentoo/Alt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On 10-02-2006 20:22:06 +, Ciaran McCreesh wrote: On Fri, 10 Feb 2006 19:25:47 +0100 Grobian [EMAIL PROTECTED] wrote: | On 09-02-2006 23:50:08 +, Ciaran McCreesh wrote: | On Thu, 9 Feb 2006 22:48:32 +0100 Grobian [EMAIL PROTECTED] | wrote: | Instead of proposing a 4-tuple [3]_ keyword, a 2-tuple | keyword is chosen for archs that require them. | | Provision should be made for future ports that require more than two | keywords. There's no particular reason to artificially limit this to | two at this stage. | | Can you come up with an example? kfreebsd-gnu is, in effect, one example you're using already. You'd have x86 as the arch, FreeBSD as the kernel and GNU as the userland. Yes, but you're actually mixing two things here now. The right hand side of the 2-tuple is not a kernel or userland, it is an OS, which includes this in itself. macos (even though the x is missing) implies a darwin kernel, and mixed BSD/GNU userland. If you really want to have kernel and userland in the keyword, then the definition of the keyword should be different, and probably state that it is always a 3-tuple and that the defaults are 'linux' and 'gnu' for the 2nd and 3rd fields respectively. I argue however, that this is not necessary, hence a 2-tuple of arch-os is enough to just distinguish it from the others, while also being descriptive to human readers. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP 47: Creating 'safe' environment variables
Please find attached GLEP 47: Creating 'safe' environment variables.
The GLEP is a Gentoo/Alt initiative. Constructive comments are welcome.
--
Fabian Groffen
Gentoo/Alt
GLEP: 47
Title: Creating 'safe' environment variables
Version: $Revision: 1.1 $
Last-Modified: $Date: 2006/02/09 21:42:57 $
Author: Diego Pettenò, Fabian Groffen {flameeyes,[EMAIL PROTECTED]
Status: Active
Type: Standards Track
Content-Type: text/x-rst
Created: 14-Oct-2005
Post-History:
Credits
===
The text of this GLEP is a result of a discussion and input of the
following persons, in no particular order: Mike Frysinger, Diego
Pettenò, Fabian Groffen and Finn Thain.
Abstract
In order for ebuilds and eclasses to be able to make host specific
decisions, it is necessary to have a number of environmental variables
which allow for such decisions. This GLEP introduces some measures that
need to be made to make these decisions 'safe', by making sure the
variables the decisions are based on are 'safe'. A small overlap with
GLEP 22 [1]_ is being handled in this GLEP where the use of 2-tuple
keywords are being kept instead of 4-tuple keywords. Additionally, the
``ELIBC``, ``KERNEL`` and ``ARCH`` get auto filled starting from
``CHOST`` and the 2-tuple keyword, instead of solely from they 4-tuple
keyword as proposed in GLEP 22.
The destiny of the ``USERLAND`` variable is out of the scope of this
GLEP. Depending on its presence in the tree, it may be decided to set
this variable the same way we propose to set ``ELIBC``, ``KERNEL`` and
``ARCH``, or alternatively, e.g. via the profiles.
Motivation
==
The Gentoo/Alt project is in an emerging state to get ready to serve a
plethora of 'alternative' configurations such as FreeBSD, NetBSD,
DragonflyBSD, GNU/kFreeBSD, Mac OS X, (Open)Darwin, (Open)Solaris and so
on. As such, the project is in need for a better grip on the actual
host being built on. This information on the host environment is
necessary to make proper (automated) decisions on settings that are
highly dependant on the build environment, such as platform or as in
[2]_.
Rationale
=
Gentoo's unique Portage system allows easy installation of applications
from source packages. Compiling sources is prone to many environmental
settings and availability of certain tools. Only recently the Gentoo
for FreeBSD project has started, as second Gentoo project that operates
on a foreign host operating system using foreign (non-GNU) C-libraries
and userland utilities. Such projects suffer from the current implicit
assumption made within Gentoo Portage's ebuilds that there is a single
type of operating system, C-libraries and system utilities. In order to
enable ebuilds -- and also eclasses -- to be aware of these
environmental differences, information regarding it should be supplied.
Since decisions based on this information can be vital, it is of high
importance that this information can be trusted and the values can be
considered 'safe' and correct.
Backwards Compatibility
===
The proposed keywording scheme in this GLEP is fully compatible with the
current situation of the portage tree, this in contrast to GLEP 22. The
variables provided by GLEP 22 can't be extracted from the new keyword,
but since GLEP 22-style keywords aren't in the tree at the moment, that
is not a problem. The same information can be extracted from the CHOST
variable, if necessary. No modifications to ebuilds will have to be
made.
Specification
=
Unlike GLEP 22 the current keyword scheme as used in practice is not
changed. Instead of proposing a 4-tuple [3]_ keyword, a 2-tuple
keyword is chosen for archs that require them. Archs for which a
1-tuple keyword suffices, keep that keyword. Since this doesn't change
anything to the current situation in the tree, it is considered to be a
big advantage over the 4-tuple keyword from GLEP 22. This GLEP is an
official specification of the syntax of the keyword.
Keywords will consist out of two parts separated by a hyphen ('-'). The
left hand part of the keyword 2-tuple is the architecture, such as
ppc64, sparc and x86. The right hand part indicates the operating
system or distribution, such as linux, macos, darwin, obsd, etc. If the
right hand part is omitted, it implies the operating system/distribution
type is GNU/Linux. In such case the hyphen is also omitted. Examples
of such keywords are ppc-darwin and x86. This is fully compatible with
the current keywords used in the tree.
The variables ``ELIBC``, ``KERNEL`` and ``ARCH`` are currently set in
the profiles when other than their defaults for a GNU/Linux system.
They can as such easily be overridden and defined by the user. To
prevent this from happening, the variables should be auto filled by
Portage itself, based on the ``CHOST`` variable.
A map file can be used to have the various ``CHOST`` values being
translated to the correct values for the four variables. This change is
Re: [gentoo-dev] coreutils: deprecated behavior not so deprecated
On 27-01-2006 08:44:14 -0500, Mike Frysinger wrote: On Monday 23 January 2006 23:04, Mike Frysinger wrote: for those who dont know what i'm talking about, consider: tail -1 head -1 some other stuff i cant remember it would seem i lied about this (at least the first two still work) FYI: sort +0 doesn't work anymore. Not sure, but it seems to control the sorting order, sort +1 sorts reverse, all the rest normal. autofs uses this in the auto.net script, which causes the automounter to get broken. Bug #120403. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sed vs gsed
On 25-01-2006 09:19:44 +0100, Diego 'Flameeyes' Pettenò wrote: On Wednesday 25 January 2006 06:47, Mike Frysinger wrote: Diego was mistaken here ... probably my fault because i lied to him at some point on irc, who knows for sure ... at any rate, the sed ebuild does not install 'gsed' on GNU systems I was pretty sure we decided to go with g-prefixed for tar, sed and make for GNU systems, too (and it's what it's being done by gawk, gmake and so on). I actually have gsed locally, but it might be some trace from the old g/fbsd overlay at this point... So this makes the things more complex again. Time to rethink all of that, what you think? I think that the g-prefixed installs are a big pain, unless you can interface to them, like epatch does. However, you can't because the exec call of a process doesn't use a shell. It appears that some people don't agree with you on changing the assumptions made in the current portage tree. Solution to this is making the GNU tool the default for portage known under its non-g-prefixed name, such that the assumptions made in the tree hold. Maybe it's just the path of least resistance... The profit of having a tree that works with any implementation of awk, sed, find, xargs, etc. is perhaps too small for the actual work and sacrifices needed for it. -- Fabian Groffen Gentoo for Mac OS X Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: tcsh vs. csh, removal of the latter
On 25-01-2006 16:19:54 -0500, Mike Frysinger wrote: On Wednesday 25 January 2006 15:47, Stuart Herbert wrote: The csh package currently has a maintainer who is an active Gentoo developer; have you spoken to taviso first to find out whether he wants to remove csh from the tree? last we talked with taviso he had no problem punting csh I probably should have said that there is a bug that is triggering this problem, and that taviso indeed was happy to remove it from his maintenance list, hence the perhaps drastically sounding solution for a seemingly small problem. Sorry about that. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
You better bring this up on the gentoo-alt mailing list. Please consider posting it there instead of going in a private discussion. On 06-01-2006 08:15:42 -0700, Duncan wrote: And I definitely wish you well in your G/FBSD efforts, but when I mentioned them on my local ISP's unix (*ix) group, the FBSD groupies reaction was Yuck! Tell me, from someone who obviously has some FBSD experience, what advantages does Gentoo/FreeBSD have over the normal FreeBSD? Why would someone use it who is currently using regular FreeBSD, and why are you spending the time? There are obviously reasons, as you're a very talented person spending quite a bit of time on the project, but equally obviously, I'm not familiar enough with them to make a good G/FBSD representative, at this point. (If you like and don't consider this topical for the list or thread, mail me. If I have the question, however, it's possible others do as well, and just haven't asked, so maybe it is worth keeping to the list. Whatever. /I'm/ interested, anyway.) TIA -- Fabian Groffen Gentoo/Alt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: regular project updates
On 05-01-2006 17:00:15 +0100, Patrick Lauer wrote: So - as GWN monkey - I'm offering my services as aggregator for project updates. Maybe someone from the doc project wants to help to get this information put on the website so that it's visible? The following crossed my mind: what about a Developers release of the GWN? I see you guys scouring the planet, MLs and whatever more, but not all information there is user-friendly, or just a 'good idea' to tell the users about. I'd really like to see an aggregation of stuff from all kinds of sources (perhaps even including CVS/SVN commit messages) put into a monthly (or bi-weekly?) message sent to -dev for instance. It should just have some headliners for each project team, such that those who want be a bit aware of what happens in the whole of gentoo can read it, and take an active role when interested in some more information. I'm thinking of quite dull news, so absolutely not meant to be a publication like GWN, but just thingis like some commits on the portage sources that say to fix/implement X, a discussion on project ML Y working on Z. Also for instance that Flameeyes has been working on something with --as-needed; just what it is, and why, from planet. Perhaps even a short note that after +-150 commits the tree has been upgraded to XOrg-7_rc1 or something... that can be useful information, even though it does look like spam. This kind of information is all of the type background noise, hence it dull, but can be very important for those that are open to it. I would just be interested in such a thing, because I'd like to read some few lines per month on projects, but not whole MLs and every dev's Blog. Of course it's just shifting the problem of not wanting to read everything to someone else... but IMHO it does improve communication for those open to read the Gentoo Developer Notes (or something like that). Just a thought. No idea whether you really meant to do something like this. Would like you to do it though ;) -- Fabian Groffen Gentoo/Alt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: regular project updates
On 05-01-2006 16:41:12 +, Ciaran McCreesh wrote: On Thu, 5 Jan 2006 17:28:13 +0100 Grobian [EMAIL PROTECTED] wrote: | I'm thinking of quite dull news, so absolutely not meant to be a | publication like GWN, but just thingis like some commits on the | portage sources that say to fix/implement X, a discussion on project | ML Y working on Z. Would our users really like to read a lengthy discussion on the intricacies of the changes made to versionator.eclass to improve performance, or the way in which the ten zillion packages needed by the new KDE/Gnome/Xorg release were keyworded for a particular arch, or the design decisions made for vim-spell.eclass to avoid requiring that our users have four gigs of RAM? I mean, it'd be pretty frickin' boring... Probably not, that's what I wrote that I really don't like it to be targetted (and sent to) users. I myself, on the other hand, *would* like to read that. -- Fabian Groffen Gentoo/Alt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On 02-01-2006 20:03:54 +0100, Patrick Lauer wrote: On Mon, 2006-01-02 at 12:50 -0600, Lance Albertson wrote: I guess I'm almost hinting at that Gentoo needs a single entity that's sole purpose is to drive/research the direction and goals for Gentoo. Or call it proper hierarchy. Management. Probably all evil words, in this context, but they for sure apply. It'd be almost ceo-like, but the council is still top dawg. Right now, I view our group as a bunch of chiefs with no real single leader saying lets strive to do this. The main problem is, too many people fear about such a person could turn into a dictator, so I'm not sure if this could ever happen. I wonder if any single person would be accepted? If it isn't one person, then you would need to find two persons or even more that are completely aligned and have the same visions. Since leaders usually are charismatic and controversial where necessary to achieve their goals, it is hard to find two that don't get conflicts, stalling any vision to become a mission. After all there is noone capable of forcing anyone to do anything as far as I can tell - worst case you fork Gentoo (again) and don't resolve the issues. ...or only resolve the ones that you care about. Your first sentence forms the basis of the problem, IMHO. This person would be in constant contact of all the groups and try to muck together what everyone is doing. They could suggest things to help minimize user impact, maybe try to join two projects if they are both working on a similar goal, thus minimizing the workload. Stuff like that essentially. Communication ... should happen anyway, but it seems to get more and more difficult. Another layer of bureaucracy won't help that ... Call it bureaucrazy, or whatever you like. I think it has nothing to do with bureaucracy at all. It's just a matter of having communication on a high level, in order to get an overall view of Gentoo. IIRC this is one of the tasks of the council, to align teams somehow, for example. We need a good visionary. If such a position were created, I also think that person's sole focus should be that focus within Gentoo. (i.e. they aren't a major contributor for a subproject in Gentoo). This position would take too much time for them to keep those other duties. ... and you'd burn out a capable person within half a year I think Depends on the person. Lance is just putting a lot of Mintzberg and probably (work) experience on the table to apply it to Gentoo. But ok, fine, if that's the case, gives a nice refresh rate :) (j/k) Dunno, maybe I'm the loner here thinking this... Well, you're not alone for sure ;) However, the amount of measures to take, why and what are a bit of an open question to me. I do, however, share your concerns of a missing 'Mission Statement'. It is a commonly known problem and primary point of concern (ie. Heene). -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On 02-01-2006 21:12:03 +0100, Patrick Lauer wrote: If it isn't one person, then you would need to find two persons or even more that are completely aligned and have the same visions. Since leaders usually are charismatic and controversial where necessary to achieve their goals, it is hard to find two that don't get conflicts, stalling any vision to become a mission. To extrapolate from that ... council etc. are incapable of doing real work? ;-) Or in other words, a person is smart, people are dumb Your words here. I don't follow your logic, and I don't see where your statement comes from. I want to make explicit that -- in any case -- I didn't mean my words like that. Dunno, maybe I'm the loner here thinking this... Maybe a bit idealistic, but I mostly agree :-) Well, you're not alone for sure ;) However, the amount of measures to take, why and what are a bit of an open question to me. I do, however, share your concerns of a missing 'Mission Statement'. It is a commonly known problem and primary point of concern (ie. Heene). I guess we should decide on a problem before solving it :-) Is the problem the lack of a mission statement? I don't see the need for that, we all have our own definitions what a Gentoo is and why it's cool. Trying to get that defined will be really tricky (and I predict a smallish flamewar) I reinserted your first response. It looks like you changed your mind inbetween to me, and that you probably don't agree 'mostly' anymore? We already have a mission statement - to produce the best software distribution, ever ;-) Wether it should be Linux only, GNU-based or a metadistribution is a rather touchy subject, so please try to keep the discussion civilized ... Lance mentioned something about what he sees is a niche where Gentoo does quite well. Produce the best software distribution, ever sounds a bit vague to me. That's why I agree with Lance for now. Maybe after a little research, trial and error period it turns out to be better to keep the target vague. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ChangeLogs and rsync time
On 01-01-2006 21:35:34 +0100, Francesco Riosa wrote with possible deletions: The information contained in the ChangeLogs is essential, and it must be kept, but, force the users to download all that data it's not optimal. That said I can see only two ways to reduce the ChangeLog files (a centralized one is obviously not viable) 1) bzip2 them in some way. 2) rotate Changelogs, keeping only the last changes, until a size or 3) remove entries for non-existing ebuilds This may, or may not be a good idea, but it is founded on the following observation: currently old or redundant ebuilds are removed from the tree. Once that happens, they don't show up in the rsync tree and are only available through the (centralised) CVS Attic. One can argue that Changelog entries for non-existing ebuilds are not of any use, since the files they refer to aren't present. This method would clean up the Changelog entries, in the same way ebuilds are removed, and CVS keeps the history around. 4) compress Changelog entries where possible Often, a package is marked testing or stable on request via a bug. This usually results in having as much as new Changelog entries as there are arch teams involved. These kind of entries, that all more or less report 'Marked arch' could be merged into one, given that the information itself is Changelog-worthy anyway. (This is arguable IMHO.) This method may involve a lot of fuzzy matching to perform it automatically, with its related risks. The win for the large Changelog files is probably minimal. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Allow upstream tags in metadata.xml
On 26-12-2005 22:11:46 -0200, Marcelo Ges wrote: Fellow Gentooers, Here is a draft of an enhancement proposal that should allow upstream information to be included in metadata.xml: http://dev.gentoo.org/~vanquirius/glep-0099.txt using http://www.gentoo.org/proj/en/glep/glep-0046.html The bugs-to tag can hold either an email address or URL. Not a big issue, but why not make it an URI, such that an email address is written as mailto:[EMAIL PROTECTED]? Using an URI gives a nice specified format (already including the http(s) which you require) and should go with regular URI parsers. Given the URI thing, maybe it can be useful to define the changelog tag to have an URI as well, since some upstreams ship the changelog with the sources and don't put them on the web. In such case you might want to use a file:// URI to point to the file on disk when installed? I realise this is tricky. Not clear from the text, but I take it from the example that remote-id has an attribute named type which points to some source. Is there a reason to make that an attribute, instead of a tag? Also, the remote-id tag in the example has a TEXT node which apparently is the id, but needs some information in order to track it. Taking your SourceForge example: remote-id type=sourceforgeadium/remote-id Usually for SourceForge means that adium in this case is the UNIX project name, hence an URL such as http://sourceforge.net/projects/adium points to the project's SourceForge home, while http://adium.sourceforge.net/ points to the project's home page. It's not clear for me where this is different from the home page URL in the ebuild itself. I don't know if FreshMeat can be a real project home. What I wanted to say, where is the logic stored on how to make this id into some resource? And if you store that logic somewhere, why not in the XML structure? Any reason to use an id, and not for instance an URI to the remote 'developers' homepage/resource? Observation: the added data is mainly targetted at developers, not users. Given the ongoing discussion, this might be an interesting side note. In an overlay I'm currently keeping 'portnotes' in metadata.xml, which basically give us developers a quick look on what was necessary to port an ebuild. This is by no means interesting for a regular user, and we put it in metadata.xml because that allows to group the portnotes, since XML is a bit more structured than a changelog. For the sake of rsyncs/speed/storage/whatever, perhaps this purely targetted at developers information should be put in a separate file, which is by default excluded in the rsync? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Misquoted in the GWN
On 28-11-2005 18:54:14 +, Ciaran McCreesh wrote: On Mon, 28 Nov 2005 19:46:57 +0100 Patrick Lauer [EMAIL PROTECTED] wrote: | On Mon, 2005-11-28 at 17:54 +, Ciaran McCreesh wrote: | On Mon, 28 Nov 2005 10:48:01 +0100 Henrik Brix Andersen | [EMAIL PROTECTED] wrote: | | A friend of mine just alerted me to the fact, that I am featured | | in this weeks Gentoo Weekly News. Odd, I thought, noone had asked | | me anything regarding the GWN... | | Not the first time this has happened... | | Not the first time that people whine. Meh. Yes, surprisingly enough people tend to get upset when they're misquoted and have their views utterly misrepresented in something which most users think is an official Gentoo publication. Being quoted: ok Being misquoted: very bad Having an unofficial Gentoo publication on official Gentoo infrastructure: priceless. Seriously: reading the blog entry, I made more or less the same conclusions as the GWN author, but the problem is just that the blog item was rephrased and made 'stronger', whereas the official blog was very careful in wording. (Possibly an attempt by the GWN author to make it more easily readable?) This was just wrong because it was not agreed on with the respective author, hence resulted in this thread. GWN authors need to be a bit more careful with this I think. However, I don't think that GWN authors should need permissions to grab exact quotes which are to be found elsewhere publicly available on the web. It is just sad to see that (what I assume to be) a running out of time and having no content issue results in such unpleasant misquote for the respective quoted person. One can criticise the use of newspapers, but somehow they seem to be useful for many people. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On 25-11-2005 12:14:53 +, kang wrote: Curtis Napier wrote: gentoo.org and all domains owned by the Gentoo Foundation should render correctly in all browsers that are still in general use. IE5 on the mac is still a valid browser and will be supported as much as possible. IE5 for mac contains unfixed security issues which won't be fixed (as announced by MS), how is that considered supported ? Is it even still distributed within MacOSX Tiger ? IE5:mac is a dead end, IMHO. It isn't shipped with Tiger any more, and Safari has taken it's place. This already was the case for Panther as far as I know (but Panther does ship IE I think). Since Jaguar and before are really ancient I think it's not unreasonable to let IE5:mac have a very low priority in your renderings issue fixing list. IE5:mac has always had it's own quirks, but again, it's unsupported and not maintained anymore. Camino, Safari and Firefox cover its place quite well on the Mac. Talking about Camino (which is a native Cocoa/Aqua skin for Firefox more or less), the site looks fine, only the recent changes in the font affect it negatively to me. The fonts are small in the tabs-bar and shortcut menus (Documentation, Resources and Community). The text now looks vertically misaligned to me in the tabs-bar and footer, in comparison how it was before the font size change. I could live with it. Here are some screenies of the font-sizes: http://dev.gentoo.org/~grobian/Afbeelding%204.png http://dev.gentoo.org/~grobian/Afbeelding%206.png -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Maintainer's guides?
Diego 'Flameeyes' Pettenò wrote: On Thursday 24 November 2005 21:25, Ciaran McCreesh wrote: *shrug* I'm not sure that the existing docs team is the best way of handling developer documentation. If it's just matter of fixing the English in it, I don't think there's much technical matter they would be required to think about. I'm not saying they should write *more* of it, it's just a way to clean up the form of something written by the techies. Beware that this can get tricky; sometimes it's very easy to change the meaning of a sentence by 'correcting' it. Hence a feedback loop sounds like a necessity. | Not everybody is a native English speaker, and it's stupid blaming | people for that. There doesn't seem to be any strong correlation between being a native English speaker and being able to write correct English... You might not be able to see it because you're one, so don't even try to find lame reasons. It's not _easy_ at all. If you look at the quote below, I think that it is not easy for anyone. Hence, you need designated people for such job as corrector and get a certain style for your text. | On Thursday 24 November 2005 20:50, Ciaran McCreesh wrote: | Of course, the problem | with that is that some our package maintainers couldn't stick | together a coherent English sentence even if they were paid to do | so... -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
On 21-11-2005 19:15:58 -0800, Donnie Berkholz wrote: | virtual/x11 isn't xorg for all profiles. Perhaps the relevant people (macos?) could get in touch with me, and we can figure out what needs to happen. It may be that we'll need to add x11-base/apple-xfree into the || list as well. Using the virtual is not an option right now, because of the previously mentioned bug. OSX doesn't have Xorg (yet?), so it would indeed cause some trouble for us right now. Since we're outnumbered here, I'd vote to make the change that is compatible with the majority of users right now. I'm affraid it would just boil down to dropping the ppc-macos keyword on those packages that get xorg dependency. The mentioned || list is an issue for more than xorg, so it should be considered some more IMHO. Kito, can you agree with this, or do you have another 'solution'? -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Stuart Herbert wrote: On Fri, 2005-11-11 at 18:22 -0500, Chris Gianelloni wrote: It seems to be your own quest to have the news *only* delivered by portage. I thought I'd been very clear in the email that you've replied to that I support making the news available via other ways. It's the timing that I'm a bit worried about. And that worries me. Because you more or less suggest to postpone implementing (just activating) traditional solutions, being used by many equivalent others in our field (works for them, more or less) in favour of an experimental new thing. I would just do it the other way around: do your experiment after the traditional channels are set up, and let your experiment rely on the solid base those traditional solutions give. I've managed a few change programmes over the years, and I've had the most success when a change happened in stages. The issues centre on the ability of a large body of people to understand the change that has been introduced. People find change itself confusing. If something isn't given time to bed in, people never quite understand the original change, and this undermines the benefits of introducing the change. You are probably right here. So why not doing the obvious steps? Just activate now the traditional ways of getting news to the users. In the mean-time you work on getting GLEP42 implemented and accepted, and by the time it more or less works, you have a wonderful base to announce this new feature on, and sell it as personalised sophisticated news delivery. We live and breathe Gentoo daily, and we understand this news thing because we've invested time and effort to kick it back and forward here on -dev. The vast majority of our users haven't had that luxury, and it'll take a while for them to get it. Another good reason to start with the 'common' things. The traditional ways some of your 100% of our users will be common with. Nothing new there for them. The portage way *is* new, and has never been done, hence they might have difficulties to get it. If the majority don't agree with me, not a problem; I'm not going to stop you (like I could anyway!) from putting out multi-channel from day one. But if it was my decision, I'd roll out one channel first, and the others later. See above why I think that is just the wrong order, though I support your 'phased' roll out. I'm not hoping for a 100% perfect technical solution straight away. Release early, release often is the F/OSS way. Once we've agreed on something that's fit for purpose, let's implement it, deploy it, get to the tipping point, see how users react, and then improve it. Please remember that many of your 100% of our users hates software that doesn't work. It wouldn't be the first time a user decides never to use a piece of software again, because his/her first experience with it was very bad. You'd lose a few bits of your 100% making it impossible to reach your own goal. I would seriously test this (hence not release early), if you happen to make an error and deliver all news messages at once to the user, you might end up in having the same as that very user that ignored etc-update because it had so much items to update. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 42 Critical News Reporting Round Two
Jason Stubbs wrote: To be honest, this is the part that I don't like the most. Integrating code into portage to copy files here and there based on some predefined rules and news readers reading and renaming files based on some predefined rules... A filesystem based API just doesn't seem very robust to change. I'd prefer that either the post-sync handling code is not integrated into portage and portage just triggers some external script - or - portage exposes an API (via python and bash) for accessing and updating news items. I'd prefer the latter but I get the impression that most prefer the former. - append message to /var/spool/mail/portage alternative 1 (very very sober install): - less /var/spool/mail/portage - rm /var/spool/mail/portage alternative 2 (sober install): - vi /var/spool/mail/portage alternative 3 (for those having `mail`, `mutt` or whatever that reads mbox) - mail -u portage (program allows deletion) alternative 4 (those that don't like mbox reading) - either run mbox2mail or - allow portage to write to a pipe to `mail` instead of append to /var/spool/mail/portage (would be the best solution IMHO) It doesn't have to be so complicated, IMHO. Most of the tools are already there, because traditional unix systems had this notification system built in. Imagine how nice you could benefit from a shell that tells you you've got (new) mail if you log in as root. Appending in the right format to /var/spool/mail/portage doesn't need an MTA either. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 42 Critical News Reporting Round Two
On 10-11-2005 20:55:37 +, Stuart Herbert wrote: Ok, you want a reaction, because you are Feeling Blue[1], right. On Mon, 2005-11-07 at 20:11 +0100, Grobian wrote: Ciaran McCreesh wrote: That's your first misconception right there. Most users don't sign up for things. Doesn't matter. I think it does. I believe that is the root cause of our difficulty in getting news to our users. We rely on our users coming to us to find the news. If they don't do that, they don't get the news. Our aim is to put the news in front of 100% of our userbase. Not the small fractions who check each of the places where news is currently published. You describe here (and in your diary) the aim to reach 100% of our user base. Wow, nice thing. Discussions on whether you will succeed or not, are out of the question right now, it's just your aim. Good. I hope you will succeed! Besides that, I see no arguments why users don't. No proof either. No proof?!? Did you read the original blog posting which kicked this off? Or the thread in the forums where our users claim the Apache upgrade was a surprise - even though this was a well-trailed change? That's just one change. I scoured the forums a bit and looked what users were telling. I wasn't surprised. What do you expect from a user telling it all doesn't work any more, who doesn't run etc-update just because after every emerge --upgrade --world it has over 100 files to update? Such user just ignores the importance of the tool, and will most certainly ignore anything else that we try to help this user. This was just one example. It is a very humble attempt to try and help these users, but they simply chose the wrong Linux distro, because Gentoo expects you to be an system administrator, not a user. At least that's my vision on it. I think we can agree that Gentoo requires a user to know/realise more than a Fedora/SuSe/Ubuntu user. I don't understand the problem from your point of view. No, scratch that. I don't understand your point of view. You're coming across to me as someone who doesn't believe there's a problem that needs solving. I am just in the opinion that we lack a system where users can find the information they need. That would help a certain type of users, absolutely not all of them. So yes, after that, this problem needs solving, perhaps. Personalisation using portage is a sweet thing! Here comes the point where I can express my doubt about the 100%. There are unfortunately users who are too hard to help, if you get what I mean. I'm tempted to forcibly co-opt you into the PHP team before we put dev-lang/php live. This would allow you to experience the situation for yourself. Maybe that would give you another perspective? ;-) Might be a very good excercise for me (and you?). As you might guess from my comment above, I simply think _communication_ is the big problem, as I see being a problem in many places around here. Not that perfect communication solves the problem entirely, but it allows to reply in the sense of 'rtfw'. If you're serious here, feel free to contact me (off-list) to see what we can arrange. [1] http://stu.gnqs.org/diary/gentoo.php/2005/11/10/feeling_blue -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On 10-11-2005 21:33:48 +, Stuart Herbert wrote: We need to establish *one* authoritative source of news. We can't do that if we simultaneously launch several sources of news all at once. We have to launch *one* service first, give the userbase time to adjust to that, and then start making the news available via additional sources. Yep, so create that central source on the web, and fork off mailing list posts, RSS-feeds and stuff based on this central repository. Also let portage warn users based on the information in this repository. We can start creating and populating the central web resource _right now_, as all the infrastructure is there. The mailing lists shouldn't be a problem as well. It all makes sense... ... as long as you include the right handles for users to adjust their preferences. You missed my point here, when I was just trying to indicate that in our user base, there will be many different users. Different users as in different preferences. Forcing the portage solution, the mailing list solution, or which other solution upon a user is evil. People should be *free* to choose. That you define a default setting of enabling the portage feature is fine with me, but include clear directions to disable such feature and allow it to send mails if the possible infrastructure is there and the user wants it. Take all preferences into account. I don't see why you would want to achieve your 100% user coverage aim through only *one* channel. I am strongly in favour of using multiple channels to do that. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On 11-11-2005 10:38:43 +0100, Marius Mauch wrote: No, the central repository certainly shouldn't be on the web (whatever that means in the first place), it has to be somewhere in CVS (easily accessible by all devs, though not necessarily in a direct way) and should be replicated to as many channels as possible (the website being one of them). Agreed. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sun, Nov 06, 2005 at 09:56:35PM +, Ciaran McCreesh wrote: | Then what is the point of this GLEP? Instead, just warn people | through existing intrastructure, which is cheap from an engineering | perspective because everything is already there in place, and don't | think of implementing all kinds of extras just to warn a user one | extra time, since trying to warn them any further becomes futile | anyway. The current warning levels we have are insufficient. This GLEP proposes a new system for warnings which will be far harder to accidentally ignore. There are, however, limits to how far we can reasonably go before we make the solution worse than the problem. Remember that there are packages in the tree that satisfy the preemptive requirement, since they simply die when trying to upgrade and a certain amount of prerequisites is not met. This prevents the user from losing data files or making them inaccesible, while at the same pointing out what needs to be done and why, using a short message. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 42 Critical News Reporting Round Two
Ciaran McCreesh wrote: On Mon, 07 Nov 2005 19:32:38 +0100 Grobian [EMAIL PROTECTED] wrote: | So, what list should the user that wants to receive those | **important** messages sign up to? That's your first misconception right there. Most users don't sign up for things. Doesn't matter. If the important messages aren't posted or you have to extract them yourself the effect is the same. Besides that, I see no arguments why users don't. No proof either. Forcing a push-based method on someone who likes pull-based methods is evil. The least you can do to make everybody happy, is allow pull-based access to the important news items, and devote some more words on how to disable your 'feature'. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Daniel Ostrow wrote: You are correct, there is no clear cut place for them to go...that's how this thing got started in the first place. However why force users to sign up for something which can't be appropriately filtered (installed packages, keywords, use flags, profiles, etc.) when all of them are already signed up for something that can track and filter, portage. I wouldn't necessarily bother signing up for an errata list if said list was going to provide me with *all* the errata out there. The reason that a mailing list works for RedHat is because RHN tracks what packages you have installed on your system on *their* server (again something you have to sign up for, and worse send them info about your configuration), so the filtering is done for you. We will *never* do something like this, we have a client side tool that can identify what is installed already...why not use it? What if an admin just wants to see all errata messages because (s)he doesn't feel like aggregating the unique messages from a whole cluster of machines running Gentoo with all different packages installed? It is a well-known fact that removing seemingly useless background noise can cause relations between problems not to be recognised. Some users know that and hence would like to see all errata. Our GLSAs are sent out exactly in the same way, but there is not a word on them in the GLEP, neither does anyone seem to care about them, while they seem to me at least ***VERY*** important, that is, much more important than a message about breaking my installation. And they aren't even personalised! Users don't care about security[1], adminstrators do. Administrators don't care about breaking installations[2], users do. About the RHN subscription thing, that service is IMHO quite expensive (certainly not free) and not available to Fedora Core users. I don't think you _want_ to compare Gentoo Linux Free support to support provided by commercial entities for an annual membership fee. The issue whether news or GLSAs are important and whether they can be read or not is of relevance with regard to the motivation of the GLEP which assumes it doesn't work for anybody, while I claim it 1) doesn't work because the information is hard to find and 2) it will work for a certain group of people very well if the information would be there. To conclude my far too lengthy replies here: I'd like to see some recognition that the world isn't that flat as the GLEP suggests, thereby including opportunities for everyone to be happy with the GLEP. I already stated this in my first reply in my part on use-scenarios. Don't worry I'll shut up now as there is clearly no interest for a bit broader thinking. [1] (linux) desktop users are of a much lower target than big companies for security exploits [2] administrators try out package upgrades on a spare box first, users usually don't have such box, or risk the potential impact -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Ciaran McCreesh wrote: | Which means you won't be able to satisfy your preemptive | requirement. Not at all. You can warn users repeatedly, but there comes a point when trying to warn them any further becomes futile. Then what is the point of this GLEP? Instead, just warn people through existing intrastructure, which is cheap from an engineering perspective because everything is already there in place, and don't think of implementing all kinds of extras just to warn a user one extra time, since trying to warn them any further becomes futile anyway. The motivation of your GLEP is based solely on the assumption that critical news is not effectively delivered to the user, however, the GLEP implicitly introduces this critical news, so how can it be ignored by users? It's not there. If you don't plan to solve the requirements you state yourself, either don't state them, or make clear you will not satisfy them for what reason. To me it looks as if you just would like to remove the 'preemptive' requirement because it suggests some behaviour that you don't (plan to) implement. And hence, you should also rewrite the motivation to reflect your statement in the quote above. I like the idea of the GLEP, since it will be helpful for many users I think, but the grounds on which and the reasons why should be valid points, IMHO. I also think that the idea comes very close to things proposed and or desired by many users that would like to have all the einfo messages being sent out to them, or accumulated after portage has done it's compiling. See the respective super bug and ml discussions on it. Hence, the GLEP itself doesn't differentiate itself, is not defined to be generic enough or reusable, should include configurability and, last but not least as I mentioned before, should be grounded in valid points. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Ciaran McCreesh wrote: Motivation == There are currently several ways of getting news out to our users, none of them particularly effective: This assumes the following ways are really ineffective, something which you don't prove or give any reason for. Hence it's eligable for another big discussion. To avoid that, I would suggest to add a number of reasons, or whatever to make this assumption sound (more) valid. It is important, I think, that the reader can understand your grounds for saying this. (I personally disagree on this statement now, but it makes no use discussing it since you haven't given any ground as on why. Maybe if you would give a definition, I could adjust my own definition and agree.) A more reliable way of getting news of critical updates out to users is required to avoid repeats of the various recent upgrade debacles. Perhaps you want to add a small footnote here, to give a small example of such debacle, and using that example point out what is the problem you think is important, and hence will address in this paper... eh GLEP. This GLEP proposes a solution based around pushing news items out to the user via the ``rsync`` tree. This is a minor side issue, but I think that GLEP 2 states that you should use ' instead of `. No discussion on it please, I might be wrong or you just didn't know. Preemptive Users should be told of changes *before* they break the user's system, after the damage has already been done. style suggestion for unambigous interpretation: perhaps a because if applied afterwards instead of after No user subscription required It has already been demonstrated [#forums-whining]_ 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. You implicitly state that many users do not read the gentoo-announce list and RSS-feeds because they are subscription based. This sounds like a too quick assumption to me. At least it is not founded in any way. Consider that for RSS-feeds one typically doesn't have to subscribe, but just add it to his/her reader. Make clear why you think the subscription model stops users from reading, and why a push-based alternative (as you suggest here) will work. Remember that it is easy to say here that users don't read what's on their consoles as well, as in post emerge messages etc. So make sure you deal with it upfront, why you think now it *will* work. No user monitoring required It has already been demonstrated [#forums-whining]_ 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. Apart from that this point seems to repeat much of the previous one, it introduces a new unfounded claim (users do read, but now too late) which somehow contradicts previous statements. Beware that you clearly deal with this, or just introduce it earlier so it doesn't look you're contradicting yourself. 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. Direct question that follows from this: what *do* we expect a user/system to have available? I think it's good to state that as well, since you're excluding a lot here in once sentence. 3. The news item is committed to a CVS (or Subversion [#glep-36]_) repository. From here, it is merged with the rsync tree. This is described in `News Item Distribution`_. 4. The news item is merged with the rsync tree. Implementation details of this point are beyond the scope of this GLEP; existing solutions are in place for merging GLSAs to the tree. Where does point 4 differ from the second part of point 3? Also, point 3 implies that the merging into the rsync tree is being described further on, while point 4 states the oposite of not discussing it (out of scope). Maybe split point 3 and merge with 4? 5. Users fetch the news item when they sync. This ensures that the news items in question are pushed to the user before the user accidentally makes an unwanted change. No changes to the existing rsync process are required by this GLEP. I would suggest a reference to a place where you will explain this 'pushing' to the user in detail. Especially the time and the way how are important. Or maybe I was just confused by pushed and is the only thing this point wants to say that all news items are just synced together with the rest of the portage tree upon a emerge --sync. The latter sounds logical considering the last sentence quoted above. 6. Portage filters the news item and, if it is relevant, installs it in a special location to be read by a news item reader. Messages are also displayed to
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Jan Kundrát wrote: On Saturday 05 of November 2005 11:28 Grobian wrote: Remember that it is easy to say here that users don't read what's on their consoles as well, as in post emerge messages etc. So make sure you deal with it upfront, why you think now it *will* work. Emerge messages are usually hidden by compilation output, so this argument doesn't apply here, IMHO. Or am I missing your point here? You give an example here of why console messages aren't read. But if that is your rationale here, I would like to see it stated in the GLEP why it *will* work there. On the previous discussion there was an example of a console message not being read fully/properly. This will happen to more people. What I was asking for is that such situation is either outlawed (ie. People should just read, if they don't then it's not my problem) or recognised (ie. It is known that people do not read, hence we propose to use a text-to-speech module and play the produced audio file, so the user can listen to the imporant message -- idiotic example of course). Just to make things clear and properly defined. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
[EMAIL PROTECTED] wrote: You must not have read the [#forums-whining]_ reference as that makes it quite clear that existing methods isn't adequate. Even if you think the apache maintainers made lots of mistakes you can't really fault us for not trying to get the news of config changes out to all users. I haven't, that's correct. However, a reference should be a source for additional information. A small exerpt or recap of that thread is not in the GLEP. Also, [#forums-whining]_ was not referenced in the quoted part, the reference only follows later on. Going into answering your question, the thread suggests for instance an RSS-feed with this info. Also the GLEP mentions 5 distinct sources, of which I personally think at least two will be effective for a certain group of people. That last thing was what I was aiming at. For some it might work quite well if the apache2 upgrade stuff (as sent out on gentoo-dev) was communicated through gentoo-announce. Hence my doubts on whether [they are not] particularly effective is a general statement that applies to any situation. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
[EMAIL PROTECTED] wrote: If we were only aiming at a certain group of people there would be no need to change anything. The apache announcements reached lots of users but still left a large chunk of users in the dark. Moving the news to -announce or some RSS feed wouldn't change anything as the basic problem with these methods is that people have to actively search out important news instead of news getting pushed to them. I disagree. A lot Gentoo users I know read gentoo-announce and the GWN. For me it works quite well if I see a message with a warning on something. I can quickly find it back if I am in need for it. I would typically disable the whole news feature of portage and just watch the announce ML with all the news announcements. Works fine for me. The GLEP *is* targetted at a certain group of people, since it is there mainly to help those that complained in [forum_whining] and those -- I think -- mostly desktop end-users to prevent them from breaking their system and complain with us. I broke my webserver too after the apache update. Too bad I was stupid enough to 'just do it' on a webserver that should *not* have been offline for a while. I just ignored the message the init.d script gave when it refused to stop my apache. To cut a long story shory, I have solved the problem myself, knowing I was stupid for ignoring the message on gentoo-dev. I never blamed the apache herd or anyone else but myself and just fixed it myself. Sys-admins are supposed to try updates on a toy box first. A warning is nice, documentation on how to solve it the best is even nicer. Think of knowledge books of many commercial systems. What the GLEP does is twofold: 1. Suggest special (**important**) news items to be accepted within Gentoo, and them being stored somewhere 2. Desparately push this news to users, because it seems that they don't read information which is not available (yet! see 1). So thank you for letting me realise that this GLEP should be splitted in two. One for just realising and standardising a way to publish news items on normal and known media: mailing lists, RSS feeds and WWW pages. It should include topics regarding what information (like solutions or workarounds) should be there. Then an additional GLEP which suggests the pushing of information to the user -- like this current GLEP -- can be written when it becomes clear after a reasonable amount of time after realising the GLEP mentioned above doesn't work sufficiently. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Bryan ��� wrote: Even if you don't realise that this will be a big help for many users or you just don't think those users deserver any help (not sure which one it is tbh) - you might at least consider the fact that only having to push news about major / critical changes in one place is going to make things a lot easier for devs. Any help that you can give is great. I am not against the ideas in this GLEP. It's are good ideas. However, you cannot push something that is not there, and you cannot say you *have* to push it because other ways don't work -- ways which aren't yet explored. News items as described have never been published before, IMHO, and hence the effect of un-filtered, un-personalised publishing of these news items is *not* known. I would priorise on getting them published somehow, and in the meanwhile continue on this GLEP from another perspective: personalising news messages based on the user's portage. Such GLEP can elaborate much more on support for mailing automatically to root or another user, pushing forcibly on the screen or reading via 'news-update', just to suit every installation/user scenario that we can dream up. It also is in the two separate issues that you snipped from my previous mail. I think we're not going to agree here, so to prevent any more lengthy discussions over gentoo-dev on this topic, you can contact me off-list. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Ciaran McCreesh wrote: | Apart from that this point seems to repeat much of the previous one, | it introduces a new unfounded claim (users do read, but now too late) Read the linked forums thread and all will become clear. the forums thread advocates against the new unfounded claim, IMHO. | The news item will be named in the form | ``-mm-dd-item-name.en.txt``, where ``item-name`` is a very | short name (e.g. ``apache-updates``) and ``en`` is the two letter | ISO 639 [#iso-639]_ language code for the news item. The short name | must consist only of characters ``a-z``, ``A-Z``, ``0-9`` and ``-`` | (hyphen). | | Consider replacing hyphen with an underscore to ease parsing. Mixing hyphens and underscores? That's just going to start confusing things... I was referring to the item-name. It is defined to allow -, whild the fields are also separated with -. Hence I suggested to allow _ in the item-name instead of - to avoid (possible) problems when parsing the field. | In any case, elaborate on why supporting only OR was chosen and why | other (probably investigated) options were discarded (and hence make | my statement above unnecessary). The previous draft had an option for and or none-of modes. I took it out because I don't think it's going to be anywhere near as useful as one might initially think. I'd appreciate it if that would be documented and grounded. | Elaborate some more on No fancy formatting or tab characters. | People might want/like to include a bulleted/numbered list or insert | a small (shell) code example. Also make some note on the average | length (number of paragraphs) and perhaps a predefined structure | (ie.: introduction/abstract, impact, solutions/actions, | links/more-information) These're things to be decided when news items are sent for review. Once we have some real material there'll be a more useful way of judging what is acceptable and what has gone too far. I guess then it's better to state that, and make no assumptions or partial decisions on it. If it is out of scope of the GLEP, make it like that. | - what if noone feels like commenting on the submission? Then it's assumed correct. | - how do you know a certain dev is a competent English speaker? *shrug* If we ever get onto linguistics arguments, there're enough of us with copies of Fowler and the OUP Style Guide to settle things. Then what is the point in requiring it is correct English? (Not even considering the big difference between UK/US English) You can and will not enforce it. Everyone writing such news item will do her/his best to make it sound like real English, and perhaps ask for help, but that's it. Hence my suggestion to put the doc writers in the loop somehow. | Does portage only 'warn' and still continue, or does it completely | stop when an unread news item is found for a package that is to be | upgraded? In the first case, the 'preemptive' requirement is being | violated, in the latter, the option for a '--force' or something must | be discussed. (Users with multiple systems might already know the | message, or users might not be interested in it since they don't run | the application in production.) Portage only *warns* you if you try to unmerge glibc... Which means you won't be able to satisfy your preemptive requirement. | Yes, and make it a requirement that all news messages get posted | somewhere on public channels. I don't see any particular need to *require* that all news items are posted to a specific place. You might be right, as the how, when and why of news items should be a completely separate thing, as I see it right now. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
Danny van Dyk wrote: IMHO a text based file has a big advantage in this proposed application over fileformats which use XML: Any administrator can read it with his editor of choice, right from the console. This is an important aspect for sure, but why can't such file be generated from a marked up one? Because the same message will be put in multiple forms (ideally) it is best to have a version with all the required meta-data to generate all the other formats, because if you have to add such meta-data it's usually much worse (= manual or conditional human work). Some people like reading console messages, others plain text mail messages, others want html marked up mail messages, other others like reading an rss-feed, and of course there are people that like to read the full fledged funky marked up with all hyperlinks possible html version on the web. I think the only real importance is that all representations can easily be generated from the original source, be that XML, reStructuredText or any other format. With regard to being it hard to write or not, I think these kind of messages are very well suited for templates, so it is just a matter of filling in the message, which should make the underlying format not so important. Just my €0.02 on the XML vs. plain text discussion. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Questions about XML files used in portage
Paul de Vrieze wrote: One reason is that there still is no real agreement on what schema to support. Also when I wrote those I was more at home with DTD's than with WXS or Relaxng, and xmllint (part of libxml2) did not support WXS validation. I'll look into creating a WXS version. Is WXS an XML Schema file? (XSD) If so, I have made a few of those schemas myself in the past, so I might be of any use if necessary... Feel free to contact me about it. -- Fabian Groffen Gentoo for Mac OS X -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Questions about XML files used in portage
Paul de Vrieze wrote: AFAIK CDATA will be satisfied by one single space as well... One of the drawbacks of DTD's. In general schema's are better in specifying an xml format, as they allow restrictions on CDATA, and more freedom in other areas (like true order independence). Is there a reason why there's only a (legacy) DTD and not an XSD? -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC - Gentoo on the Lab
Ricardo Loureiro wrote: Usable in the way that the client machines should be able to use portage, except it's the hacked (or new package) version that should do everything from the SQL server. For example, a emerge package would behave in 2 possible ways;1- calculate it's dependencies from the portage tree on the SQL server and request the binary packages, 2- Request the package and the server would calculate dependencies and get the binary done. I'm more keen on the second since it takes away processor time from the clients, but that involves sending sensitive information such as world files and make.conf over the network. Sounds like in your setup you would like to keep a profile of the client on the server, so you don't have to send over that information, because it is already in the DBMS. That also allows you to update 'push-driven', because the server can easily tell which clients have packages that are out of date. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla handling for maintainer-wanted things
Maurice van der Pot wrote: On Thu, Aug 18, 2005 at 09:28:47PM +0100, Ciaran McCreesh wrote: Bah! No I'm not, because Sven pointed out that it collides with the bugzilla resolution. So I'm going with CHECKED instead. Whoah! Isn't REVIEWED the perfect keyword? or APPROVED? -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
Extracted from what Henrik Brix Andersen wrote: That's not a valid argument - you can use a bash function for calling echangelog and repoman as shown numerous times on this list. See my first answer (bash function). See my first answer (bash function). From a database point of view, it is evil to duplicate values in an automated manner, just use a foreign key for such purposes. In other words, avoid duplication. If such bash function is a common tool then -- apart from wondering why it isn't part of the default suite -- this anti-duplication constraint is being broken massively. I like Mike's idea, because it deals with data redundancy and basically uses this 'foreign key' for the changelog. In other words: centralise the administration, don't make yourself having to keep multiple copies up-to-date, you're doomed to make errors with that. Just my two cents. -- Fabian Groffen eBuild Porting Gentoo for Mac OS X -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-osx] Package testing -- Automated initiative
Chris Gianelloni wrote: By the way, I am working to get catalyst running on OSX, so version 2.0 will definite suit your needs when it is released. If you need help on OSX specific things, be sure to contact us... -- Fabian Groffen eBuild Porting Gentoo for Mac OS X -- gentoo-dev@gentoo.org mailing list
