Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 04 Oct 2006 15:09:06 +0200 Natanael Copa [EMAIL PROTECTED] wrote: What you didn't need to be a gentoo dev to be a package maintainer? Lets say anyone could be marked as maintainer in an ebuild. When there is a bug, the package maintainer fixes the bug and submits an updated ebuild/patch whatever. This person has no commit access. Then a committer, a gentoo-dev (someone with little more experience), just take a quick look at it and commit it. This already happens on some packages (in particular where the upstream author is happy to maintain the Gentoo ebuild). One very important thing is for the Gentoo proxy dev to be listed in metadata.xml (as well as the non-Gentoo maintainer). The Gentoo dev takes formal responsibility for any commits. The trick is to find a Gentoo dev who is prepared to proxy for you; that involves a trust relationship between the dev and the maintainer. The amount of work the dev has to do depends on how well the maintainer follows the Gentoo ebuild rules. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On 2006.10.07 00:26, Chris Gianelloni wrote: On Fri, 2006-10-06 at 10:24 +0100, Roy Bamford wrote: Before you can have useful reports, you need a plan to report against. Like a target date for 2007.0 and its contents. Such a plan depends on other projects delivering the contents in accordance with their own plans. Like real life, these plans will have external dependencies on $UPSTREAM, that Gentoo has little or no control over. Please stop assuming that Release Engineering has any control over what goes on in the tree. Not only do we not have any such control, we also do not *want* any such control. [snip] I'll be honest, Release Engineering work is *very* stressful. My primary goal as the lead is to try to come up with ways to make working on a release easier for the guys doing the work. I don't see how doing reporting improves their lives. After all, we put out four reports a year, two releases, and two meetings between the releases where we plan the next release. Anything more than that is wasteful. ;] -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation Chris, I understand you don't have any control over what goes on in the tree. In Gentoo, nobody outside of the individual projects does. My post was not intended as a crit of yourself or the Release Engineering team. I replied in your part of the thread because Release Engineering are the obvious users of the mooted plans and reports. As long as Gentoo is organised as an anarchy, which I have seen work well in other groups, then the status quo is fine. If Gentoo is to be organised as a single project, then some bureaucracy to oil the wheels is needed. In turn, that would mean setting up a management body of some sort (not Release Engineering) but that's a whole new thread. No replies to that here please. Either organisation can work providing the contributors want it to make it work but there will always be some dissenters discussing change (change != improvement). That's a healthy sign in any group. Regards, Roy Bamford (NeddySeagoon) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Sat, 2006-10-07 at 09:58 +0100, Roy Bamford wrote: I replied in your part of the thread because Release Engineering are the obvious users of the mooted plans and reports. That was kinda my point. We aren't. We really don't care what version of Gnome/KDE/kernel get in the release. We just care that whatever it is, it works. We work with the respective teams, but we leave it up to them what we use. It happens to work out quite well this way. Reports from teams such as Gnome and KDE would be more useful to users, I would think, than to most developers. Any developers that it would impact are likely already in the know. Again, the last thing that I want to do is enforce some arbitrary reporting where it isn't necessary. I do agree that it definitely is necessary in some places, though. It just isn't necessary ubiquitously. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Thomas Cort wrote: There have been a number of developers leaving Gentoo in the past 6 months as well as a number of news stories on DistroWatch, Slashdot, LWN, and others about Gentoo's internal problems. No one seems to have pin pointed the problem, but it seems glaringly obvious to me. We simply don't have enough developers to support the many projects that we have. Here are my ideas for fixing this problem: - Cut the number of packages in half (put the removed ebuilds in community run overlays) I doubt this'll work. I sorta see the portage tree like a starfish -- cut it in half, and within time, you get two starfish. Cut it into three parts, and you eventually get three starfish. You wind up back at square one with double the trouble and none of the fun. - Formal approval process (or at least strict criteria) for adding new packages This might work, but it depends on what criteria/process, and how well its enforced. - Make every dev a member of at least 1 arch team This won't work -- especially if the dev lacks access to the hardware. Some arches are so complex, you need several types of hardware. In mips, for example, if a dev's got access to a low-end box like an Indy or an O2, then letting them help out on basic keywording on common packages probably won't hurt, but it would be much better if they had access to say, more than one type of mips hardware (say, an Octane, and a Cobalt). Also, not every dev would want to have to maintain another box of some obscure/strange arch. It's opposite in my case -- I have 1 x86 box running Linux (not counting my main desktop since its in windows), and everything else is an SGI box (or my one cobalt). I've got spare parts lying around to build two more functional x86 systems, but I've never seen a need to put'em together and run them continuously. - Double the number of developers with aggressive recruiting This can become a slippery slope real fast. - Devs can only belong to 5 projects at most I can see this having its uses, but this is more of a personal thing on a per-dev basis. - Drop all arches and Gentoo/Alt projects except Linux on amd64, ppc32/64, sparc, and x86 Uh, no? Although we sometimes seem as inactive as hell, mips is very much an alive arch. We're a tad guilty of going off and doing our own thing sometimes, but then again, most of us are guilty of that at some point in our devship. I would instead opt for more interaction among archs, probably through dev sharing and such. sparc and mips share several developers (or did, I think I'm one of the few left), and encouraging more publicity for the lesser archs. I occasionally post an announcement about some neat new whizbang thing I do (like the X LiveCD for SGI systems I might post about tomorrow), and though I rarely see a response, I feel it gets the word out. - Reduce the number of projects by eliminating the dead, weak, understaffed, and unnecessary projects Depends on the definition of unnecessary. - Project status reports once a month for every project Hmm, could be useful. Depends on whether one defines a report as needing to match some obscure DoD specification, or whether a simple paragraph or two works fine. --Kumba -- Gentoo/MIPS Team Lead Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere. --Elrond -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On 2006.10.04 15:27, Chris Gianelloni wrote: [snip] I'll give you Release Engineering's status reports for September, October, and November: September: taking a well-deserved break October: taking a well-deserved break November: taking a well-deserved break How about other projects that rely on things like upstream's release cycle? What about projects that just maintain ebuilds? Here's the games team's status reports for every month: Fixed more bugs, added more packages, cleaned up some ebuilds. Now, perhaps what everyone would like, instead, would be status reports *where necessary* from certain projects? In fact, the council has been discussing asking a few projects about the status on some of their tasks. The main reason for this is for communications purposes. Basically, we'd just get a Hey, where are you at on $x? response from the teams. I don't *want* to drown projects in bureaucracy and paperwork. I want them to *accomplish* things, instead. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation Before you can have useful reports, you need a plan to report against. Like a target date for 2007.0 and its contents. Such a plan depends on other projects delivering the contents in accordance with their own plans. Like real life, these plans will have external dependencies on $UPSTREAM, that Gentoo has little or no control over. With progress reports against plans and updated plans, everyone can see whats happened, why some things haven't and what the fallback is, if one is required. The old saw, If you don't have a plan, then plan to fail remains true for volunteer projects as well as funded ones. The content and update rate of plans/reports can vary from project to project and it need not be onerous. Reporting can even be by exception, so to take your well-deserved break example, if it was in your plan, no report would be needed. Regards, Roy Bamford (NeddySeagoon) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Saturday 07 October 2006 01:26, Chris Gianelloni wrote: I'll be honest, Release Engineering work is *very* stressful. My primary goal as the lead is to try to come up with ways to make working on a release easier for the guys doing the work. If anyone had still any doubt about this, he can easily try to tweak a release :P I've been doing releng-like work lately to build Gentoo/FreeBSD stages with catalyst and I have to say that releng is doing a heck of an hard job to produce the releases, and my requirements are waaay more open than their own (as Gentoo/FreeBSD is still highly experimental)... -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpykeVGxjfmR.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On 10/7/06, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: If anyone had still any doubt about this, he can easily try to tweak a release :P I've been doing releng-like work lately to build Gentoo/FreeBSD stages with catalyst and I have to say that releng is doing a heck of an hard job to produce the releases, and my requirements are waaay more open than their own (as Gentoo/FreeBSD is still highly experimental)... And if anyone's still not convinced, try remembering what it was like before Chris started getting releng into some semblence of shape. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Thu, 2006-10-05 at 00:00 +0100, Duncan Coutts wrote: On Wed, 2006-10-04 at 17:13 -0400, Chris Gianelloni wrote: With the increase in developer and project overlays, I see the possibility for reducing work needed to maintain many packages. As Natanael Copa, it would be nice for him to be able to maintain packages without having CVS access. The idea of formalizing and promoting proxy developers has come up a few times before, and I think it is a great idea. Work is done in the overlays, tested, improved, then committed into the main tree once the kinks have been worked out. We get a stronger core tree with fewer developers and a better interaction with the community. Some projects/herds already work this way with good results. We regularly get contributions from users that go into our overlay, get tested by us and other users and then get into the main portage tree some time later. We have a very low barrier to entry, it's just darcs record; darcs send. Then one of the devs reviews and applies/rejects the patch. Easy. If the proxy maintainer is specified as contact person in the ebuild, and will be added to the CC list on bugs posted, the official developer will not need to care about it until he gets a response from the proxy developer. For some of our ebuilds we already have de-facto proxy developers. If it would be possible to become a proxy developer, I'd be maintainer for several packages. Its not the first time I'm offering that: https://bugs.gentoo.org/show_bug.cgi?id=76213#c2 Nobody has ever showed interest and I'm not pushing my services on anyone. But I'd like to do official portage and not any overlay. I have submitted ebuilds to bugzilla that ended up in an overlay somehwere (bug got closed) and has dissapeared for ever. I can't post bugs about overlays in bugzilla, (I suppose) so no updated ebuild have been submitted and I ended up just running my own local overlay. -- Natanael Copa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Natanael Copa wrote: Nobody has ever showed interest and I'm not pushing my services on anyone. Why exactly you don't want to become a Gentoo dev? The whole proxy maintainer thing is a bunch of crap. The Gentoo developer will still be expected to be responsible of his/her commits, which means 2 maintainers will spend (approximately) same amount of time testing it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide (Proxy-dev)
Chris Gianelloni wrote: On Wed, 2006-10-04 at 13:20 -0400, Caleb Tennis wrote: With the increase in developer and project overlays, I see the possibility for reducing work needed to maintain many packages. As Natanael Copa, it would be nice for him to be able to maintain packages without having CVS access. The idea of formalizing and promoting proxy developers has come up a few times before, and I think it is a great idea. Work is done in the overlays, tested, improved, then committed into the main tree once the kinks have been worked out. We get a stronger core tree with fewer developers and a better interaction with the community. http://article.gmane.org/gmane.linux.gentoo.devel/40744 I am still willing to cooperate with this project idea if there exist enough interest in our users and devels base. -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 11:44:07 -0400 Thomas Cort [EMAIL PROTECTED] wrote: On 10/4/06, Kevin F. Quinn [EMAIL PROTECTED] wrote: On Wed, 04 Oct 2006 09:41:45 -0400 Alec Warner [EMAIL PROTECTED] wrote: My view is that while they're being actively supported, there's no reason to remove them. Granted their mostly SpanKY's babies, but so what? My view is that currently we cannot offer the same level of support for the minority arches as the majority arches because we don't have enough people involved. We don't need to. Gentoo isn't just one single thing, and I see no reason to require that all projects and arches offer the same level of support. Each project and arch can make their own determination about what level of support they can and will offer. Embedded users, for example, are generally more technically-oriented to start with so need far less support than, say, non-technical x86 users. I think that spreading the developers too thin leads to conflict and burnout. Look at NetBSD and debian. They are trying to be everything for everyone. How is that working for them, how is it working for us? I think we should be more focused, but that's just my opinion. Minority arches don't affect devs who aren't interested in them, so they have no impact on how spread out the developers are. Effectively you're saying that those involved in the minority arches should stop messing about with that and commit all their Gentoo time to mainline activities, which is obviously not sensible. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 11:44:07 -0400 Thomas Cort [EMAIL PROTECTED] wrote: On 10/4/06, Kevin F. Quinn [EMAIL PROTECTED] wrote: On Wed, 04 Oct 2006 09:41:45 -0400 Alec Warner [EMAIL PROTECTED] wrote: My view is that while they're being actively supported, there's no reason to remove them. Granted their mostly SpanKY's babies, but so what? My view is that currently we cannot offer the same level of support for the minority arches as the majority arches because we don't have enough people involved. We don't need to. Gentoo isn't just one single thing, and I see no reason to require that all projects and arches offer the same level of support. Each project and arch can make their own determination about what level of support they can and will offer. Embedded users, for example, are generally more technically-oriented to start with so need far less support than, say, non-technical x86 users. I think that spreading the developers too thin leads to conflict and burnout. Look at NetBSD and debian. They are trying to be everything for everyone. How is that working for them, how is it working for us? I think we should be more focused, but that's just my opinion. Minority arches don't affect devs who aren't interested in them, so they have no impact on how spread out the developers are. Effectively you're saying that those involved in the minority arches should stop messing about with that and commit all their Gentoo time to mainline activities, which is obviously not sensible. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 11:39:07 -0400 Thomas Cort [EMAIL PROTECTED] wrote: On 10/4/06, Kevin F. Quinn [EMAIL PROTECTED] wrote: On Wed, 4 Oct 2006 09:21:08 -0400 Thomas Cort [EMAIL PROTECTED] wrote: The minority arches like mips, sparc etc seem to get along quite happily. Not the minority arches like m68k, s390, alpha, ... I haven't seen any significant numbers of complaints. What exactly about those arches do you think is a problem? The speed at which bugs are resolved is the problem. Keywording/stable bugs can sit for months and sometimes over a year without being touched. So? Who is complaining? Open stabilisation bugs are a concern for the relevant arches, not for everyone. Once an arch has actioned a stabilisation bug, they remove themselves from CC, after which they don't care. Some people think the amount of time some arches lag behind is acceptable, I don't. The primary reason why arches lag is that we don't have enough people doing the testing and keywording. You should only raise expectations when you know you can follow through, not the other way around. Raising expectations before being able to follow through leads to disappointment, which is bad. I think that if we implement my suggestions (drastically reducing the workload), we will be able to meet those expectations. All that will happen if you ditch the minority arches, is that the devs involved will take their work into overlay or possibly leave Gentoo altogether. It won't improve anything for other arches. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Thu, 5 Oct 2006 12:52:14 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | Minority arches don't affect devs who aren't interested in them Actually, they do. Minority archs lead to much better tree QA being done, more bugs in packages being identified and more ebuild and package bugs being fixed. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Thursday 05 October 2006 13:48, Ciaran McCreesh wrote: Actually, they do. Minority archs lead to much better tree QA being done, more bugs in packages being identified and more ebuild and package bugs being fixed. Hell is gonna break loose, I agree with Ciaran! -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgp4ozz5ydi6I.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Diego 'Flameeyes' Pettenò wrote: On Thursday 05 October 2006 13:48, Ciaran McCreesh wrote: Actually, they do. Minority archs lead to much better tree QA being done, more bugs in packages being identified and more ebuild and package bugs being fixed. Hell is gonna break loose, I agree with Ciaran! Not today, not today, 1/2 of the devils are on a strike because of the recent freezes in the latest months, the others are still recovering from the flu caused by the change in the climate... lu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Thursday 05 October 2006 14:04, Luca Barbato wrote: Not today, not today, 1/2 of the devils are on a strike because of the recent freezes in the latest months, the others are still recovering from the flu caused by the change in the climate... What if I call as a reinforcement the BSD daemons I have here around? -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpYo0lbsdb4k.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Thu, 2006-10-05 at 09:52 +0300, Alin Nastac wrote: Natanael Copa wrote: Nobody has ever showed interest and I'm not pushing my services on anyone. Why exactly you don't want to become a Gentoo dev? The whole proxy maintainer thing is a bunch of crap. The Gentoo developer will still be expected to be responsible of his/her commits, which means 2 maintainers will spend (approximately) same amount of time testing it. It does mean you can sometimes offload work onto other people, eg upstream maintainers - who are themselves not interested in becoming devs but are more than happy to maintain their single ebuild. And it does actually mean less work for us because although we still have to test it, we can rely to some extent on the testing done by that maintainer and by other users who regularly build from our overlay. Also it means we don't have to look out for upstream releases because they 'darcs send' in their updates and we just take responsibility for QA and getting things into portage cvs. -- Duncan Coutts : Gentoo Developer (Haskell team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Diego 'Flameeyes' Pettenò wrote: On Thursday 05 October 2006 14:04, Luca Barbato wrote: Not today, not today, 1/2 of the devils are on a strike because of the recent freezes in the latest months, the others are still recovering from the flu caused by the change in the climate... What if I call as a reinforcement the BSD daemons I have here around? They got all taken for the next pokemon film, seems that the new logo rang a bell to the producers... lu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Thu, 2006-10-05 at 12:48 +0100, Ciaran McCreesh wrote: On Thu, 5 Oct 2006 12:52:14 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | Minority arches don't affect devs who aren't interested in them Actually, they do. Minority archs lead to much better tree QA being done, more bugs in packages being identified and more ebuild and package bugs being fixed. You see this is the problem with being perceived as a minority architecture. And it's something that gets completely overlooked -- before we had a QA team, the minority architectures served a similar purpose. Countless packages have had build-system fixes, compile fixes, runtime fixes all *because* we had ppc, sparc, mips and others (ppc and sparc being the more major of them, in terms of long-term impact to Gentoo). IOW, +1 on Ciaran's statement. I think it's perfectly fine to think about pruning/thinning out Gentoo to its core, but first we have to actually decide what its core actually is. Hint: majority architectures are *not*. Gentoo, at heart, is a meta-distribution, and all that that implies. Thanks, -- Seemant Kulleen Developer, Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 2006-10-04 at 22:00 -0400, Mike Kelly wrote: I don't *want* to drown projects in bureaucracy and paperwork. I want them to *accomplish* things, instead. Sending a brief All's well with releng email isn't exactly what I would call drowning in bureaucracy. Of course not, but that's where it starts. Forcing projects to really do anything on a regular set schedule that isn't internally set is bureaucracy and pointless. I don't *want* to have to spend my time thinking about which projects I'm supposed to be sending status reports on that haven't done anything. I'd *much* rather spend my time actually *developing* on the projects that *are* currently moving. This is my *entire* point. Forcing a project to send in worthless little we're still here messages doesn't do anything. Of *course* they're still there. They have a project page. They have members. They're doing commits. Rather than wasting time trying to get everybody out giving each other warm fuzzies, I'd prefer we focus on the areas where we truly need to improve communications. A couple good examples of projects/teams that affect everyone are infrastructure and the trustees. These are two good places for status reports. Things like the games team are not. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Thu, 2006-10-05 at 09:52 +0300, Alin Nastac wrote: Natanael Copa wrote: Nobody has ever showed interest and I'm not pushing my services on anyone. Why exactly you don't want to become a Gentoo dev? The whole proxy maintainer thing is a bunch of crap. The Gentoo developer will still be expected to be responsible of his/her commits, which means 2 maintainers will spend (approximately) same amount of time testing it. Maybe he doesn't want to deal with the politics? Maybe he doesn't want to deal with the flame wars? Maybe, he just wants his package in the tree and hopes to find a developer who thinks the same? Personally, I proxy maintain 3 packages. I don't actively *use* these packages. In this case, I'm mostly just a commit monkey though I do check the packages for things similarly to what is done by Arch Testers. Now, I wouldn't take on a very large number of such packages, simply due to my own time constraints. In this case, I proxy maintain for a former Gentoo ebuild developer, so I have a strong level of trust that he knows what he's doing. Even then, I still give them a once-over. It is so little effort on my part to maintain the packages that, if I so chose, I could probably proxy 100 of these. The brunt of the work, such as keeping up with upstream, writing patches, etc. are done by the person whom I proxy for, and not by me. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Thu, 2006-10-05 at 08:34 +0200, Natanael Copa wrote: If the proxy maintainer is specified as contact person in the ebuild, and will be added to the CC list on bugs posted, the official developer will not need to care about it until he gets a response from the proxy developer. Well, look at sys-auth/bioapi. The ebuild is written (and maintained) by an ex-developer, SeJo. He sends me the updates, and I commit them. About the only thing that I do is run them through repoman and check that they're not doing fun things like rm -rf / in pkg_preinst. ;] Of course, they're super-new, so there's no bugs, but once a bug gets filed on it, I'll be sure that SeJo is added to CC, if he isn't added by the bug wrangler. At that point, I'll expect him to fix it. In the end, *I* am ultimately responsible for the package, since I am the developer that maintains it, but the workload on me is minimal, at most. But I'd like to do official portage and not any overlay. I have submitted ebuilds to bugzilla that ended up in an overlay somehwere (bug got closed) and has dissapeared for ever. I can't post bugs about overlays in bugzilla, (I suppose) so no updated ebuild have been submitted and I ended up just running my own local overlay. If your package was added to an overlay and the bug was closed, it was closed in error. Bug reports (unless they pertain to an overlay itself) don't get closed until the bug is FIXED in the main tree. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On 2006.10.04 13:15, Brandon Low wrote: As usual, sweeping new policies or procedures WILL NOT FIX THINGS. [snip] --Brandon Since I have been a Gentoo user, there have been two completely different management styles in use. When drobbins was around, he was like the MD and Gentoo was managed as if it were a single project. Since that time, Gentoo has grown into a loose knit collection of smaller projects all doing their own thing. Higher level collaboration must be happening because releng relay on all the bits coming together but its not much in evidence. There are two options for Gentoo. We can add some reporting and control to make Gentoo appear as a single cohesive project, the price for that is some bureaucracy. Or we can continue management by tribal warfare, as is evidenced by the flame fests on this list. Both take about the same amount of effort from the participants. What we lack to manage Gentoo as a single project is a proactive management body. Regards, Roy Bamford (NeddySeagoon) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wednesday 04 October 2006 13:00, Thomas Cort wrote: - Drop all arches and Gentoo/Alt projects except Linux on amd64, ppc32/64, sparc, and x86 I would say to drop everything bug sparc and ppc64, that seems to be the only arch teams that actually respond in a timely fashion to keywording requests. Sounds crazy, but both amd64 and x86 are bottlenecks here... I don't even want to comment on your mail, I looked at the calendar to see if it was April 1st already, maybe I ended up in a timedrift. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpqnrLjH7OI4.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Thomas Cort wrote: There have been a number of developers leaving Gentoo in the past 6 months as well as a number of news stories on DistroWatch, Slashdot, LWN, and others about Gentoo's internal problems. No one seems to have pin pointed the problem, but it seems glaringly obvious to me. We simply don't have enough developers to support the many projects that we have. Here are my ideas for fixing this problem: - Cut the number of packages in half (put the removed ebuilds in community run overlays) No, thank you. We are already decimating packages in certain areas but isn't a good solution. - Formal approval process (or at least strict criteria) for adding new packages let the herds decide... - Make every dev a member of at least 1 arch team Ok - Double the number of developers with aggressive recruiting NO! I want to know people I'm working with. Double the people doing recruiting and evaluation! (I have at least one guy in wait phase) - No competing projects No projects that don't coordinate between them. - New projects must have 5 devs, a formal plan, and be approved by the council some projects starts by one and then grow... - Devs can only belong to 5 projects at most No. - Drop all arches and Gentoo/Alt projects except Linux on amd64, ppc32/64, sparc, and x86 No. - Reduce the number of projects by eliminating the dead, weak, understaffed, and unnecessary projects too much subjective so, No. - Project status reports once a month for every project bureocracy In short, interesting ideas, I don't like more than half of them. what about: let treecleaners do their job, recruiters get more people, put the devmanual where it belongs, have better coordination between projects to the point stepping on others feet is quite hard and not dead easy as today? those point and less noise on gentoo-dev. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wednesday, 04. October. 2006 13:00, Thomas Cort wrote: There have been a number of developers leaving Gentoo in the past 6 months as well as a number of news stories on DistroWatch, Slashdot, LWN, and others about Gentoo's internal problems. No one seems to have pin pointed the problem, but it seems glaringly obvious to me. We simply don't have enough developers to support the many projects that we have. Here are my ideas for fixing this problem: - Cut the number of packages in half (put the removed ebuilds in community run overlays) We (treecleaner, poke Alec about that) are currently working on something alike. A user / Alec suggested putting removed packages into a seperate overlay, so the ebuilds would be still accessible (without using sources.gentoo.org and putting it into a local overlay). - Formal approval process (or at least strict criteria) for adding new packages - Make every dev a member of at least 1 arch team I think that would solve the understaffing of some of the arch teams (iirc amd64 and x86 are having enough devs / at's right now) - Double the number of developers with aggressive recruiting Before you do that, you'll have to double the number of recruiters. Otherwise you're creating a pretty bottleneck. - No competing projects - New projects must have 5 devs, a formal plan, and be approved by the council - Devs can only belong to 5 projects at most Reducing the stress on people ? No clue what that would solve. - Drop all arches and Gentoo/Alt projects except Linux on amd64, ppc32/64, sparc, and x86 I guess at least Diego and Fabian are going to yell at you right now. - Reduce the number of projects by eliminating the dead, weak, understaffed, and unnecessary projects - Project status reports once a month for every project That would be great, but to whom should they report ? The council ? Or via -core ? -- Christian Heim phreak at gentoo.org GPG key ID: 9A9F68E6 Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6 Your friendly treecleaner/mobile/kernel/vserver/openvz monkey -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 07:00:14 -0400 Thomas Cort [EMAIL PROTECTED] wrote: | - Double the number of developers with aggressive recruiting Aggressive recruiting isn't going to find you more competent people. All it's going to do is increase the moron quotient from its current 50% to 75%. | - Reduce the number of projects by eliminating the dead, weak, | understaffed, and unnecessary projects So just how *do* you plan to replace Portage, which is definitely weak, definitely understaffed, probably getting close to dead and entirely not unnecessary? | - Project status reports once a month for every project Who's going to read them and follow up on it? All this will do is create more noise. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Thomas Cort wrote: There have been a number of developers leaving Gentoo in the past 6 months as well as a number of news stories on DistroWatch, Slashdot, LWN, and others about Gentoo's internal problems. People come and go, I still see Gentoo going forward, packages still get updated, work gets done... So I'm really beginning to think people read t much into a few people leaving over 6 months and a few, generally wrong articles based on misinterpreting someones blog... simply don't have enough developers to support the many projects that we have. Here are my ideas for fixing this problem: Maybe, maybe not... Projects exist, so there is at least _someone_ that's interested in them... If that's not true, then ok, just remove that project... Let's start the comments on the 10 points (all imho): - Cut the number of packages in half (put the removed ebuilds in community run overlays) Who decides what goes away and what now? Which criteria is used here? Btw, this is already being done splendidly by the TreeCleaners project, and Sunrise and other overlays are already absorbing stuff from the community. - Formal approval process (or at least strict criteria) for adding new packages Err what? So I, as a dev, that did quizzes, etc., cannot even anymore just add the package that has got my fancy atm, because there are some criteria to what is added and what not, and I have to go through a bureaucratic process just for that? Never! If for strict criteria you mean there must be at least a dev or herd maintaining it, or such stuff, they already exist, they may just need some more enforcing... ;) - Make every dev a member of at least 1 arch team Which doesn't mean he will ever keyword stuff stable, other than his own, which he already can... Let's face it: most devs are mainly interested in their stuff, getting their stuff keyworded, and many wouldn't anyway have the time to efficiently work on an arch-team, as members of such I mean, not just as I'm a member, so I keyword my stuff, that's it... For that I agree with the current practice: if you want that, ask the arch-team first. ;) - Double the number of developers with aggressive recruiting That's something that goes on since... forever! Gentoo's continuously recruiting new people, more aggressive recruiting has already been proposed many times, but it was always agreed to try to maintain a relatively high standard of new recruits, and if you want quality, finding loads of people who just happen to have the time and dedication to become a Gentoo dev isn't that easy. - No competing projects Kills innovation... Who comes first has total monopoly of that branch of things basically... I'd never agree to something like this, personally. - New projects must have 5 devs, a formal plan, and be approved by the council New projects do always have a plan, they wouldn't be created else... ;) Making it formal, be approved by the council... How to slow everything down? We continuously see how adding bureaucratic stuff just suffocates innovation, I totally agree with discussion et all, but not really on the need to have everything approved by someone (the council in this case)... The council may kill the project later on if it's doing totally crazy shit, but that's another thing entirely... - Devs can only belong to 5 projects at most Why? If someone has time to dedicate and work on a lot of projects, why not? - Drop all arches and Gentoo/Alt projects except Linux on amd64, ppc32/64, sparc, and x86 Uhhh is this real? How would this help at all? Hell, it would make things worse to an extent, we've already seen that at least Gentoo/BSD helped in finding problems in ebuilds using too GNUish stuff, other arches may help in finding broken code, etc.. I'd agree with some proposal to relax keywording policy for all arches you've not listed, since on those others, sadly, not soo many people are active, and you get to wait on keywords for months sometimes... This is something we should imo address from an arch-team PoV, some kind of if they don't react in time, I can drop their keyword back to unstable or entirely, or something like that, that would help many package maintainers I think. - Reduce the number of projects by eliminating the dead, weak, understaffed, and unnecessary projects Again, who's the judge of that? If there is a project with at least one person active, it means for him it's not unnecessary... What means weak project? What's unnecessary? Sure, kill the dead ones with no activity and no active members, that's easy and I agree with that, but the other, little ones, who's the one to say you're understaffed and useless, go die!? :S - Project status reports once a month for every project Totally agree on this one! -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description:
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Christian Heim wrote: - Make every dev a member of at least 1 arch team I think that would solve the understaffing of some of the arch teams (iirc amd64 and x86 are having enough devs / at's right now) No. We don't need more people on our dev lists, because it won't change anything. What we need is more people who do actual testing. If you're forced to be in an arch team you're just a dev tag in a project page, not more. This is not going to help at all, in fact it will only hide the problems even more. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
As usual, sweeping new policies or procedures WILL NOT FIX THINGS. Pretty much every commercial enterprize learns this eventually. New rules from above don't fix problems, peolpe fix problems from below. Gentoo has always been about close cooperation between core devs, new devs and non devs. I think the best thing that can possibly be done is to help to foster that kind of connection again. The bigget problem that I see facing that effort is that #gentoo is no longer a manageable place for devs to talk to users. Remember when every developer could be found in there? Remember when #gentoo was _the_ place for gentoo related discussions, and new ideas could be implemented and handed to the very users who would be impacted by the changes right in #gentoo? Remember when committing a big bug into the tree just wasn't that big of a deal, because it'd get fixed soon, and the people who updated often enough to care in the meantime would just laugh about it with you in #gentoo? What if the problem is too many devs instead of too few? Slackware Linux is a comparatively simple to maintain distribution, but ONE person does it. How many devs are on Gentoo now? 200? more? A close knit group of college students and bored professionals should be able to maintain this distribution. The biggest point that I do agree with from the original email is that projects like stage 4s, the installer and pretty much anything other than the portage program, the portage tree and the stage[123] live CDs should not be officially part of the Gentoo project. That's not Gentoo. Gentoo was started as a meta-distribution for good reason and it's good at that, keep it that way. If people want to wrap an installer and stage 4s around that meta distribution, more power to them -- they should name their distro and credit Gentoo, but that is _not_ Gentoo. The great thing about being a meta distribution and not a full pretty-installer binary distribution is that some of the quirky one-off package incompatibilities become not really Gentoo's problem. They are now the person who wants to distribute a binary distro that contains that particular weird set of packages problem. Hopefully they fix it and submit a patch upstream to Gentoo, and maybe they request a portage feature (cuz there aren't enough already) to improve it. Rant! Meh, I'm part of the problem, so I should shut up now. --Brandon On 2006-10-04 (Wed) at 13:44:01 +0200, Simon Stelling wrote: Christian Heim wrote: - Make every dev a member of at least 1 arch team I think that would solve the understaffing of some of the arch teams (iirc amd64 and x86 are having enough devs / at's right now) No. We don't need more people on our dev lists, because it won't change anything. What we need is more people who do actual testing. If you're forced to be in an arch team you're just a dev tag in a project page, not more. This is not going to help at all, in fact it will only hide the problems even more. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Thomas Cort wrote: - Cut the number of packages in half (put the removed ebuilds in community run overlays) Removing part of the market will make us weaker, not stronger. - Formal approval process (or at least strict criteria) for adding new packages Though I doubt bureaucracy will help, adding some strict criteria doesn't seem a bad idea. - Make every dev a member of at least 1 arch team That's a sound idea, that way some herds (see KDE) won't have to be searching for testers in every arch because _strangely_ one of the most daily used desktop environments doesn't have many users among the testers. - Double the number of developers with aggressive recruiting Do you plan on sacrificing quality? - No competing projects If the projects are small, that shouldn't be an issue. (i.e. does not imply much effort) - New projects must have 5 devs, a formal plan, and be approved by the council What are the reasons for a minimum of 5 developers? Any argument for that? What do you understand for 'formal plan'? - Devs can only belong to 5 projects at most What if the projects are small enough? How about belonging to the infrastructure project for instance, does it count? - Drop all arches and Gentoo/Alt projects except Linux on amd64, ppc32/64, sparc, and x86 Again, reducing the market isn't the way IMHO. - Reduce the number of projects by eliminating the dead, weak, understaffed, and unnecessary projects Please define 'unnecessary projects'. - Project status reports once a month for every project I agree with this one. A monthly report might bring some order and light :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On 10/4/06, Christian Heim [EMAIL PROTECTED] wrote: On Wednesday, 04. October. 2006 13:00, Thomas Cort wrote: - Devs can only belong to 5 projects at most Reducing the stress on people ? No clue what that would solve. There are developers who belong to many projects and do very little or no work for some. This would make them more focused and active on each project. A team with 5 really active members is a lot nicer than one with 30 people who aren't active. - Project status reports once a month for every project That would be great, but to whom should they report ? The council ? Or via -core ? They would report to the community in general by posting status reports on their project pages. -Tom PS Sorry for not using my @gentoo.org e-mail address. I don't have access to my Gentoo e-mail where I am right now. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On 10/4/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 4 Oct 2006 07:00:14 -0400 Thomas Cort [EMAIL PROTECTED] wrote: | - Double the number of developers with aggressive recruiting Aggressive recruiting isn't going to find you more competent people. All it's going to do is increase the moron quotient from its current 50% to 75%. There are plenty of competent people out there. We just aren't getting them. | - Reduce the number of projects by eliminating the dead, weak, | understaffed, and unnecessary projects So just how *do* you plan to replace Portage, which is definitely weak, definitely understaffed, probably getting close to dead and entirely not unnecessary? I think you know the answer to that question ;) | - Project status reports once a month for every project Who's going to read them and follow up on it? All this will do is create more noise. People in the community who are wondering what is going on are going to read them. Userrel/pr would follow up. -Tom -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Hi, everyone. I'm not gentoo dev (yet), but I take the chance to vent an idea I have a while, based on my personal experience in bugzilla. On Wed, 2006-10-04 at 07:15 -0500, Brandon Low wrote: What if the problem is too many devs instead of too few? Slackware Linux is a comparatively simple to maintain distribution, but ONE person does it. How many devs are on Gentoo now? 200? more? A close knit group of college students and bored professionals should be able to maintain this distribution. I think the challenge is the amount of packages. One person could not maintain all packages in gentoo. What you didn't need to be a gentoo dev to be a package maintainer? Lets say anyone could be marked as maintainer in an ebuild. When there is a bug, the package maintainer fixes the bug and submits an updated ebuild/patch whatever. This person has no commit access. Then a committer, a gentoo-dev (someone with little more experience), just take a quick look at it and commit it. This way fewer dev with commit access is needed, and more people from community are able to offload the dev's. This would also make the threshold lower for people to become a maintainer. Personally there are a few packages I could maintain, but I don't think its worth becomming a developer to just maintain 1 single package. I think this how the do with the freebsd ports tree. I am maintainer for 1 single freebsd port without being a committer. -- Natanael Copa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On 10/4/06, Luca Longinotti [EMAIL PROTECTED] wrote: People come and go, I still see Gentoo going forward, packages still get updated, work gets done The number of opened bugs has always been higher than the number of closed bugs in the bug stats listed in every 2006 GWN. How is this 'going forward'? It seems to me like we are falling behind. - Cut the number of packages in half (put the removed ebuilds in community run overlays) Who decides what goes away and what now? Which criteria is used here? Duplicate packages (we don't need more than a few mp3 players), unpopular packages with only a few users, unmaintained packages, and broken packages. We would provide a set of packages for most things a user would want to do and then sunrise/someone else provides ebuilds for the rest. I was thinking something similar to what Ubuntu does, they provide the basics to do most things and then they have universe and multiverse repos for extra stuff. - Formal approval process (or at least strict criteria) for adding new packages Err what? So I, as a dev, that did quizzes, etc., cannot even anymore just add the package that has got my fancy atm, because there are some criteria to what is added and what not, and I have to go through a bureaucratic process just for that? Never! If for strict criteria you mean there must be at least a dev or herd maintaining it, or such stuff, they already exist, they may just need some more enforcing... ;) I believe that we have too many packages for us to maintain. We have over 11,000 packages (over 24,000 ebuilds) and only about 175 active developers. I don't think its maintainable and I don't think adding more packages will make it any better. - Make every dev a member of at least 1 arch team Which doesn't mean he will ever keyword stuff stable, other than his own, which he already can... Let's face it: most devs are mainly interested in their stuff, getting their stuff keyworded, and many wouldn't anyway have the time to efficiently work on an arch-team, as members of such I mean, not just as I'm a member, so I keyword my stuff, that's it... For that I agree with the current practice: if you want that, ask the arch-team first. ;) Every developer should have access to at least 1 Gentoo system. They should also be able to determine if something is stable or not. It would cut down on the number of keyword/stable bugs if developers did a lot of their own keywording. - Double the number of developers with aggressive recruiting That's something that goes on since... forever! Gentoo's continuously recruiting new people, more aggressive recruiting has already been proposed many times, but it was always agreed to try to maintain a relatively high standard of new recruits, and if you want quality, finding loads of people who just happen to have the time and dedication to become a Gentoo dev isn't that easy. Even when someone is found it is hard for them to find mentors. We need to improve this. I had found someone who wanted to join the sound team and I was unable to locate a mentor for him (I wasn't a dev for 6 months then, so I couldn't do it myself). I e-mailed [EMAIL PROTECTED] and only one person offered. The person who offered fell through because he didn't have enough free time. - No competing projects Kills innovation... Who comes first has total monopoly of that branch of things basically... I'd never agree to something like this, personally. What happened to working together? Should we work together instead of competing against each other? - Drop all arches and Gentoo/Alt projects except Linux on amd64, ppc32/64, sparc, and x86 Uhhh is this real? How would this help at all? We've got tons of keywording/stable bugs. There aren't enough developers to do all the proper testing on all of the architectures supported by Gentoo. Many of the arches are dead or soon to be dead (m68k, alpha, mips, etc). - Reduce the number of projects by eliminating the dead, weak, understaffed, and unnecessary projects Again, who's the judge of that? If there is a project with at least one person active, it means for him it's not unnecessary... What means weak project? What's unnecessary? Sure, kill the dead ones with no activity and no active members, that's easy and I agree with that, but the other, little ones, who's the one to say you're understaffed and useless, go die!? :S We come up with a list of potential cuts and then the council decides -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On 10/4/06, Brandon Low [EMAIL PROTECTED] wrote: What if the problem is too many devs instead of too few? Slackware Linux is a comparatively simple to maintain distribution, but ONE person does it. How many devs are on Gentoo now? 200? more? A close knit group of college students and bored professionals should be able to maintain this distribution. Slackware != Gentoo On Gentoo we have to provide support for each possible combination of USE flags, CFLAGS, and compiler versions on 32-bit and 64-bit systems, on little endian and big endian systems, and with mix of stable and testing packages. Slackware just has to get things to compile and work once. -Tom -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 15:02:17 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | Yuck. Devs should be free to add whatever packages they like, | provided they're willing to maintain them. There're already some restrictions: http://devmanual.gentoo.org/general-concepts/tree/index.html#what-belongs-in-the-tree? Perhaps they should be enforced... -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
The minority arches like mips, sparc etc seem to get along quite happily. Not the minority arches like m68k, s390, alpha, ... - Reduce the number of projects by eliminating the dead, weak, understaffed, and unnecessary projects Weak: Be more specific. What are the weak projects, and why? Projects that don't achieve anything, have no goals, and don't show any promise of doing anything productive. Understaffed: this issue manifests itself as a project being slow to update. However the only place this is an issue is for security issue management. Another solution to under-staffing is to reduce expectations. The more we reduce expectations, the more it will hurt users. We should be raising expectations and following through. Unnecessary: again, be more specific. What are the unnecessary projects, and why? Projects that aren't needed to further Gentoo and are not helpful to users or developers. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Okay, I didn't want to answer anymore to this thread because I really find it suited for April 1st, not October 4th, but seems like I cannot... On Wednesday 04 October 2006 15:10, Thomas Cort wrote: I was thinking something similar to what Ubuntu does, they provide the basics to do most things and then they have universe and multiverse repos for extra stuff. And one of the main thing that new users like of Gentoo when compared to Debian, Ubuntu and Fedora is that you have almost everything available out of the box. Not counting that a good deal of the packages in the tree does not really require much maintainership. I believe that we have too many packages for us to maintain. We have over 11,000 packages (over 24,000 ebuilds) and only about 175 active developers. I don't think its maintainable and I don't think adding more packages will make it any better. Let's see, about 400 packages are handled by KDE herd. Not sure how many are currently handled by X11 herd after modular Xorg was addded, at least 20 packages are handled by BSD herd, and I think I maintain directly about 40 packages; we have about 30 kernel sources packages, and a uncounted number of minor or micro packages. I think my stuff is pretty well maintained, too. The problem is not the quantity, the problem is the coverage. Every developer should have access to at least 1 Gentoo system. They should also be able to determine if something is stable or not. It would cut down on the number of keyword/stable bugs if developers did a lot of their own keywording. Cut the crap, if you allow me. I have four systems: AMD64, PowerPC and two i386 (FreeBSD) boxes. I run ~amd64 and ~ppc, I cannot stable anything for those two, and I don't want to waste time in a stable overlay. I've resigned from AMD64 team for that reason, too. Even when someone is found it is hard for them to find mentors. We need to improve this. Well, happens to me that I always found enough mentors to do the job.. even if it required to wait some weeks. What happened to working together? Should we work together instead of competing against each other? Competing does not mean try to kill the other, means try to do a similar thing in a different way, that is something that we are already doing by being a (mostly) Linux distribution... Why don't you go help Ubuntu, if you think that competing is bad? We've got tons of keywording/stable bugs. There aren't enough developers to do all the proper testing on all of the architectures supported by Gentoo. Many of the arches are dead or soon to be dead (m68k, alpha, mips, etc). Yeah and as others said, x86 and AMD64 are way more of a bottleneck than Alpha, Sparc or PPC64 . I've asked two days ago a re-keywording of libao and libao-pulse. ~amd64 and ~x86-fbsd keywords are mine; the only keyword added after those was ~ppc64 up to now. If I look through the PulseAudio packages, x86 is missing everywhere, even if users asked for keywording. Sure, killing Gentoo/FreeBSD will improve x86 support, yeah sure, keep on tryin'. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpVGSalhEpcQ.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wednesday 04 October 2006 15:14, Thomas Cort wrote: On Gentoo we have to provide support for each possible combination of USE flags, CFLAGS, and compiler versions on 32-bit and 64-bit systems, on little endian and big endian systems, and with mix of stable and testing packages. Slackware just has to get things to compile and work once. No. You don't support each possible combination of CFLAGS, nor of compiler versions. Arch teams takes care of arch differences. Sorry, but I think I cope well enough on xine-lib (which is a kinda strange package with many arch differences), and I don't really spend much time on the ebuild (or Gentoo maintenance) anymore for it, after cleaning it up one time. It required time but it was feasible, or I wouldn't be able to do it. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpOy2t2UTKy4.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Thomas Cort wrote: The number of opened bugs has always been higher than the number of closed bugs in the bug stats listed in every 2006 GWN. How is this 'going forward'? It seems to me like we are falling behind. Take a closer look at the statistics. The numbers seem drastic, but once you've seen the queries behind them you know how to interprete them and things don't look that bad anymore. - Make every dev a member of at least 1 arch team Which doesn't mean he will ever keyword stuff stable, other than his own, which he already can... Let's face it: most devs are mainly interested in their stuff, getting their stuff keyworded, and many wouldn't anyway have the time to efficiently work on an arch-team, as members of such I mean, not just as I'm a member, so I keyword my stuff, that's it... For that I agree with the current practice: if you want that, ask the arch-team first. ;) Every developer should have access to at least 1 Gentoo system. They should also be able to determine if something is stable or not. It would cut down on the number of keyword/stable bugs if developers did a lot of their own keywording. We had this model already, the x86 arch team did not always exist. We could revert to the old one, would be less bureaucratic. Would also take quite some load off the arch teams. Would also result in worse overall quality of the tree. *shrug* - Double the number of developers with aggressive recruiting That's something that goes on since... forever! Gentoo's continuously recruiting new people, more aggressive recruiting has already been proposed many times, but it was always agreed to try to maintain a relatively high standard of new recruits, and if you want quality, finding loads of people who just happen to have the time and dedication to become a Gentoo dev isn't that easy. Even when someone is found it is hard for them to find mentors. We need to improve this. I had found someone who wanted to join the sound team and I was unable to locate a mentor for him (I wasn't a dev for 6 months then, so I couldn't do it myself). I e-mailed [EMAIL PROTECTED] and only one person offered. The person who offered fell through because he didn't have enough free time. - No competing projects Kills innovation... Who comes first has total monopoly of that branch of things basically... I'd never agree to something like this, personally. What happened to working together? Should we work together instead of competing against each other? Sometimes you want to achieve the same goal by totally different means. Sometimes there are good reasons for a complete new start. It does not even mean you don't communicate anymore. Brian Harring, although working on pkgcore which basically competes portage, communicates a lot with the portage team and vice versa, in a very productive manner. Nevertheless, you won't find anybody on the portage or pkgcore team saying that it would have been better to incorporate the ideas of pkgcore into portage. Sometimes it's simply better to start all over again. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On 10/4/06, Alec Warner [EMAIL PROTECTED] wrote: - No competing projects do we have any competing projects now? I believe seeds competes with releng (since they both want to release stage tarballs). Some people don't believe that the two projects compete, but it isn't up for discussion in this thread. PR and User Relations used to do pretty much the same thing (interact with the public), but they have since merged. I haven't looked at the list of projects lately to identify any others. I mainly wrote No competing projects because there aren't any rules preventing competing projects. Since top level projects don't need discussion or formal approval from anyone, any dev could make their own Gentoo/x86 project. I think that's crazy. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Thomas Cort wrote: On 10/4/06, Luca Longinotti [EMAIL PROTECTED] wrote: The number of opened bugs has always been higher than the number of closed bugs in the bug stats listed in every 2006 GWN. How is this 'going forward'? It seems to me like we are falling behind. That's not an indicator you can really trust imo... A lot of those are WTF??? segfault? eh? and/or waiting on user input because they're irreproducible by the devs involved, but I agree, there are a lot of open ones because lately it seems that people tend to just go MIA, return sometimes, do 1-2 commits, then away again... This has to stop and such people have to be retired, but devrel already does that. And orphaned/broken ebuilds do get punted from the tree... TreeCleaners! Who decides what goes away and what now? Which criteria is used here? Duplicate packages (we don't need more than a few mp3 players), unpopular packages with only a few users, unmaintained packages, and broken packages. We've all seen how we don't need more than a few mp3 players when trying to remove XMMS, which is _broken_, _old_ and _dead_. :) One of Gentoo's strenghts is the it's all about choice paradigm, don't ever remove that, ever. ;) If there are people willing to maintain them, or if they are not broken and perfectly work, don't kill stuff just because you think it's duplicate/useless/unpopular. We would provide a set of packages for most things a user would want to do and then sunrise/someone else provides ebuilds for the rest. I was thinking something similar to what Ubuntu does, they provide the basics to do most things and then they have universe and multiverse repos for extra stuff. Yes, but we're a meta-distro, we do not know what the user wants to do, he just does... I myself run desktops and www-servers, mail-servers, others run embedded-apps, game-servers etc... So the whole breaking stuff up idea that's cursing atm through the blogs just doesn't cut it, and would imo in the end only increase maintainance because packages are spread out and you have to jump through loops to get them like you want. - Formal approval process (or at least strict criteria) for adding new packages Err what? I believe that we have too many packages for us to maintain. We have over 11,000 packages (over 24,000 ebuilds) and only about 175 active developers. I don't think its maintainable and I don't think adding more packages will make it any better. TreeCleaners, to an extent Security etc. _do_ remove what is dead, what has reached points of unmaintainability and brokenness that cannot be anymore supported. The rest still is there because it works (so why remove it?), or because it has someone that keeps it alive (so why remove it?). If there's something to do here, it's kicking out old, broken stuff etc. faster and improving QA (as Kevin already pointed out), definitely not making it so difficult to add new stuff that no one will, that only produces stagnation of the tree in the end. - Make every dev a member of at least 1 arch team Which doesn't mean he will ever keyword stuff stable, other than his own, which he already can... Every developer should have access to at least 1 Gentoo system. They should also be able to determine if something is stable or not. It would cut down on the number of keyword/stable bugs if developers did a lot of their own keywording. Cool... But that's exactly what the arch-teams were created against... From what I always understood arch-teams are there to have a second set of eyes for stabling and testing stuff, even if the maintainer himself can do that. Then he can stable his own stuff (just ask the arch-team permission), or not... And the arch-team may or not give permission, depends on the package in question. That's a relatively good approach that ensures a measure of peer-review at least on the important packages. - Double the number of developers with aggressive recruiting That's something that goes on since... Even when someone is found it is hard for them to find mentors. We need to improve this. I had found someone who wanted to join the sound team and I was unable to locate a mentor for him (I wasn't a dev for 6 months then, so I couldn't do it myself). I e-mailed [EMAIL PROTECTED] and only one person offered. The person who offered fell through because he didn't have enough free time. Ok, so I don't see how aggressive recruiting would improve that... Improving recruiters/mentors capacity would have to be done first, so even if we did some aggressive recruiting (which I'm not sure would bring quality... probably quantity hey cool Gentoo wants new devs, let's join cause I like Linux! w0h000!!11!), we wouldn't have the resources to sustain it. - No competing projects Kills innovation... What happened to working together? Should we work together instead of competing against each other? Sure, working together is cool, but it doesn't always work, it never always
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 2006-10-04 at 07:00 -0400, Thomas Cort wrote: There have been a number of developers leaving Gentoo in the past 6 months as well as a number of news stories on DistroWatch, Slashdot, LWN, and others about Gentoo's internal problems. No one seems to have pin pointed the problem, but it seems glaringly obvious to me. We simply don't have enough developers to support the many projects that we have. Here are my ideas for fixing this problem: - Cut the number of packages in half (put the removed ebuilds in community run overlays) I'm not sure that this really would solve much of anything. I do agree that putting removed ebuilds in community-run overlays isn't a bad idea, but reducing the number of packages for the sake of reducing does nothing more than decrease the usefulness of Gentoo to many people. - Formal approval process (or at least strict criteria) for adding new packages This sounds like too much overhead. - Make every dev a member of at least 1 arch team Absolutely not. The last thing that we need from a QA standpoint is having every single developer allowed free reign for marking their own packages stable, then completely ignoring bugs for any packages that are not their own. - Double the number of developers with aggressive recruiting Why do people think that this is a good idea? I have a different one. How about we *half* the number of developers, keeping the people who do the most work, and let everyone else contribute as members of the community? Having developers on projects/teams/herds/whatever that do only a few commits a year doesn't do anything but artificially inflate our numbers. - No competing projects I wouldn't mind this. The idea of competing *official* projects seems rather ludicrous. Of course, to counter this, we would need some way to create semi-official projects. Projects that are supported within themselves but not by Gentoo as a whole. This would allow for multiple teams to create projects that competed, but then let time and actual usage decide which (if any) becomes official. - New projects must have 5 devs, a formal plan, and be approved by the council I only agree to the second of these three points. Projects should have a plan. The council definitely should not be a bottleneck in starting new projects, unless someone was going to start paying us so we can meet all the time to make all these decisions. ;] - Devs can only belong to 5 projects at most This is a really bad idea. Some developers simply work harder/faster/more than others. Setting up some artificial limitation on how many projects one can belong to won't help. Perhaps a better solution here is that all developers must belong to at least one project? Coupled with this would be that there would be certain expectations within the project for work completed. Developers who do not meet the quota are removed from the project. Get removed from all your projects and get retired. Simple as that. - Drop all arches and Gentoo/Alt projects except Linux on amd64, ppc32/64, sparc, and x86 Quite honesty, Gentoo/BSD (for example) has been excellent in finding issues with quality on many packages/ebuilds. The same can be said for many of the architectures. Also, remember that there's a difference between our supported architectures/projects and our unsupported ones. - Reduce the number of projects by eliminating the dead, weak, understaffed, and unnecessary projects This would be highly subjective. Who would do this? - Project status reports once a month for every project To whom? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Cort wrote: [. . ] My, that's an awful lot of work on top of everything else we have to do. D'you plan on getting us all paid, as well? That'd be motivation to stay and be even more productive. Also, it's not necessary for every dev to also be a member of an arch team -- it's better that developers can choose *where* they want to focus their energy and time -- otherwise people'd be bugging deves who're primarily infra (in their heads, at least) about bumping firefox, userrel would be badgered about broken kde stuff, and GDP would have to field new ebuild requests. Separation of responsibilities is obviously a much better solution. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFI8P3rsJQqN81j74RAhp6AJoCgWipvFO0BKZpU3KW84DvgrxoIQCglEsO GhfVtGcx0gohh2lmFyixcAg= =a+M/ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
- Project status reports once a month for every project Totally agree on this one! OK. I'll give you Release Engineering's status reports for September, October, and November: September: taking a well-deserved break October: taking a well-deserved break November: taking a well-deserved break How about other projects that rely on things like upstream's release cycle? What about projects that just maintain ebuilds? Here's the games team's status reports for every month: Fixed more bugs, added more packages, cleaned up some ebuilds. Now, perhaps what everyone would like, instead, would be status reports *where necessary* from certain projects? In fact, the council has been discussing asking a few projects about the status on some of their tasks. The main reason for this is for communications purposes. Basically, we'd just get a Hey, where are you at on $x? response from the teams. I don't *want* to drown projects in bureaucracy and paperwork. I want them to *accomplish* things, instead. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wednesday 04 October 2006 07:21, Diego 'Flameeyes' Pettenò wrote: I would say to drop everything bug sparc and ppc64, that seems to be the only arch teams that actually respond in a timely fashion to keywording requests. too bad sparc is tied to old kernels and ppc64 toolchain is useless -mike pgpBOFf3i7hpy.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: - Project status reports once a month for every project Totally agree on this one! OK. I'll give you Release Engineering's status reports for September, October, and November: September: taking a well-deserved break October: taking a well-deserved break November: taking a well-deserved break How about other projects that rely on things like upstream's release cycle? What about projects that just maintain ebuilds? Here's the games team's status reports for every month: Fixed more bugs, added more packages, cleaned up some ebuilds. Now, perhaps what everyone would like, instead, would be status reports *where necessary* from certain projects? In fact, the council has been discussing asking a few projects about the status on some of their tasks. The main reason for this is for communications purposes. Basically, we'd just get a Hey, where are you at on $x? response from the teams. I don't *want* to drown projects in bureaucracy and paperwork. I want them to *accomplish* things, instead. Hear, hear! ++ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFI8ZJrsJQqN81j74RAt5GAJ9UletQJrSllbOuk4WG1Ro+XEvlLQCfY9VE bLWnmc2rJ6Z6Mx9dmvnEQ7I= =JbqS -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 2006-10-04 at 07:15 -0500, Brandon Low wrote: Remember when committing a big bug into the tree just wasn't that big of a deal, because it'd get fixed soon, and the people who updated often enough to care in the meantime would just laugh about it with you in #gentoo? This is definitely something that we've lost. Major bugs sit waiting for the maintainer to fix them, when really, anyone who spots the bug should be free to fix it, so long as they inform the maintainer. Yes, commenting to the effect of I fixed this by doing $blah on a bug report *is* informing the maintainer. What if the problem is too many devs instead of too few? Slackware Linux is a comparatively simple to maintain distribution, but ONE person does it. How many devs are on Gentoo now? 200? more? A close knit group of college students and bored professionals should be able to maintain this distribution. I really want to see another checking of the CVS logs (without names, of course) to see just how much work how many developers do. I'd be interested to know if it really is a very few doing most of the work. I would venture to say that it is, and CIA stats seem to agree. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
- Double the number of developers with aggressive recruiting Why do people think that this is a good idea? I have a different one. How about we *half* the number of developers, keeping the people who do the most work, and let everyone else contribute as members of the community? Having developers on projects/teams/herds/whatever that do only a few commits a year doesn't do anything but artificially inflate our numbers. Even if someone only does a little bit of work (maintaining a package or two and only doing one or two commits per month), it is better than none. Does having active accounts for these people produce very much extra work for infra or anyone else? I only see it as a benefit to users (things get done faster) and developers (one less bug to fix). The only problem I have with low activity developers is when they don't commit fixes for bugs that are assigned to them in a timely manner. - Devs can only belong to 5 projects at most This is a really bad idea. Some developers simply work harder/faster/more than others. Setting up some artificial limitation on how many projects one can belong to won't help. Perhaps a better solution here is that all developers must belong to at least one project? Coupled with this would be that there would be certain expectations within the project for work completed. Developers who do not meet the quota are removed from the project. Get removed from all your projects and get retired. Simple as that. I really like your idea. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 14:18:54 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 4 Oct 2006 15:02:17 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | Yuck. Devs should be free to add whatever packages they like, | provided they're willing to maintain them. There're already some restrictions: http://devmanual.gentoo.org/general-concepts/tree/index.html#what-belongs-in-the-tree? Perhaps they should be enforced... Yes, I have no objections to there being rules about what can and cannot be added to the tree, and the ones in your devmanual are clearly sensible and should be applied. I do however object to the suggestion that adding a package to the tree be subject to formal approval (by whom, for a start...). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 09:21:08 -0400 Thomas Cort [EMAIL PROTECTED] wrote: The minority arches like mips, sparc etc seem to get along quite happily. Not the minority arches like m68k, s390, alpha, ... I haven't seen any significant numbers of complaints. What exactly about those arches do you think is a problem? - Reduce the number of projects by eliminating the dead, weak, understaffed, and unnecessary projects Weak: Be more specific. What are the weak projects, and why? Projects that don't achieve anything, have no goals, and don't show any promise of doing anything productive. By specific I meant which projects exactly - i.e name some, and explain how the weakness you perceive is a problem. Understaffed: this issue manifests itself as a project being slow to update. However the only place this is an issue is for security issue management. Another solution to under-staffing is to reduce expectations. The more we reduce expectations, the more it will hurt users. We should be raising expectations and following through. You should only raise expectations when you know you can follow through, not the other way around. Raising expectations before being able to follow through leads to disappointment, which is bad. Unnecessary: again, be more specific. What are the unnecessary projects, and why? Projects that aren't needed to further Gentoo and are not helpful to users or developers. Again, by specific I meant which projects, by name, do you think meet those criteria. Explain why you consider those projects to be a hindrance to users or developers. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 2006-10-04 at 15:34 +0200, Simon Stelling wrote: What happened to working together? Should we work together instead of competing against each other? Sometimes you want to achieve the same goal by totally different means. Sometimes there are good reasons for a complete new start. It does not even mean you don't communicate anymore. Brian Harring, although working on pkgcore which basically competes portage, communicates a lot with the portage team and vice versa, in a very productive manner. Nevertheless, you won't find anybody on the portage or pkgcore team saying that it would have been better to incorporate the ideas of pkgcore into portage. Right. Sometimes it's simply better to start all over again. I completely agree here. I do want to note, though, that Brian is working on pkgcore outside of Gentoo, much like how Paludis is being done. Now, at some point in the future, we might all decide that pkgcore (or paludis, or something else, entirely) would be a better official package manager than portage. So we switch. I think this model for competing projects works out quite well. At the same time, I dislike us having so much competition internally, as I think it helps to foster some of the conflict and ill will that many of us have towards each other. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 04 Oct 2006 09:41:45 -0400 Alec Warner [EMAIL PROTECTED] wrote: Thomas Cort wrote: - Drop all arches and Gentoo/Alt projects except Linux on amd64, ppc32/64, sparc, and x86 I can perhaps see some of this stuff dying. Like all of SPanKY's weird ass arches; I have no idea why they are in the tree. Cool yes...Useful? debatable. My view is that while they're being actively supported, there's no reason to remove them. Granted their mostly SpanKY's babies, but so what? If you're not using those arches, you don't need to get involved. Incidentally you only have to lurk in #gentoo-embedded to see there are users trying Gentoo on all sorts of bizarre boxes; it's something that is much less painful and much more flexible with Gentoo than with any other distribution. I don't like the idea that only stuff used by large groups should be in the tree. I think the criteria should hinge primarily on whether stuff has an active Gentoo maintainer. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 2006-10-04 at 10:38 -0400, Thomas Cort wrote: - Double the number of developers with aggressive recruiting Why do people think that this is a good idea? I have a different one. How about we *half* the number of developers, keeping the people who do the most work, and let everyone else contribute as members of the community? Having developers on projects/teams/herds/whatever that do only a few commits a year doesn't do anything but artificially inflate our numbers. Even if someone only does a little bit of work (maintaining a package or two and only doing one or two commits per month), it is better than none. Does having active accounts for these people produce very much extra work for infra or anyone else? I only see it as a benefit to users (things get done faster) and developers (one less bug to fix). The only problem I have with low activity developers is when they don't commit fixes for bugs that are assigned to them in a timely manner. Basically, the person doing one or two commits a month *do not* need CVS access. They can still *contribute* at their current pace without having CVS access and a nice @gentoo.org email address. All they need is for someone to commit for them, just like every other person who contributes by adding ebuilds/patches/etc to bugzilla. I saw bring in people that *want* to work harder and let the ones that don't contribute like any other user. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wednesday 04 October 2006 17:10, Chris Gianelloni wrote: At the same time, I dislike us having so much competition internally, as I think it helps to foster some of the conflict and ill will that many of us have towards each other. It probably depends to which level of competition we're referring to. Gentoo/FreeBSD can be considered as a competitor for Gentoo Linux, because we try to get the same result (an usable distribution) in a different way (different kernel and userland). KDE is a competitor for GNOME, too, but there's space for both of them in Gentoo. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgp8SssbGfCyL.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On 10/4/06, Kevin F. Quinn [EMAIL PROTECTED] wrote: On Wed, 4 Oct 2006 09:21:08 -0400 Thomas Cort [EMAIL PROTECTED] wrote: The minority arches like mips, sparc etc seem to get along quite happily. Not the minority arches like m68k, s390, alpha, ... I haven't seen any significant numbers of complaints. What exactly about those arches do you think is a problem? The speed at which bugs are resolved is the problem. Keywording/stable bugs can sit for months and sometimes over a year without being touched. Some people think the amount of time some arches lag behind is acceptable, I don't. The primary reason why arches lag is that we don't have enough people doing the testing and keywording. You should only raise expectations when you know you can follow through, not the other way around. Raising expectations before being able to follow through leads to disappointment, which is bad. I think that if we implement my suggestions (drastically reducing the workload), we will be able to meet those expectations. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Basically, the person doing one or two commits a month *do not* need CVS access. They can still *contribute* at their current pace without having CVS access and a nice @gentoo.org email address. Sorry, but as a dev who has lurked in the shadows for a long time, this simply isn't globally true. Sometimes there are packages which the dev takes over that nobody else who is a developer wants or has time to work on. This happened to me when all of a sudden nobody was on the ruby herd anymore. All of my requests went unanswered. So I simply took it over. I really appreciate the handful of devs who do the most commits, but why would you want to add even more to their plates by removing a bunch of the developers who handle smaller stuff. I simply don't have the time anymore to be as active as I used to be years ago. But I still do contribute as much as I can: I keep Qt, Ruby, Ice, and some KDE packages updated. If you want to take away my CVS access because I'm not a power committer anymore it won't hurt my feelings, but I can't imagine how it helps Gentoo in any way. I'll offer a counter proposal: I don't play games on the computer, and they're definitely not required for a working Linux distribution, so I think we should just get rid of all games packages. Let's focus our efforts more on the necessities. My point is that as long as it's of sufficient quality, it's silly not to accept the gratis work that someone's willing to do, be it in putting games into the distribution or making a small number of commits to keep a certain subset of packages up to date. Caleb -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Diego 'Flameeyes' Pettenò wrote: Let's see, about 400 packages are handled by KDE herd. Not sure how many are currently handled by X11 herd after modular Xorg was addded, Around 300, by Josh and me. The number of packages is completely irrelevant on its own, you need to combine it with the amount of work per package to get anything that matters. It would be more useful to figure out which packages are packager-intensive, because those are the big time sinks or the things that require at least one full-time developer to maintain. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Chris Gianelloni wrote: Now, perhaps what everyone would like, instead, would be status reports *where necessary* from certain projects? In fact, the council has been discussing asking a few projects about the status on some of their tasks. The main reason for this is for communications purposes. Basically, we'd just get a Hey, where are you at on $x? response from the teams. I don't *want* to drown projects in bureaucracy and paperwork. I want them to *accomplish* things, instead. I really like the concept of answering questions rather than giving arbitrary reports. The problem is, sometimes nobody outside your project knows the right questions to ask. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Thomas Cort wrote: Unnecessary: again, be more specific. What are the unnecessary projects, and why? Projects that aren't needed to further Gentoo and are not helpful to users or developers. Since Gentoo doesn't have any global goals, it's impossible to tell what's furthering them and what isn't. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Thomas Cort wrote: I mainly wrote No competing projects because there aren't any rules preventing competing projects. Since top level projects don't need discussion or formal approval from anyone, any dev could make their own Gentoo/x86 project. I think that's crazy. Sure, you could in theory, but that doesn't except you from any of our other rules relating to QA etc. I expect it would get old and become too much work very fast. Why do we need a rule for self-correcting problems? Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, Oct 04, 2006 at 10:27:17AM -0400, Chris Gianelloni wrote: Here's the games team's status reports for every month: Fixed more bugs, added more packages, cleaned up some ebuilds. You forgot to mention the weekly team meeting including a motivational speech. Shame on you! Apart from that, i guess a lot of reports will look like that, so i don't really see the point in making them, too. 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 pgp7vIeDq22Fk.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, Oct 04, 2006 at 07:15:16AM -0500, Brandon Low wrote: As usual, sweeping new policies or procedures WILL NOT FIX THINGS. I fully agree to this. While some of the ideas may be good, and some not, each of them should be discussed seperately and eventually something good will come out of it. A list of 10 big changes (some of them even affect our current metastructure) is hardly something that will get clear yes/no support from anyone. 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 pgpV6M3HjSM1n.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Donnie Berkholz wrote: Chris Gianelloni wrote: Now, perhaps what everyone would like, instead, would be status reports *where necessary* from certain projects? In fact, the council has been discussing asking a few projects about the status on some of their tasks. The main reason for this is for communications purposes. Basically, we'd just get a Hey, where are you at on $x? response from the teams. I don't *want* to drown projects in bureaucracy and paperwork. I want them to *accomplish* things, instead. I really like the concept of answering questions rather than giving arbitrary reports. The problem is, sometimes nobody outside your project knows the right questions to ask. I was thinking more about this. What if, instead of these periodic status reports, you just send out a note when something interesting happens? There's no point in holding it back till your monthly required report, and it saves the trouble of the report when nothing's happening. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 2006-10-04 at 13:20 -0400, Caleb Tennis wrote: Basically, the person doing one or two commits a month *do not* need CVS access. They can still *contribute* at their current pace without having CVS access and a nice @gentoo.org email address. Sorry, but as a dev who has lurked in the shadows for a long time, this simply isn't globally true. Sometimes there are packages which the dev takes over that nobody else who is a developer wants or has time to work on. This happened to me when all of a sudden nobody was on the ruby herd anymore. All of my requests went unanswered. So I simply took it over. Looking at CIA, you're nowhere near the target of my comment. I am talking about the people that disappear for months on end, then suddenly come back for a commit or two to keep from being retired. People who ignore their bugs also fit into this category. I'll offer a counter proposal: I don't play games on the computer, and they're definitely not required for a working Linux distribution, so I think we should just get rid of all games packages. Let's focus our efforts more on the necessities. I'll be honest. I don't care. A counter proposal such as this is pretty much given entirely to provoke an emotional response, which I'm simply not going to do. My point is that as long as it's of sufficient quality, it's silly not to accept the gratis work that someone's willing to do, be it in putting games into the distribution or making a small number of commits to keep a certain subset of packages up to date. Nobody is saying that we shouldn't accept work from people. However, there's a difference between accepting one's work and giving them the keys to the castle. Many people also seem to think that someone has to be a developer to do good work. This is absolutely untrue. After all, where do all of our recruits come from? With the increase in developer and project overlays, I see the possibility for reducing work needed to maintain many packages. As Natanael Copa, it would be nice for him to be able to maintain packages without having CVS access. The idea of formalizing and promoting proxy developers has come up a few times before, and I think it is a great idea. Work is done in the overlays, tested, improved, then committed into the main tree once the kinks have been worked out. We get a stronger core tree with fewer developers and a better interaction with the community. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 2006-10-04 at 12:21 -0700, Donnie Berkholz wrote: Donnie Berkholz wrote: Chris Gianelloni wrote: Now, perhaps what everyone would like, instead, would be status reports *where necessary* from certain projects? In fact, the council has been discussing asking a few projects about the status on some of their tasks. The main reason for this is for communications purposes. Basically, we'd just get a Hey, where are you at on $x? response from the teams. I don't *want* to drown projects in bureaucracy and paperwork. I want them to *accomplish* things, instead. I really like the concept of answering questions rather than giving arbitrary reports. The problem is, sometimes nobody outside your project knows the right questions to ask. I was thinking more about this. What if, instead of these periodic status reports, you just send out a note when something interesting happens? There's no point in holding it back till your monthly required report, and it saves the trouble of the report when nothing's happening. That's really a good idea. When I was writing, I was thinking more along the lines of things like: What's the status of bugs getting updated? What's the status of anonsvn/anoncvs? What's the status of QA's policy document? These are things that either are interesting to a large number of developers, and easier to answer once rather than 300 times, or things the council itself has asked a group to do based on one of our decisions. Of course, we could/would take ideas for things to ask, and again, all we need really is something like this (mock) answer: Well, we have all the hardware in place and have gotten access to the systems. We've installed the OS and setup the main databases, but we're still having some issues with the virtual IP scheme, and that's slowing us down on getting this implemented. That's it. No long report or anything is necessary. Just a simple, short few sentences on the current status is all that's really needed for the long ongoing projects. For other things, like, xorg 7.1 going stable or KDE 3.5.5 being unmasked, a simple announcement from the team when it happens should really cover it. That isn't even necessary from most projects, as they simply do maintenance tasks which don't really need an announcement. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On 10/4/06, Chris Gianelloni [EMAIL PROTECTED] wrote: On Wed, 2006-10-04 at 12:21 -0700, Donnie Berkholz wrote: Donnie Berkholz wrote: Chris Gianelloni wrote: Now, perhaps what everyone would like, instead, would be status reports *where necessary* from certain projects? In fact, the council has been discussing asking a few projects about the status on some of their tasks. The main reason for this is for communications purposes. Basically, we'd just get a Hey, where are you at on $x? response from the teams. I don't *want* to drown projects in bureaucracy and paperwork. I want them to *accomplish* things, instead. I really like the concept of answering questions rather than giving arbitrary reports. The problem is, sometimes nobody outside your project knows the right questions to ask. I was thinking more about this. What if, instead of these periodic status reports, you just send out a note when something interesting happens? There's no point in holding it back till your monthly required report, and it saves the trouble of the report when nothing's happening. That's really a good idea. When I was writing, I was thinking more along the lines of things like: What's the status of bugs getting updated? What's the status of anonsvn/anoncvs? What's the status of QA's policy document? These are things that either are interesting to a large number of developers, and easier to answer once rather than 300 times, or things the council itself has asked a group to do based on one of our decisions. Of course, we could/would take ideas for things to ask, and again, all we need really is something like this (mock) answer: Well, we have all the hardware in place and have gotten access to the systems. We've installed the OS and setup the main databases, but we're still having some issues with the virtual IP scheme, and that's slowing us down on getting this implemented. That's it. No long report or anything is necessary. Just a simple, short few sentences on the current status is all that's really needed for the long ongoing projects. For other things, like, xorg 7.1 going stable or KDE 3.5.5 being unmasked, a simple announcement from the team when it happens should really cover it. That isn't even necessary from most projects, as they simply do maintenance tasks which don't really need an announcement. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation How about something in the planet format that where each group reporting status could do so at their schedule when they feel an update is necessary or warrented. Then users could just read the website for the latest status updates. There are a few hot items many people are interested in such as kde or gnome stablization, for example. A simple line like Don't expect KDE 5.0 to go stable before the end of the year provides transparency and a bit of communication to the user community. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On 10/4/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Work is done in the overlays, tested, improved, then committed into the main tree once the kinks have been worked out. We get a stronger core tree with fewer developers and a better interaction with the community. And a Gentoo that's so deeply loved by those who enact this plan that they've strangled it with their love. Ugh. No thanks. Gentoo's not just a project, it's a community. Those of us who work within it have a moral duty to preserve it, and all the opportunities it offers people, for the developers who will come after us. It is _not_ for us to steal those opportunities from future generations. Gentoo isn't ours. We just hold it in trust for the moment. Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, Oct 04, 2006 at 10:36:37AM -0400, Chris Gianelloni wrote: On Wed, 2006-10-04 at 07:15 -0500, Brandon Low wrote: What if the problem is too many devs instead of too few? Slackware Linux is a comparatively simple to maintain distribution, but ONE person does it. How many devs are on Gentoo now? 200? more? A close knit group of college students and bored professionals should be able to maintain this distribution. I really want to see another checking of the CVS logs (without names, of course) to see just how much work how many developers do. I'd be interested to know if it really is a very few doing most of the work. I would venture to say that it is, and CIA stats seem to agree. I've just blogged about this including a fancy graph of commit activity versus devs. See http://kloeri.livejournal.com for the glory details or wait for it to show up on http://planet.gentoo.org. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 2006-10-04 at 17:13 -0400, Chris Gianelloni wrote: With the increase in developer and project overlays, I see the possibility for reducing work needed to maintain many packages. As Natanael Copa, it would be nice for him to be able to maintain packages without having CVS access. The idea of formalizing and promoting proxy developers has come up a few times before, and I think it is a great idea. Work is done in the overlays, tested, improved, then committed into the main tree once the kinks have been worked out. We get a stronger core tree with fewer developers and a better interaction with the community. Some projects/herds already work this way with good results. We regularly get contributions from users that go into our overlay, get tested by us and other users and then get into the main portage tree some time later. We have a very low barrier to entry, it's just darcs record; darcs send. Then one of the devs reviews and applies/rejects the patch. Easy. For some of our ebuilds we already have de-facto proxy developers. -- Duncan Coutts : Gentoo Developer (Haskell team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 09:46:31 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: too bad sparc is tied to old kernels and ppc64 toolchain is useless Depends on your sparc64 box. Most of them are fairly stable now. Its just the SBUS boxes and some of the pricier hardware that may be problematic. Cheers, -- Jason Wever Gentoo/Sparc Team Co-Lead signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 04 Oct 2006 10:27:17 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: - Project status reports once a month for every project Totally agree on this one! OK. I'll give you Release Engineering's status reports for September, October, and November: September: taking a well-deserved break October: taking a well-deserved break November: taking a well-deserved break Well, in the past, I've found that even getting brief reports like that is very helpful when I've been running meetings. It's just generally good to know that folks are alive and such, and a brief Hi, we're still here kinda report every month is nice for that. Just a quick email before the meeting works fine. Also, it gets everyone in the habit of giving reports, so that they remember to report when something new happens. I don't *want* to drown projects in bureaucracy and paperwork. I want them to *accomplish* things, instead. Sending a brief All's well with releng email isn't exactly what I would call drowning in bureaucracy. -- Mike Kelly signature.asc Description: PGP signature
