Re: [gentoo-dev] Group limit for NFS exported file systems
Robert Szentmihalyi wrote: is there a group limit for NFS exported file systems in recent kernels? One if my users cannot access directories that belong to a group he actually _is_ a member of. That, however, is true only when accessing them over NFS. On the local file system, everything is fine. UIDs and GIDs are the same on client and server, so that cannot be the problem. Client and server run Gentoo Linux with kernel 2.6.16-gentoo-r9 on the server and 2.6.17-gentoo-r4 on the client. You'll have a better chance of getting an answer to your question on the gentoo-users mailing list, the #gentoo IRC channel on freenode, or an NFS-specific mailing list/IRC channel. Cheers Andrew signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Xmms needs to die.
On Thu, 24 Aug 2006 19:34:27 +0200 Andrej Kacian [EMAIL PROTECTED] wrote: On Thu, 24 Aug 2006 18:42:27 +0200 Robert Cernansky [EMAIL PROTECTED] wrote: [...] mpd (and xmms2) is just a server that is responsible for music playback, functionality such as xosd notification can be provided by clients, one [...] Many xmms plugins I saw are frontend-related. This can be handled by MPD clients. One of main clients, gmpc, recently added plugin support, and already plugins for album covers or song lyrics are available. [...] Also I read that it is not possible to play file without addind it to mpd's database.(?) It seems to be clumsy. This is mainly because mpd is designed to run remotely, i.e. not on your desktop - clients connect via TCP, so they have no idea about the filesystem on box where mpd runs. There are plans to allow this exact functionality via URIs in format: file://. So, I've tried mpd plus mpc, gmpc, glurp and kmp clients. I must say I don't like it. _Mainly_ because that database thing - sorry but the playlist management is worse than I expected. I want simply _freely_ browse my filesystem, pickup an .m3u file and play it. I find it very limiting that I cannot play file from any location. That I have to copy it to music directory and rebuild the database. What about removable media? Another big disadvantage is that it cannot play Audio CD's. Behavior in multi-user environment is also bad. There is only one daemon, so imagine that I'll take a break from my work, pause the player, lock my screen and go to pub for an hour. Another user can log in and work, and listen the music. But he will have loaded same playlist, paused as I left it. So he loads its own and listen, but it will break also my player status and when I return, I'll find his playlist in my player. Sure, it can be solved by running separate instance of mpd by user but then it is too complicated way just to play music. In general, I thing there is no really good client for mpd. I can imagine that it is possible to start mpd by client, transparently for user. That this database disadvantages can be hidden by a client so work with files will be easy and straightforward like in xmms. That it will have plugin support and more features so things like xosd, handy disk-writer plugin, effect plugins, tag editing,... will not be missed. Many features are planned, but it takes time to get into real life. Btw, something like effect plugin (for example voice removal) belongs to server or client? Also, mpd has gapless output by default, iirc. It does not wor for me, gaps are there. I only found Crossfade option in kmp client. Robert -- Robert Cernansky E-mail: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last Rites app-pda/rapip
Hi all, app-pda/rapip has been masked and is pending removal from the portage tree. Upstream has stopped maintaining this and I believe that kpilot and others are a good replacement for it. Due to the lack of man power and my general lack of interest with anything that requires KDE, I am removing this from the tree. Hopefully this doesn't affect many, but if it does, please scream out and we can sort something out. Cheers, Alastair -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Coda file system needs new maintainer
On Thu, Aug 24, 2006 at 01:58:05PM +0200, Enrico Weigelt wrote: I've got switching my nfs installations to coda for right some time, and so I'd offer to maintain the package. Actually I'm looking for a Gentoo developer to take over maintenance. Maurice. -- Maurice van der Pot Gentoo Linux Developer [EMAIL PROTECTED] http://www.gentoo.org Creator of BiteMe! [EMAIL PROTECTED] http://www.kfk4ever.com pgpTWj6RRTfGo.pgp Description: PGP signature
Re: [gentoo-dev] Xmms needs to die.
On Thu, Aug 24, 2006 at 03:53:09PM +0200, Robert Cernansky wrote: Unfortunatelly this is something different. xmm-pipe lets you control running xmms from commandline (thus binding these commands to keys). It allows control volume, skipping in current track (fast forward), do some playlist actions and lot more. Isn't this what the included audtool command is for? I use it for windowmanager hotkeys. audtool help shows that it has lots of options. Christian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] mulltiib cruft: /emul
On Thu, Aug 24, 2006 at 04:58:02PM -0400, Chris Gianelloni wrote: Don't forget that this will require an update to (at least) eselect-opengl, too. Actually I'm not sure it would. eselect-opengl currently checks /usr/lib[,64,32]/opengl/ for 32bit opengl libs libs and only finds the emul libs since we create a symlink - /emul. We just would't need the symlink anymore since this is where they'd actually be installed. Herbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Asking permissions for package substitution -kover to koverartist
Ciaran McCreesh wrote: Are they configuration-file compatible, including the location of said configuration files? [homedir]/.kde3.5/share/config/koverartistrc is obviously different from [homedir]/.kde3.5/share/config/koverrc (both path and contents), but it doesn't needs manual intervent as the gui let you set your cddb preferences easily (and kover config file doesn't get deleted after unmerging kover). Matteo -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Future of tetex
I have been busy all the summer! Is there any news about the TeXLive ebuild? About the texmf tree, is there really many packages that would be included in each distributions? Would a modular ebuild system like the one used by Gnome (emerge gnome and emerge gnome-lite) and X.org would be nice for TeXLive? Each packages in the texmf tree could be updated independently if needed and the packages like beamer could be also included in the dependencies. Thanks Gabriel Lavoie Martin Ehmsen a écrit : Gabriel Lavoie wrote: I suppose for now that the best way to check the texmf tree dependencies is to install TeX Live using the .iso file? I'm not sure I understand your question... The tex packages that should go into the three trees is not necessarily the packages that ships with texlive (the texmf tree that is downloaded with the current texlive ebuild is the same as the one shipped in the .iso file), they could just as well come from ctan (or any other place for that matter, as long as the licenses are clear). So what one should do is go to ctan and figure out the interdeps between packages that goes into the texmf trees. And some of the bigger packages (beamer,...) should _not_ be in the texmf trees, since we want to be able to upgrade those without making a new release of the temxf trees (which forces users to download a large file again). Martin Ehmsen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
Daniel Ostrow wrote: On Thu, 2006-08-24 at 17:26 -0400, Michael Cummings wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stuart Herbert wrote: We've had a global vision for where Gentoo is going from before I joined - Gentoo is here to create a source-based distribution where each package is as close to what $UPSTREAM intended it to be as possible. We're not trying to take $UPSTREAM packages and innovate with them - we're here to do a first class job of packaging them up. Um, that's a mission statement, not a vision. A vision is a series of goals for a project, like my vision is that we will produce knoppix like catalyst+template releases for myth, firewalls-on-a-disk, etc by the 2007.0 release. a mission statement is we'll make the best from source distro ever. i.e, mission statements never change because they are just an overarching definition of a project, not the vision or goal it might be working towards at the moment. somebody shoot me, my job in middle management is finally getting to me. Exactly... Above and beyond that is the next step...once you have a vision...ok so what do we need to do to further the vision, do we need more devs doing X, do we need hardware Y, do we need an Ice Cream machine... Leadership is way more then just shouting a vision out to the world and expecting people to hop to it...its about helping facilitate that visions completion, keeping yourself involved so those working on it feel involved themselves...leadership is just as much a community building exercise as any of the rest of it. --Dan Vision says who we are and why we are here. It speaks to our shared values and what makes us a community. Once you have a vision, you need Strategy. A Strategy describes the big plays you are going to make to achieve your vision. Examples might be, We want to be the biggest distro, or We want to be the most user friendly distro, or We want to capture the enterprise market for Linux, etc. Once you have your Strategy, you need a plan and the plan must match the Strategy. Once you have a plan, you execute. That's what leadership does. My 2 cents. Mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
On Thu, 2006-08-24 at 22:36 -0700, Donnie Berkholz wrote: Chris Gianelloni wrote: On Thu, 2006-08-24 at 14:00 -0700, Donnie Berkholz wrote: Oh, gimme a break. Screaming about it on -dev for hundreds of posts isn't just equivalent to a vote, it's better. It makes people think there's more than 2 developers opposed to it. Really? Even you didn't remember that *I* was opposed to Sunrise and probably accounted for at least a good 50 responses. Yes, good came from it. Yes, it could have been done much, much better. Sunrise is a poor example for me, because I ignored all the discussion on it past a certain point. It was just rehashing the same points over, and over, and over... Yes, because we were asked for the same thing over and over, which is also why I ended up no longer responding. You can only say the same thing so many ways before it gets tiring. Hopefully, to streamline processes and give power back to individual projects to govern themselves in internal matters and let people get back to doing development. That's a goal I would love to see us strive to achieve in the next year. From what I see, projects are pretty free to govern themselves. How do you see it differently? How do you kick someone out of a project? Currently, I know of no way to do so. What process is required for someone to join a project? Currently, anyone can add themselves to any project without any consent from the project itself. The only real counter-examples to this are projects which require some kind of specific authorization to join, such as devrel or infra, since they have access controls. Who is responsible for an individual developer's work, aside from the developer? If a developer joins a project and doesn't do what he's promised, nothing happens to him. If he doesn't work his bugs, nothing happens. Why not? What if the developer does poor work? This really ties into the above, but what happens if someone is found to not really possess the skills necessary to be in a project? Right now, we cannot do anything about this person but hope that they either magically gain the skills, or leave the project on their own accord. As Weeve said, he's still trying to get people to stop breaking SPARC keywords, just like 3 years ago. It's just when trying to do anything larger than a single project that you run into issues. People that do this sort of thing should have some sort of consequences. The occasional accident is one thing, but there are people that become repeat offenders with many of these sorts of issues, yet nothing is done to them. If there's no consequences, why should they bother changing their behavior? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] mulltiib cruft: /emul
On Fri, 2006-08-25 at 13:26 +0100, Herbie Hopkins wrote: On Thu, Aug 24, 2006 at 04:58:02PM -0400, Chris Gianelloni wrote: Don't forget that this will require an update to (at least) eselect-opengl, too. Actually I'm not sure it would. eselect-opengl currently checks /usr/lib[,64,32]/opengl/ for 32bit opengl libs libs and only finds the emul libs since we create a symlink - /emul. We just would't need the symlink anymore since this is where they'd actually be installed. Cool. That was either changed at some point, or my brain is still stuck on opengl-update. ;] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Democracy: No silver bullet
Chris Gianelloni wrote: [snip] How do you kick someone out of a project? Currently, I know of no way to do so. It's at the leads discretion. For amd64 me and my OP leads talk it over and make a decision. I suspect that most leads simply don't have the balls to remove someone. It's not an enjoyable task. . What process is required for someone to join a project? Currently, anyone can add themselves to any project without any consent from the project itself. The only real counter-examples to this are projects which require some kind of specific authorization to join, such as devrel or infra, since they have access controls. It's also the leads discretion. Were someone try to add themselves to a project I run without chatting with me(or my OP leads) first, he'd find himself quietly removed at best. [snip] --Mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
Mike Doty wrote: Chris Gianelloni wrote: [snip] How do you kick someone out of a project? Currently, I know of no way to do so. It's at the leads discretion. For amd64 me and my OP leads talk it over and make a decision. I suspect that most leads simply don't have the balls to remove someone. It's not an enjoyable task. Never had to do, probably because nobody really did anything to require that, cleaning the herd from people not interested/active anymore on the other hand... . What process is required for someone to join a project? Currently, anyone can add themselves to any project without any consent from the project itself. It's also the leads discretion. Were someone try to add themselves to a project I run without chatting with me(or my OP leads) first, he'd find himself quietly removed at best. Usually people ask to the leads/team before joining in... lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
On Fri, Aug 25, 2006 at 11:45:36AM -0400, Chris Gianelloni wrote: As Weeve said, he's still trying to get people to stop breaking SPARC keywords, just like 3 years ago. It's just when trying to do anything larger than a single project that you run into issues. People that do this sort of thing should have some sort of consequences. The occasional accident is one thing, but there are people that become repeat offenders with many of these sorts of issues, yet nothing is done to them. If there's no consequences, why should they bother changing their behavior? From the new conflict resolution policy (found at http://dev.gentoo.org/~plasmaroo/policy.xml, will move to some more official place soon): --snip-- Issues not necessarily related to personal conflict, such as intentional or repeated policy breaches, malicious or abrasive behavior to users or developers, or similar developer-specific behavioral problems should be brought directly to Developer Relations via [EMAIL PROTECTED] These should be dealt with on a case-by-case basis by Developer Relations and may require disciplinary action. --snip-- So if by breaking the keyword someone breaks a policy, it is something devrel should and will deal with. 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 pgpKr2bz8M162.pgp Description: PGP signature
Re: [gentoo-dev] Democracy: No silver bullet
On Fri, 25 Aug 2006 18:25:53 +0200 Wernfried Haas [EMAIL PROTECTED] wrote: | So if by breaking the keyword someone breaks a policy, it is something | devrel should and will deal with. Should, sure. Care to back up the will part? -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Future of tetex
Tach Gabriel, 0x2B859DE3 (PGP-PK-ID) Gabriel Lavoie schrieb: About the texmf tree, is there really many packages that would be included in each distributions? Would a modular ebuild system like the one used by Gnome (emerge gnome and emerge gnome-lite) and X.org would be nice for TeXLive? Each packages in the texmf tree could be updated independently if needed and the packages like beamer could be also included in the dependencies. You know the maintenance that will need? Yearly updates of TeXLive should be sufficient. V-Li -- Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3 http://www.gnupg.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
On Thu, Aug 24, 2006 at 06:29:03PM -0400, Chris Gianelloni wrote: Quite frankly, I think that with a properly run community, there should be no need for a Developer Relations project, since it should be mostly self-policing. With 300+ people, i severely doubt self policing would work. I assume you were mostly thinking about conflict resolution when you wrote this, but there are other things like - recruitment - retirement of developers that - quit - go AWOL etc. In an ideal world with a self-policing community this could work out, however i rather tend to assume one of these things happen in the real world: - People get recruited by anyone in whatever way and have no idea about our policies, breaking the tree in their first commit. - Developers retire and no one removes their access due to lack of procedure - Devs go AWOL, no one notices. If someone notices, perhaps he starts volunteering doing this kind of clean-up work, and technically a new devrel project emerges. Beyond that, the leadership should have the power and the ability to take care of problems in a timely manner without the need for droves of bureaucratic process. The process (http://dev.gentoo.org/~plasmaroo/policy.xml) is reorganized and should fulfill both your concern for a timely manner and is much less bureaucratic. Also, there's a lot of stuff happening other than the conflict resolution stuff with regard to ombudsman and often kloeri resolving things - you don't read that on the news, but i'm not sure if council members should spend a lot of their time to resolve silly conflicts between devs, they're elected make decisions, not obsolete devrel. ;-) Btw, the new policy also includes the possibility of refering a decision to the council in certain cases, see Resolution and Appeal. I'm sure nearly every member of devrel would agree that they would love to see a Gentoo where devrel simply wasn't needed. I assume you're only refering to conflict resolution again, and i agree it would be great. I just don't think this is ever going to happen as long there are more than 50 developers. 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 pgpfux2surC6W.pgp Description: PGP signature
Re: [gentoo-dev] Xmms needs to die.
So, I'm curious -- did anyone ever come to a decision what to do on the matter? The list traffic seems to be dying down. Maybe I just missed the final decision email. Not that it really matters, but here's my 2 cents: If its a pita to maintain, hard mask everything and just say sorry, no bugs fixie unless you want to maintain it. See http://dev.g.o/~foo/xmms.html for reasons At least that way it will still be in the tree for those that want to use it. The second thing is, why does it even matter if its out of the tree or not? Those who are currently using it will still have it installed on their system, anyway. I'm still using audacious 0.2.3 even though it's been taken out, and I won't upgrade until my favorite plugin is ported. I'm fine with that. Anyway, whatever. Do what works best. :) Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
On Fri, Aug 25, 2006 at 05:35:53PM +0100, Ciaran McCreesh wrote: On Fri, 25 Aug 2006 18:25:53 +0200 Wernfried Haas [EMAIL PROTECTED] wrote: | So if by breaking the keyword someone breaks a policy, it is something | devrel should and will deal with. Should, sure. Care to back up the will part? Time travel is not possible, so i am not able to present you hard evidence. What i can assure you is that there is a policy that says so, and that policies are there to be followed. There also was one case of policy violation that resulted in a devrel bug, and the issue was resolved (further details are dev restricted in bugzilla iirc and i really don't want to name details, bug number or names not to turn that into a witch hunt). 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 pgpywPe5c2FFk.pgp Description: PGP signature
Re: [gentoo-dev] Democracy: No silver bullet
Wernfried Haas wrote: On Fri, Aug 25, 2006 at 05:35:53PM +0100, Ciaran McCreesh wrote: On Fri, 25 Aug 2006 18:25:53 +0200 Wernfried Haas [EMAIL PROTECTED] wrote: | So if by breaking the keyword someone breaks a policy, it is something | devrel should and will deal with. Should, sure. Care to back up the will part? Time travel is not possible, so i am not able to present you hard evidence. What i can assure you is that there is a policy that says so, and that policies are there to be followed. The point we're making here is, policies mean nothing if they can't be backed up. The past has shown that not to happen, and until there's hard evidence to show that something is actively being done, then the assumption that nothing will happen will stand. I don't care how many policies you come up with, they mean absolutely nothing if you can't actively deal with the consequences. -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Democracy: No silver bullet
On Fri, 2006-08-25 at 19:13 +0200, Wernfried Haas wrote: On Thu, Aug 24, 2006 at 06:29:03PM -0400, Chris Gianelloni wrote: Quite frankly, I think that with a properly run community, there should be no need for a Developer Relations project, since it should be mostly self-policing. With 300+ people, i severely doubt self policing would work. I assume you were mostly thinking about conflict resolution when you wrote this, but there are other things like You assumed wrong. While I was mostly thinking about conflict resolution, I still don't think that in a properly run project there is a need for an HR project. - recruitment This goes into the whole thing about bringing people into the project, as well as having a longer probation period. The mentor should really be responsible for the developer. If things were working smoothly, there really shouldn't need to be much work done for recruitment. Remember, we're talking a meritocracy here. We shouldn't just be bringing on some guy because he says he'll do something. We should be bringing on people that have *proven* that they can and will do something. - retirement of developers that - quit - go AWOL See, you missed that we're talking with the idea of people belonging to a project. If you work on my project and quit, I'll know. If you go AWOL, I'll know. I can then simply ask Infra to remove your access. It really should be that simple. If Infra is unable to do so due to being understaffed, then they should get more staff. etc. In an ideal world with a self-policing community this could work out, however i rather tend to assume one of these things happen in the real world: - People get recruited by anyone in whatever way and have no idea about our policies, breaking the tree in their first commit. Uhh... like this hasn't happened in the past? - Developers retire and no one removes their access due to lack of procedure If the developer belongs to a project, the manager knows it and asks for their removal. Is there need for any more procedure than that? - Devs go AWOL, no one notices. If someone notices, perhaps he starts volunteering doing this kind of clean-up work, and technically a new devrel project emerges. See, you seem to be assuming that I haven't thought this through. It would be impossible for a developer to go AWOL without their manager/lead/whatever you want to call them noticing if everyone were a member of a project. This doesn't mean you can only be on one project, it means you must be on *at least* one project. No more projects, no longer a developer. It's simple, yet effective. Beyond that, the leadership should have the power and the ability to take care of problems in a timely manner without the need for droves of bureaucratic process. The process (http://dev.gentoo.org/~plasmaroo/policy.xml) is reorganized and should fulfill both your concern for a timely manner and is much less bureaucratic. It does not fulfill my concerns in any way. Developer Relations is not Gentoo's leadership. Also, there's a lot of stuff happening other than the conflict resolution stuff with regard to ombudsman and often kloeri resolving things - you don't read that on the news, but i'm not sure if council members should spend a lot of their time to resolve silly conflicts between devs, they're elected make decisions, not obsolete devrel. ;-) With a proper structure, the council wouldn't need to be concerned with this sort of thing. Here's an oversimplified example. You are in projects A, B, and C. You haven't done anything for project A in six months, and the manager has noticed, and removed you from his project. He looks to see if you are in other projects, which you are, so he is done. He *could* email the other project leads at this point to see if you're still active, but it wouldn't be required. Each project maintains itself, after all. Project B has done the same since you haven't done anything for them in 3 months. Project C's manager notices that you haven't done anything in 2 months, with no word that you were leaving. He also notices that you aren't in any other projects, so he reopens your dev bug and asks infra to retire you. Process completed and no council involvement, whatsoever. The same sort of process really should be used for conflict resolution. Hell, at least our current policies dictate this, but it never happens, in practice. Instead, everybody goes directly to devrel. If two developers within a single project have a conflict. It goes to that project's manager. If it is between two devs in two projects, it goes to those two managers. The only reason it would need council involvement is if the managers cannot make a decision themselves, or possibly on appeal. There's really no other reason for council involvement. Btw, the new policy also includes the possibility of refering a decision to the council in certain cases, see Resolution and
Re: [gentoo-dev] Democracy: No silver bullet
On Fri, 2006-08-25 at 19:27 +0200, Wernfried Haas wrote: What i can assure you is that there is a policy that says so, and that policies are there to be followed. I thought that you'd been around long enough to laugh at this one, yourself. Sure the policies are there to be followed. That doesn't mean it always happens. What if devrel becomes overworked and is unable to police this sort of thing effectively? At that point, the policy will no longer be in effect, even though everyone will be trying their best to keep it going. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Xmms needs to die.
Steve Dibb [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 25 Aug 2006 11:20:52 -0600: So, I'm curious -- did anyone ever come to a decision what to do on the matter? The list traffic seems to be dying down. Maybe I just missed the final decision email. Well, no one has volunteered to take over maintainership, so it would appear to be heading toward orphaned package status. While that doesn't mean immediate removal from the tree, it will eventually as bugs begin to build up, and with a package such as this, they will probably build up to the point they get the attention of tree cleaners relatively fast... Overlay was suggested. I imagine if no one takes over maintainership and it gets pulled from the tree, sunrise might end up with it. It's fairly likely some user would be interested in it enough to try it there, altho as complex and old as it is, how successful they might be is open to question. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Removing dev-perl/Test-Builder-Tester
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Cummings wrote: This package was absorbed back into perl-core/Test-Simple as of the 0.62 release (which you have either via dev-lang/perl-5.8.8 or as the ebuild at this point). I'm package.mask'ing it and will be removing it from the tree in 30 days. Anything that used to dep Test-Builder-Tester has been updated to dep virtual/perl-Test-Simple-0.62, which is available on more arch's stable than T::B::T ever was. (incidently, this also resolves an upgrade/downgrade loop some folks face when emerge -De and emerge -Du are used, I can supply the relevant bug number if you are really super curious). ~mcummings Removed. - -- - -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E - -o()o-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFE704Kq1ztTp5/Ti4RApWxAJ9tWjcNImNos39k+iQ/WIg03JvVsgCgqBtm 8+ALpOFLRhf2fn8TWkJ3K38= =wuYU -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
On 8/24/06, Donnie Berkholz [EMAIL PROTECTED] wrote: A distribution is more than just an entity that packages upstream tarballs. I agree with your point, but it misses a large chunk of what we do. We do more than that, sure, but the vast majority of the day to day work in Gentoo is exactly that - packaging software released by upstream, and fixing bugs reported back from users. What do you do that goes beyond this? If this is the Gentoo vision, then why are we even doing anything else? Because folks want to? Because we've been recruiting people to shoulder the load, instead of recruiting them into a culture? Because we want to see Gentoo run on a wider variety of hardware than $upstream has access to? Because we want to make Gentoo more accessible to folks than it was in the past? What activities are we doing that don't directly support the Gentoo vision? We've already reached our only goal, which is packaging stuff, and all we need to do is bump it. People need to feel that Gentoo is _moving forward_, that it's actually going somewhere. We have no organisation that's going out there making deals with commercial entities, ISV partners, nor users. In that respect, we're a completely different beast to RedHat, SuSE and Ubuntu. You're not the first, and you won't be the last, to complain that we're not going anywhere. My question is simple : where do folks want to go, and what is stopping them getting there? Seriously - what exactly is this enormous brick wall that folks need a boost from management to climb over? Then why wasn't the hierarchy fixed? Instead we somehow ended up in this huge metastructure debate and changed everything around. It was hardly a huge debate, unless your only metric of measurement is number of posts. Take that debate, and then re-imagine it as an event in the physical world, with folks having face to face contact. You'll find that none of these debates are really that big. They just seem big, because electronc communications can be so inefficient. Personally, I'm opposed to a return that that hierarchy. The idea that somehow desktop, server, and other such projects should sit at an exclusive top-table doesn't work for me. Gentoo would be much more effective with having a core management team that covered our key operations (infra, devrel, userrel, pr, releng, and 'tools' - portage and catalyst), and which ensured that they all worked together to give the outward appearance of an organised distribution. Have management focus on what forms the spine of the Gentoo organisation. The lack of this management structure is, to pick one example, behind the grief Infra are getting over the long-term problems with bugzilla. Folks aren't complaining about bugzilla any more; they're complaining about the problem continuing. Effective senior management would have done three things in particular here which would each have made a difference: a) They would have provided oversight on Infra's handling of the problems. b) They would have communicated effectively with the wider organisation, explaining what was going on, why, and when it would be resolved. This communication would be early, it would be frequent. c) They would provide Infra with resources they can't get on their own to solve the problem, including additional budget. It's been agreed on -dev that it's not the existing Council's job to do any of these things wrt the ongoing bugzilla problems. So everyone's left with a service that's not fit for purpose at the moment, and only Infra to grumble about. Everyone loses sight of the steps Infra is taking to resolve matters, and nobody wins. Your top table of herds does nothing to address what Gentoo really needs. It's a step backwards at best. Official votes, sure. But what about GLEP discussions on -dev? That's the only way anything major ever happens, and it might as well be a requirement for a unanimous vote among all ~350 developers. The only time I can recall even a single dissenter before a GLEP moved on to the council was brix on Sunrise. I call bullshit on this. Big time. There are lots of major things happening all the time - you're one of the people who make this happen - and they don't require GLEPs. GCC upgrades, X.Org 7, Portage 2.1, Gentoo Overlays, Java 1.5 - these and many _many_ more are all major things for the users affected by them. What major things do you want to see that aren't getting done because of the perceived need for GLEPs? It's also worth pointing out that we're hardly snowed under with GLEPs. There has been only 51 in the last three years; that's less than two a month on average, and just under 50% of GLEPs were filed in the first twelve months of the GLEP process's existance. Your recollection is faulty; there _is_ no GLEP for sunrise. The basic cause always comes down to weak or non-existent management. Yes, and that's exactly my point. We need stronger management. We need _appropriate_ management.
Re: [gentoo-dev] Democracy: No silver bullet
On 8/24/06, Donnie Berkholz [EMAIL PROTECTED] wrote: A distribution is more than just an entity that packages upstream tarballs. I agree with your point, but it misses a large chunk of what we do. We do more than that, sure, but the vast majority of the day to day work in Gentoo is exactly that - packaging software released by upstream, and fixing bugs reported back from users. What do you do that goes beyond this? If this is the Gentoo vision, then why are we even doing anything else? Because folks want to? Because we've been recruiting people to shoulder the load, instead of recruiting them into a culture? Because we want to see Gentoo run on a wider variety of hardware than $upstream has access to? Because we want to make Gentoo more accessible to folks than it was in the past? What activities are we doing that don't directly support the Gentoo vision? We've already reached our only goal, which is packaging stuff, and all we need to do is bump it. People need to feel that Gentoo is _moving forward_, that it's actually going somewhere. We have no organisation that's going out there making deals with commercial entities, ISV partners, nor users. In that respect, we're a completely different beast to RedHat, SuSE and Ubuntu. You're not the first, and you won't be the last, to complain that we're not going anywhere. My question is simple : where do folks want to go, and what is stopping them getting there? Seriously - what exactly is this enormous brick wall that folks need a boost from management to climb over? Then why wasn't the hierarchy fixed? Instead we somehow ended up in this huge metastructure debate and changed everything around. It was hardly a huge debate, unless your only metric of measurement is number of posts. Take that debate, and then re-imagine it as an event in the physical world, with folks having face to face contact. You'll find that none of these debates are really that big. They just seem big, because electronc communications can be so inefficient. Personally, I'm opposed to a return that that hierarchy. The idea that somehow desktop, server, and other such projects should sit at an exclusive top-table doesn't work for me. Gentoo would be much more effective with having a core management team that covered our key operations (infra, devrel, userrel, pr, releng, and 'tools' - portage and catalyst), and which ensured that they all worked together to give the outward appearance of an organised distribution. Have management focus on what forms the spine of the Gentoo organisation. The lack of this management structure is, to pick one example, behind the grief Infra are getting over the long-term problems with bugzilla. Folks aren't complaining about bugzilla any more; they're complaining about the problem continuing. Effective senior management would have done three things in particular here which would each have made a difference: a) They would have provided oversight on Infra's handling of the problems. b) They would have communicated effectively with the wider organisation, explaining what was going on, why, and when it would be resolved. This communication would be early, it would be frequent. c) They would provide Infra with resources they can't get on their own to solve the problem, including additional budget. It's been agreed on -dev that it's not the existing Council's job to do any of these things wrt the ongoing bugzilla problems. So everyone's left with a service that's not fit for purpose at the moment, and only Infra to grumble about. Everyone loses sight of the steps Infra is taking to resolve matters, and nobody wins. Your top table of herds does nothing to address what Gentoo really needs. It's a step backwards at best. Official votes, sure. But what about GLEP discussions on -dev? That's the only way anything major ever happens, and it might as well be a requirement for a unanimous vote among all ~350 developers. The only time I can recall even a single dissenter before a GLEP moved on to the council was brix on Sunrise. I call bullshit on this. Big time. There are lots of major things happening all the time - you're one of the people who make this happen - and they don't require GLEPs. GCC upgrades, X.Org 7, Portage 2.1, Gentoo Overlays, Java 1.5 - these and many _many_ more are all major things for the users affected by them. What major things do you want to see that aren't getting done because of the perceived need for GLEPs? It's also worth pointing out that we're hardly snowed under with GLEPs. There has been only 51 in the last three years; that's less than two a month on average, and just under 50% of GLEPs were filed in the first twelve months of the GLEP process's existance. Your recollection is faulty; there _is_ no GLEP for sunrise. The basic cause always comes down to weak or non-existent management. Yes, and that's exactly my point. We need stronger management. We need _appropriate_ management.
Re: [gentoo-dev] Democracy: No silver bullet
On Fri, 25 Aug 2006 20:41:16 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | Seriously - what exactly is this enormous brick wall that folks need | a boost from management to climb over? 1. Portage. 2. Tree QA. 3. www.g.o. Those three should get you started. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
Chris Gianelloni wrote: [Fri Aug 25 2006, 01:35:53PM CDT] See, you missed that we're talking with the idea of people belonging to a project. If you work on my project and quit, I'll know. If you go AWOL, I'll know. I can then simply ask Infra to remove your access. It really should be that simple. Unless I'm missing something, for your vision to pan out we would need a comprehensive project structure with every package and every aspect of Gentoo development being part of a project that has an active and competent lead. One of the things that doomed the previous management system was the fact that project leads who are both competent _and_ active tend to be in short supply. (It's the _active_ part that really tends to be the bigger problem. Real life does tend to interfere, and at least in the past we have lacked a good way to efficiently replace project leads who become less active.) If Infra is unable to do so due to being understaffed, then they should get more staff. That's a bit like saying that if you can't afford something, you should get more money. It's a true statement, but it somehow ignores the fact that doing so may be difficult. *Shrug* The last time I asked infra about this, Kurt told me that their retention rate for new folks is extremely low due. There are countless projects out there, many with many more developers than Gentoo, that are capable of maintaining themselves quite well. Why are we so different? Perhaps because we compartmentalize rather less than most? How many people working on KDE are working on a broad swath of KDE? Yet it is common for Gentoo devs to be part of several different projects while maintaining packages all across the tree. Moreover, that's the case not due to historical accident but to design: A gentoo dev w/ CVS rights has the power to do (almost) anything. Originally that level of flexibility was intended to allow a very small number of people to reinforce each other, but even now it is something that sets Gentoo apart. My guess is that it also makes Gentoo devs less willing to pigeon-hole themselves into a rigid project structure, but I don't really have any evidence of that. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp6uCrXHt1yk.pgp Description: PGP signature
Re: [gentoo-dev] Coda file system needs new maintainer
* Maurice van der Pot [EMAIL PROTECTED] schrieb: On Thu, Aug 24, 2006 at 01:58:05PM +0200, Enrico Weigelt wrote: I've got switching my nfs installations to coda for right some time, and so I'd offer to maintain the package. Actually I'm looking for a Gentoo developer to take over maintenance. Sorry, I can't serve this. I can just offer you some of my time :) cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Xmms needs to die.
Steve Dibb wrote: So, I'm curious -- did anyone ever come to a decision what to do on the matter? The list traffic seems to be dying down. Maybe I just missed the final decision email. Not that it really matters, but here's my 2 cents: If its a pita to maintain, hard mask everything and just say sorry, no bugs fixie unless you want to maintain it. See http://dev.g.o/~foo/xmms.html for reasons At least that way it will still be in the tree for those that want to use it. The second thing is, why does it even matter if its out of the tree or not? Those who are currently using it will still have it installed on their system, anyway. I'm still using audacious 0.2.3 even though it's been taken out, and I won't upgrade until my favorite plugin is ported. I'm fine with that. Anyway, whatever. Do what works best. :) Steve ++ I don't see how whining about a package you don't maintain, nor helping out with it helps anyone. Either it stays in pmask, or it stays in sunrise (since I would bet 5 bucks it ends up in sunrise after getting punted). The sound team has been very courteous in informing the community on the matters pertaining to xmms, so either someone picks up the slack for it, or the affected users (developers and arch teams included) find another player. I don't see why sound should break their backs just so everyone can have their cake. It reminds me of the whole why isn't X,Y,Z stable!. You are an empowered smart user, I think you can figure out how to keep a package that is not in the tree installed on your systems. -Alec Warner -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Xmms needs to die.
On Fri, 2006-08-25 at 16:49 -0400, Alec Warner wrote: I don't see how whining about a package you don't maintain, nor helping out with it helps anyone. Either it stays in pmask, or it stays in sunrise (since I would bet 5 bucks it ends up in sunrise after getting punted). The sound team has been very courteous in informing the community on the matters pertaining to xmms, so either someone picks up the slack for it, or the affected users (developers and arch teams included) find another player. I don't see why sound should break their backs just so everyone can have their cake. It reminds me of the whole why isn't X,Y,Z stable!. You are an empowered smart user, I think you can figure out how to keep a package that is not in the tree installed on your systems. Sound herd will have an overlay as soon as we elect a new leader and put xmms there. This is a solution that prevents users to turn their back from us. So xmms will only be used in special cases when someone looks to play something other players don't play. We will keep the future in mind like we need to inovate and put xmms2 in the tree. -- Gentoo Linux Developer http://dev.gentoo.org/~metalgod -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
Donnie Berkholz wrote:
From what I see, projects are pretty free to govern themselves. How do
you see it differently?
As Weeve said, he's still trying to get people to stop breaking SPARC
keywords, just like 3 years ago. It's just when trying to do anything
larger than a single project that you run into issues.
Thanks,
Donnie
Projects that are by intention gentoo-spanning
(infra,qa,portage,council) all have issues.
QA:
QA doesn't want to step on toes, Halcy0n tried to give QA the power to
fix things and it failed. Developers (nor gentoo) can say we want good
qa! but it seemed that the qa as the QA team define{s,d} it was
inappropriate, because there were numerous issues.
What kind of QA do we want, is a good question; because I don't think
anyone here knows, and it's something I'd like to see answered.
PORTAGE:
Portage developers are afraid to put anything new in the tree for fear
of breaking things (and somewhat rightly so). But as noted, it also
means you get new stuff very infrequently.
I think the portage team has either done a poor job of bringing their
issues to the table; or the community has done a poor job addressing them.
INFRA:
Infra could be so much more as far as giving out access to do stuff, as
I see it now you have to be on rather good terms with them to get
anything done. However a correlation here I've noted is that people
that seem to do work (and get noticed for it) have good relations with
infra and those that don't, well don't ;)
I don't really have a solution here, I'm not on infra; I realize that
you guys maintain a lot of stuff you have very little idea about, when
there is a problem in $area, you have a guy to cover that, but that
person isn't always available and it creates frustration. I can see why
taking on new projects and ideas are difficult given the manpower issues.
COUNCIL:
The council technically has the authority to do most things,
being our elected representatives. They don't do much; mostly this is
our fault as the community itself sets their agenda. This is where I
think the current system fails, people are afraid to take issues to the
council. Part of this is because issue X is not appropriate for the
council, which I think is hogwash in many cases. If they aren't doing
anything at these meetings I would think some global issues are being
repressed rather than assuming we have none to address (which many would
agree is false). If the meeting agenda is empty, give them other issues
to work on.
-Random Rant Guy
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
PORTAGE: Portage developers are afraid to put anything new in the tree for fear of breaking things (and somewhat rightly so). But as noted, it also means you get new stuff very infrequently. I think the portage team has either done a poor job of bringing their issues to the table; or the community has done a poor job addressing them. So Brian Harring poked me on irc a bit, and I will expand upon this a bit. This is not to say that the portage team does nothing (many members do very little in terms of raw code, myself included which is why I left the project). Features get written, bugs get fixed, new versions get released. However there are what I would call key requirements that Gentoo (the community and developers) require. These requirements are not getting met by the portage team. The common point against this is developers do what we want, we volunteer..etc. I would think at this statement the community would look for new team members (recruit) those able to complete the features that are required. You can't bitch at a team that doesn't implement the things that are required. However, you can't depend on a team like that either. That would be like me going to the and making a reasonable request and then being told that they can't do that they are only volunteers, and hell, it doesn't interest me. The Portage Team should have a duty to the community in this regard. In the end I get a realization that a core team is a better idea than I initially thought. While in some cases turning down a request based on I'm a volunteer is a reasonable request, there are areas where this is not a good thing to have happen (Infra, recruiting, PR to some extent, core-utilities). I don't really want to criticize the portage team, it's filled with a bunch of very knowledgeable folks. However I don't think the team as it stands now is helping Gentoo as a whole. It is (as Ciaran mentioned earlier in this thread) only holding Gentoo back. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
Chris Gianelloni wrote: On Thu, 2006-08-24 at 22:36 -0700, Donnie Berkholz wrote: From what I see, projects are pretty free to govern themselves. How do you see it differently? How do you kick someone out of a project? Currently, I know of no way to do so. What process is required for someone to join a project? Currently, anyone can add themselves to any project without any consent from the project itself. The only real counter-examples to this are projects which require some kind of specific authorization to join, such as devrel or infra, since they have access controls. Who is responsible for an individual developer's work, aside from the developer? If a developer joins a project and doesn't do what he's promised, nothing happens to him. If he doesn't work his bugs, nothing happens. Why not? What if the developer does poor work? This really ties into the above, but what happens if someone is found to not really possess the skills necessary to be in a project? Right now, we cannot do anything about this person but hope that they either magically gain the skills, or leave the project on their own accord. That's not true, from my reading of the developer handbook. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=5 says: Decisions within a project can be made by the people inside project itself, of course coordination between the projects is necessary. The (sub-)project leads are usually responsible for doing this. As far as I'm concerned, project membership is a decision within the project. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] freenet6
For all 2 of the users of freenet6, I mistakenly removed it today and then restored it to cvs. Between the deletion and restoration there was a cvs-rsync run, so it may be broken for a sliver of time. Hopefully if should be fixed now. Sorry for my mistake, I had cvs rm'd the files and then checked bugs to make sure and realized chris had taken the package, but I forgot to undo the rm'ing of the files, so when I deleted bidwatcher I er...deleted freenet6 too. Go me. -Alec Warner -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] TreeCleaner [Cleanings]
app-emulation/pose and net-misc/bidwatcher were punted today. -- gentoo-dev@gentoo.org mailing list
