[gentoo-dev] Resignation
All, I'm afraid that I find that my position with Gentoo is no longer tenable. Over the past year and especially over the past few months the ability to keep Gentoo a coherent and smooth environment has been eroded and hindered at practically every opportunity by bad decisions, staff, and in some cases, downright incompetence. It transpires that from the recent barrage of developers leaving, the disquiet and increasing lack of congruence of the developer (and to some extent also the user) communities that something is inherently wrong. I'm leaving it as an exercise to the reader to explore exactly what (if anything) is wrong. Seeing as we have failed to address these challenges over the course of many months and as a result of continuous recent discussions (which half the time end up being totally redundant due to miscommunication) both on -core and on -dev, it is evident that something is wrong with the core management (or lack thereof, depending on your point of view). I no longer have the commitment or desire to follow the road in solving the above challenges. I'm not really sure whether there even is a solution. I'd like to add that I have really enjoyed my time in the past three years working with Gentoo and helping to contribute to the then vibrant and dynamic community. Lately however, the fun and the motivation just hasn't been there for the reasons I've outlined above; it's finally taken its toll, and I believe the time to move onto new projects and ventures has finally come for me. I would like to wish all of you the very best, and would like to thank all of you who have (and haven't) made my time here so enjoyable. So long, and thanks for all the fish... Tim. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make FEATURES=test the default
On Sat, Aug 05, 2006 at 02:26:16AM +0200, Jakub Moc wrote: Kevin F. Quinn wrote: I'd like to suggest we make FEATURES=test (and therefore USE=test) the default behaviour, rather than the opt-in we currently have. Far too many packages fail their test phase. Sure everyone likes to watch glibc failing? :P /joke Well, can't be done until bugs such as http://bugs.gentoo.org/show_bug.cgi?id=69343 are solved (at least as in sticking RESTRICT=test there) instead of being ignored. At the very least, ebuild maintainers and ATs should be running with tests switched on. If the tests are known to fail then the ebuild can either RESTRICT=test, or just return successfully from src_test() where the test report is useful even if some tests fail. See above. And even then, I don't think it's a good idea to force this upon users. Lots of packages have tests that are very time-consuming, and there are packages that always fail tests and it's pretty much expected (PHP is one of them; and while the failure isn't fatal there, it still takes tons of time to go thru those ~2000 tests). And there are tons of packages where tests are more or less unmaintained. Agreed. It may be better to instead have a FORCE=test on certain ebuilds (mainly sci-* stuff where you want to be sure the numbers are coming out correctly) -- adding FEATURES=test to the default set will cause serious breakage and will take quite some time to be fully fixed across the whole tree. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On Sat, Jul 29, 2006 at 03:07:03PM +0200, Thierry Carrez wrote: Those were nominated but did not (yet) confirm their participation : plasmaroo I'll decline, maybe next year... :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 49 - take 2
On Mon, May 22, 2006 at 08:47:22AM +, Thomas Cort wrote: So what I suggest is the following: While it is desirable that the primary package manager be maintained on official gentoo infrastructure, under the control of gentoo developers, it is not required. During the path to becoming the primary package manager, the package manager maintainers must be asked if they would like their project to be an official Gentoo project. All rules about projects apply. The package manager maintainers have the right to refuse such an offer if there is a team of at least 3 Gentoo developers that understand the package manager source code and are willing to deal with bugs, testing, feature enhancements, modifications, and integration. Maybe I'm reading it wrong but the above sounds like if there's less than 3 Gentoo developers that understand... ... ... the package maintainers *don't* have the right to refuse and magically get sucked into Gentoo whether they like it or not? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 09:22:45PM +0100, Ciaran McCreesh wrote: On Wed, 17 May 2006 16:12:09 -0400 Daniel Ostrow [EMAIL PROTECTED] wrote: | Unfortunately in this case there is only one cat, he has only one skin | and there is only one knife with which to skin him. Chris asked if | paludis can build a release (meaning an official Gentoo release), | which means following the Release Guidelines to the letter. If you look at it that way (which isn't what he actually asked to begin with), then the question is is Paludis identical to Portage?, which it clearly isn't. A more useful question is can Paludis give the same end result as Portage?. So if it can give the same end result, it can be a replacement. So hence paludis should be able to do what Portage + Catalyst now do. Which you've not-so-clearly said is not the case; unless paludis has now manifested the ability to generate bootable ISOs across nine architectures, which it clearly hasn't. Therefore paludis can not deliver the same end result as Portage. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 03:49:16PM -0500, Andrew Gaffney wrote: Tim Yamin wrote: So if it can give the same end result, it can be a replacement. So hence paludis should be able to do what Portage + Catalyst now do. Which you've not-so-clearly said is not the case; unless paludis has now manifested the ability to generate bootable ISOs across nine architectures, which it clearly hasn't. Therefore paludis can not deliver the same end result as Portage. Last I checked, Portage doesn't have the ability to generate bootable ISOs across nine architectures, either :) Well, if you're going to have a package manager that delivers the same result as Portage it must therefore work with Catalyst... or it must replace catalyst. And according to Ciaran: | #1. Can paludis work with catalyst? No. Nor will it ever, nor will it need to. ... hence paludis would be required to do whatever end result catalyst produces (i.e. official release media) for it to be usable as an official package manager. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 10:30:10PM +0100, Stephen Bennett wrote: On Wed, 17 May 2006 20:56:14 + [EMAIL PROTECTED] (Tim Yamin) wrote: Well, if you're going to have a package manager that delivers the same result as Portage it must therefore work with Catalyst... Paludis can produce the same end result as Portage. The reason it won't work with catalyst is that the interface is different. ... so thus you claim it can produce binpkgs (I'm not bothered about the interface, but the support to produce said binpkg must be there and also to utilize said binpkg to install things)... and it can't. Once again, this is going far beyond the scope of the initial discussion. I'm not saying that Paludis should replace Portage, nor that it should be an officially supported package manager. The question is simply one of whether I can add a top-level paludis profile without people complaining overmuch, or whether I have to go through the arch teams and make sub-profiles in 4 different places under default-linux/. Yes, getting this thread back on-topic would be nice. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union + suggestion for global dev conference (at bottom, if you want to skip)
On Sat, Apr 29, 2006 at 10:33:11PM +0100, Stuart Herbert wrote: __Problem: Developer Growth__ Why do people have to take a test? There are certain skills we need a developer to demonstrate before we can give them commit access. There is currently no opportunity for a would-be-developer to demonstrate all of those skills before they get commit access. That and the test is standardized: the range of questions it asks people should know the answer to. That's why we have recruiters and don't give out access to anybody... But I don't see overlays as a replacement for our tests ... they're only a training ground to help get people ready to take the tests. +1 The magic thing about Gentoo is that everything finds its own level. That's our secret formula. If an area of working with Linux is important enough to enough people, Gentoo becomes strong in that area, and its weaknesses reflect where something simply isn't important enough for people to make an effort. It's a beautiful thing when it works. That's the beauty of community-based distros -- with a commercial distro you can just wave cash and most of the time, things get done. We can't do that but sooner or later somebody who has the necessary skills to fix the problems starts shouting and problems do get fixed. It's also the thing that puts a lot of people off. Many people fear uncertainty. They need to exist within a plan or some sort of structure in order to be able to function. Our approach is uncertainty in motion. Your only guarantee is what rsync delivered this morning. Yeah, and this is the problem we need to solve to get more corporate adoption. The master plan is simply to deliver what $UPSTREAM invents, as close to what $UPSTREAM intended as possible. That's a different world to what most people know, and it's a message we do a piss poor job of communicating to anyone and everyone. Yeah, I think Gentoo's only real PR to users is Here you go, try it. Those that do soon find out a lot of things just work which is exactly what people want. Splitting up the tree into two - development/testing arch trees - would be the sensible thing to do. The counter argument here is that the arch trees would wither and die, because all the fun would be happening in the other trees. I don't buy that for an instant. Simply make the arch trees the default on the install media, and 80% of the userbase will never even notice that the other tree even exists. I don't think this will work. Your major problem is going to be merging changes from users working on the arch trees to the dev trees and vice- versa... users would (unknowingly) work on the arch trees (possibly on some pretty serious changes) and then be told none of them apply any longer. The advantage of one tree is that development is streamlined and is always going in one direction - forward. With large branching this is still doable. But it needs time and more importantly people and also the motivation to do the job. And that usually means $$$. Those behind that proposal mean well, but I personally feel that their focus isn't where it will do the most good. The proposals that Mark has posted on -dev are for a reactive, enforcement-first team that's focused on applying coding standards across all our packages. A proactive, education-led team that's focused on finding out what's actually hurting our users will deliver more benefit to Gentoo in a shorter period of time. Give a man a fish, and you feed him for a day. Teach him how to fish, and you feed him for a lifetime. It's not hokum. I think that's the underlying idea -- if developers aren't up to scratch the QA team would notice this pretty quickly and teach the man how to fish the proper way. Man is a political animal, and this sort of voting structure I find too simplistic and too naive. How does it cope with the malicious dev who takes every opportunity to slander another one behind their back? If you tell someone something often enough, people accept it as the truth - even if it's a lie. And people are lazy. They'll take information from someone they trust, and not take the trouble to learn whether or not that information is true. That's why advertising works :) +1 In any walk of life, it's a sad but true fact that most of the staff in most organisations do not get what the organisation is, and what its culture is, to the extent that they can be trusted to preserve it without assistance. Every one of us has a unique perspective on the world, and no two of us have an identical perspective. In one aspect that's what makes Gentoo work. Somebody comes along with a product/idea and somebody else comes along with can I make it flexible enough to also do X, Y and Z? [Look at catalyst, for example] Gentoo should be a fun environment. I don't see how turning it into a popularity contest brings back the fun. +1. Things generally do need a management structure. I think
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 11:57:30AM -0700, Ryan Phillips wrote: Bypass the council. The council should be there only for when we get sued, and manage the money we make. Does anyone agree that having a council is too political? I strongly believe it stifles gentoo. You're confusing Council Foundation... Foundation handles moolah and the we get our asses sued scenario, not the Council. The Council helps push Gentoo forward. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 01:55:01PM -0500, Grant Goodyear wrote: CVS doesn't do branching nor tags very well... __Problem: CVS__ CVS is one of the worst application ever created. The portage tree needs to move to subversion. A lot of the problems within the project would be solved by using a better SCM system. The previous problems regarding the Live Tree and Developer Growth would be solved, IMHO, by just switching. Branches Work. Tags Work. Reverts work. Moves work. I don't see any reason not to use it. It just plain works. Have you tried using SVN for the portage tree? I don't know if anybody has recently, but in the past when people tried there were two significant problems: SVN requires at least 2x the tree size for storage on the local machine, and checkouts take something akin to an order of magnitude longer than CVS. The former is annoying, but liveable, but the latter is a deal-breaker. Speaking of which, has anybody done any tests with svk? (http://svk.elixus.org) And: http://svk.elixus.org/?WhySVK -- it would be interesting to compare checkout performance on it as well. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for app-laptop/ibm-acpi
On Sat, Apr 22, 2006 at 12:36:53PM -0700, Drake Wyrm wrote: Henrik Brix Andersen [EMAIL PROTECTED] wrote: The kernel module found in app-laptop/ibm-acpi has been included in the vanilla kernel since linux-2.6.10. There has been no releases of the stand-alone module since March 2005. Is Gentoo planning on eradicating the 2.4 kernel from the tree in the next few weeks? No, some of the 2.4 kernels (e.g. hardened/gentoo-sources) are still maintained. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo 'Images' without gcc/portage?
On Fri, Apr 14, 2006 at 06:31:31PM -0500, Allen Rohner wrote: I have been a Gentoo user for several years, but this is my first step into gentoo development. I'm looking at the feasability of using gentoo for a product at work. Is it possible to use a Gentoo host machine to create a linux 'image' (ramdisk/ext2fs/iso) that does not contain portage or gcc? I have looked at several embedded gentoo web pages, and am familiar with the ROOT=/opt/image emerge busybox dropbear type command line, but all of the examples I've seen create a portage tree on the image. Additionally, getting past bootstrap.sh is painful. Yes, use catalyst to generate a stage4/LiveCD and then add gcc to your list of packages to unmerge once the stage4/LiveCD is ready. Is this possible? Is it a good idea? Yes and maybe if you're limited on space. If you're doing this for a server which you want to keep flexible and manageable I'd say it's a bad idea. Removing Portage itself probably isn't a good idea, having systems without a Portage tree works fine (you can just emerge sync it back in when you need it). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] seeing a new trend of laziness developing.
On Sun, Feb 26, 2006 at 11:40:44AM -0500, Ned Ludd wrote: When people go out of their way to file a bug for you or a team you are on. Please _please_ don't be lazy and just close/reassign/other it with a '.' A period is the most useless way to respond to a bug. If you can't take 2 seconds out of your life to say something as simple as. 'Fixed in CVS/This is an upstream problem/etc' or anything slightly descriptive of what changed. Then your use usefulness to the project starts to come in question. Continuing to close bugs with a simple '.' will result in me making fun of you rightly every time I see your name mentioned anywhere. 232 matches. http://tinyurl.com/pmrmx Needless to say, the same applies for CVS. *Always* commit with a ChangeLog entry and never use See ChangeLog as your CVS commit message -- this makes tracking down changes very difficult due to the non-atomic nature of CVS. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Catalyst{,2} and 2006.0
On Tue, Jan 03, 2006 at 02:33:13PM -0500, Chris Gianelloni wrote: But what about helping by working on an official Gentoo release? Having somebody around to help test LiveCDs and stages is always a good thing. We need both developers and users to do this as the architecture coordinator can always only do so much (limited hardware, time, or otherwise). Interested? Let me know and I'll inform you closer to release time. Thanks. -- gentoo-dev@gentoo.org mailing list
