Re: [gentoo-amd64] Re: Why Is Gentoo So Far Behind?
Frank Peters wrote: Maybe I'll post some ebuilds for cooledit and nedit. These are two text editors for which I've filed bug reports and fixes, but there has been no action yet due to lack of maintainers. It may be a while though. After quickly looking through the developer's manual, I can anticipate a fair amount of study before I can write even a simple ebuild. If you take the time to learn there is an option to become a proxy-maintainer of a package. Essentially you would actually maintain the package, but a gentoo dev would be officially responsible for it and would supervise all work on it. This works well for specialized ebuilds that would otherwise not be in portage, but where we have an interested user. The dev that works with you would also be able to help out with any sticky ebuild issues. Keep in mind that simple ebuilds actually are fairly simple. The only issue is that some packages are really picky about how they are built and that can get tricky. Also, many devs (such as me) aren't intimately familiar with every eclass out there - ebuilds can do quite a bit and you can get started just knowing a moderate amount of the basics. Half of the job of a dev is just knowing what does and doesn't cause bigger issues so that you can safely get stuff done without having to actually know everything. Of course, in a proxy-maintainer relationship the proxy doesn't really need to worry about this stuff since somebody else is providing some QA oversight. There are also lots of developer/staff roles in gentoo beyond just maintaining packages. There are some that just do documentation work, and many who focus primarily on testing/stabilizing packages. It isn't for everybody, but if you have decent IT skills and a reasonably mature mindset it isn't that hard to get into. More than anything you need to be somebody who can be trusted - every time you run emerge you trust that gentoo won't hose your system, and to make that happen we need to have devs who understand basic QA and are responsible with the power they wield.
Re: [gentoo-amd64] Re: Why Is Gentoo So Far Behind?
On Tue, 16 Jun 2009 08:54:41 -0500 Chris Faulkner wrote: > I tell you what, do what a lot of people are doing and that > is making your own ebuilds. Make a website, put your ebuilds on it > and test it out. You will further gentoo-dev out much better than it > is now. > Maybe I'll post some ebuilds for cooledit and nedit. These are two text editors for which I've filed bug reports and fixes, but there has been no action yet due to lack of maintainers. It may be a while though. After quickly looking through the developer's manual, I can anticipate a fair amount of study before I can write even a simple ebuild. Frank Peters
[gentoo-amd64] Re: Why Is Gentoo So Far Behind?
"Arttu V." posted fecdbac60906160512p588c72c3ma0e7a38d6b48c...@mail.gmail.com, excerpted below, on Tue, 16 Jun 2009 15:12:16 +0300: > For example, IIRC the > default emerge printouts don't give you any indication that there are > actual later versions available (even just in the portage tree, let > alone in overlays which might not even be added locally). > > Thus, especially new users are bound to be vulnerable into going into > this OP's wondering-mode of "wtf, I thought Gentoo was supposed to be > bleeding edge, yet now I have the equivalent of Debian stable". :) > > Maybe some kind of small indication or hint of "later versions' ebuilds > present but using this older one" could be added to emerge's printouts? > Or has that been tried and found out to be bad? "Patches welcome?" FWIW, I think that's just part of the whole, "We document stuff, then expect our users to be big boys and girls and do their own adminning. We've never claimed to be there to hold your hand the whole way thru, particularly if you can't read the documentation" thing. Gentoo does try to provide sane defaults for stable users, and does actually quite well documenting how to customize things and the advanced tools and what they do, for those who prefer something more than the stable defaults. But it's really a shame how many users never read beyond the installation section (Part 1) in the Gentoo Handbook. I know from personal experience, because before I had Gentoo installed, I had read the entire handbook and had actually been following the dev, amd64, and user lists for weeks, how much more effective actually reading that extra documentation made me, to the point I was posting directions to people running Gentoo, about how to do stuff in Gentoo, before I was even up and running it myself! So if people aren't aware of all that's available to them, it's not because Gentoo hasn't made it available, or doesn't document it. It's there. But we aren't there to hold people's hands who can't read the documentation, and who equally can't ask in the forums or on the lists. If at that point they don't see the advanced stuff, it's probably for the best, because they'd only hurt themselves with it anyway, given they obviously can't see what's as close to right in front of their faces as we can manage, with every urge to read it Gentoo can provide. And, if at that point they decide Gentoo's not for them, it's probably because it's NOT for them. After all, we actually expect that people can actually "RTFM", and they're demonstrably incapable of doing so on either their own volition or the most urging we can do. So indeed, probably better they go elsewhere at that point. -- 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-amd64] Re: Why Is Gentoo So Far Behind?
Frank Peters posted 20090615222731.b12f5121.frank.pet...@comcast.net, excerpted below, on Mon, 15 Jun 2009 22:27:31 -0400: > In a lot of cases, for example perl, Xorg, and gcc, the Gentoo > distribution lags far behind the latest available releases. Even > allowing the "~amd64" unstable series, this remains true. Why is this > so? Others posted their take. Here's mine. I don't know enough about perl to have a reasonable opinion there, but I besides using them, I follow the Gentoo dev list, and happen to know what's going on with the other two. Consider what a well tested and working gcc means to Gentoo, as opposed to what it means for your typical binary distribution. Really, that should be enough right there if you think about it, but let's just put it in writing. In a binary distribution, a gcc that fails to build particular packages is no big deal. In Gentoo, it's a *MAJOR* issue. In a binary distribution, a gcc that gets broken somehow is again, no big deal. In Gentoo, it's a *MAJOR* big deal, possibly necessitating a complicated recovery procedure involving unpacking a stage tarball somewhere and binpkging its gcc, to then install over the broken one on the main system. So, naturally, Gentoo's way more cautious about unmasking a particular gcc version. While micro-version changes (4.3.2 -> 4.3.3) are generally bug-fix only anyway and thus get moved thru the process pretty fast, normally for minor version changes (4.3 -> 4.4), the process is far slower and more complex. I regularly unmask and test new gcc versions, so I know from personal experience what it means and the hassle early users go thru. First, pre-release, weekly snapshots and definitely the -rcs are available in the overlays, for anyone wishing to go thru the hassle of testing them. Gentoo devs therefore get a bit of a head-start, knowing the trouble areas and often patching troublesome packages to build with the new gcc before it's even released. Then, when it's released upstream, the new gcc ebuild is usually in the tree, hard-masked for testing, the same day. Based on the pre-release overlay testing, they know the ebuild itself generally works by then, and barring unusual issues, gcc itself should compile and install from the ebuild. However, at release, there's dozens of packages that have yet to be updated to be able to actually build with the new gcc. Many of them require patches. Others require restricting certain CFLAGS or the like. A gcc upgrade tracker bug is normally open by then, with a list of all the individual package bugs. As patches are developed and applied (at this point, to ~arch packages), the bugs are resolved, and the list of unresolved bugs on the tracker shrinks. Meanwhile, keep in mind that another difference between Gentoo and binary distributions is that Gentoo effectively ships often tens, sometimes hundreds, of different versions of the same package, due to USE flags. Obviously, even testing every package with a late gcc -rc version isn't going to catch all the bugs, because each package is effectively many slightly different packages, due to USE flag combinations, and it's simply impossible to test them all, period. Thus, after release, users like me start testing, and often discover NEW ways in which a particular package breaks with the new gcc, filing even MORE bugs to add to the tracker, and eventually get fixed. The binary distributions really have it easy in this regard, as they ship one, perhaps two versions of a package, with various bits enabled or disabled, take it or leave it, or compile it yourself, in which case they do NOT provide support, while Gentoo does. So eventually an ~arch version of most packages has been patched and tested to work (under at least some configurations) with the new gcc, and it's considered on the way to stable, enough to unmask it to ~arch. Then the process not quite, but almost, starts over again. Not quite because at least they have the list of packages and known ways to fix them, now. Normal package stabilization qualification is 30-days in ~arch without an open bug, at which point a package maintainer opens a keyword stabilization bug, asking the various archs to test and keyword stable. (Note that it's not the package maintainer that marks stable, it's the arch devs and their ATs, who test it, marking it stable only if it works with an all-stable system config. Also note that while Gentoo does have package.keywords as a method to run a partially unstable system, such a system is /not/ tested, and thus is far more likely to run into issues than an all-stable or all-unstable system.) However, with a toolchain package like gcc, the process is far more complex than that. Remember that list of typically a hundred packages or more that had to be patched to build with the new gcc? NOW all those packages have to make it to stable! Only when there's a stable version of every one of
Re: [gentoo-amd64] Re: Why Is Gentoo So Far Behind?
Well Frank, First and foremost, Gentoo is quite far ahead of the other distros. I choose Gentoo on my server farm specifically because it is much higher ahead in the stable department so much more than Ubuntu and RHEL which ironically are the leaders in server OS deployment. All too often I run into data centers that specifically run Ubuntu or RHEL and when I look at the version #'s on those machines and compare them to my gentoo servers, they pale in comparison. Frank, I think you are jumping the gun on this issue. I'm not going to flame you, but if you really want to participate in gentoo-dev, I will totally not mind you joining the effort to get the newer packages put out. I tell you what, do what a lot of people are doing and that is making your own ebuilds. Make a website, put your ebuilds on it and test it out. You will further gentoo-dev out much better than it is now.
[gentoo-amd64] Re: Why Is Gentoo So Far Behind?
"Arttu V." posted fecdbac60906160403r3d81bdc3uedcb0f6c89b50...@mail.gmail.com, excerpted below, on Tue, 16 Jun 2009 14:03:33 +0300: > Yes, you test both new packages and new devs extensively. :D > > I think that was the crux of the last "low manpower" thread over at > gentoo-dev couple months ago, when Mr Duncan was trying to find a way to > become a dev without camping for hours in irc. :) Interesting to see that come up here. I guess I have mixed feelings about that exchange. =:^s But it's definitely encouraging to see someone was reading... and thought enough about it to mention it again weeks (two months already? maybe) later. Honestly, thanks. =:^) Meanwhile, I've decided that while as a user and my own sysadmin, Gentoo fits my automated but customizable ideal of a distribution like a glove, the same cannot be said about being a dev. Technically, I may not be a wiz-kid, but I'm OK at it, enough to have been told by several that they'd be happy to mentor me as a Gentoo dev, even (funny how that works). But socially, not so much. My generation (I'm 42) was comfortable with email and usenet, but not so much with "instant" text technology IRC/IM/texting. At least some of us are just too deliberative for it to work well. And that seems to be where Gentoo's development is really at now days, both socially and technically. So I'd not really fit in, regardless. I still think it's stupid to on the one hand, complain about how short handed you are, while on the other, saying they'll reject a dev just because the applicant isn't interested in using a technology he's not comfortable with for what is after all, effectively a job interview, thus already a stressful situation. Whatever. Obviously no non-IRC user fits into their club, and I'm not going to spend further time trying to crash their party. But I wasn't just asking for me, I was trying to nail down the answer for others that might be interested. Which I effectively did. Meanwhile, there's other projects and indeed, other parts of the Gentoo project, where I can contribute, and where those contributions do make a difference. So that's what I'm focused on now. (Presently, in addition to my Gentoo testing, bug reporting, and list activity, I'm active on the pan (gtk news client) lists, where I am I believe the senior active regular, and I run direct Linus git kernels, where I've reported and git- bisected a number of bugs over the last several releases, such that among others, AMD 8000 chipset and Radeon r200 chip users specifically, have me to thank that the bugs were resolved before full version release. =:^) -- 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
