Re: [gentoo-dev] 2.6.18 going stable in 1 week
On Fri, 20 Oct 2006 16:17:51 +1000 Andrew Cowie [EMAIL PROTECTED] wrote: While Thomas's questions are pertinent, his tone was rather hostile and remarks accusatory. That's unfortunate. I hope dsd doesn't take it too personally. Sorry if it came across rather harsh, it was not my intent. I guess I was just having a bad day and it came through in the e-mail. I just wanted some clarification on what exact package(s) and arch(s) are involved. Meanwhile, on behalf of everyone else in the community, I'd like to say a great big huge thank you to Daniel for his continued hard work on kernels for Gentoo. I second that! Without the Gentoo kernel team, we'd be screwed. They put in countless hours of hard work into all of the different kernel packages and patch sets. -Thomas pgpTQRnlk27cr.pgp Description: PGP signature
[gentoo-dev] [adopt-a-dev] New hardware needs and offers
You haven't gotten one of these e-mails from me for a few week because there hasn't been a lot of activity. However, this week we got quite a few CPU offers and a request from a developer who is in need of a hard drive. Just a reminder, we have a spiffy list of stuff that people want to give developers and a list of stuff that developers could use to improve Gentoo. http://www.gentoo.org/proj/en/userrel/adopt-a-dev/ There are currently over 30 items available to devs and 16 items that developers could benefit from having. -Tom Community Member Offers === Offered Resource: Pentium III 800/256/133/1.7V - Slot 1 CPU Name: Mr. Anonymous Location: Paris, France Last Modified: 2006-10-17 03:52:51 Offered Resource: Pentium III 866/256/133/1.7V - Slot 1 CPU Name: Mr. Anonymous Location: Paris, France Last Modified: 2006-10-17 03:53:12 Offered Resource: Pentium III 800/256/133/1.7V - Socket 370 CPU Name: Mr. Anonymous Location: Paris, France Last Modified: 2006-10-17 03:49:41 Offered Resource: Pentium III 733/256/133/1.7V - Socket 370 CPU Name: Mr. Anonymous Location: Paris, France Last Modified: 2006-10-17 03:50:18 Offered Resource: 128MB Memory DIMM SDRAM *ECC* (Various brands) Name: Mr. Anonymous Location: Paris, France Last Modified: 2006-10-17 03:50:34 New Developer Requests == Name: Chris White Location: CA, USA Resource: 10GB+ SCSI Disk Purpose: I'd currently like to use the alpha workstation I have for desktop related testing for the alpha herd, however I have a small drive (about 3 gigs) which could work for the basics, but I'd like to do a bit more testing than that. Last Modified: 2006-10-17 03:51:35 pgpdLTqS2zwUz.pgp Description: PGP signature
Re: [gentoo-dev] 2.6.18 going stable in 1 week
On Thu, 19 Oct 2006 21:21:21 -0400 Daniel Drake [EMAIL PROTECTED] wrote: This is your 1 week warning.. fix any packages which don't compile and ensure the fix is also in the stable tree. What package(s) are going stable in 1 week? I have no clue what you are writing about since you didn't mention it in your e-mail. I did a quick search and found the following 6 packages which have a version 2.6.18: gentoo-sources-2.6.18 linux-headers-2.6.18 suspend2-sources-2.6.18 usermode-sources-2.6.18 vanilla-sources-2.6.18 You also neglected to mention which architectures are going stable. Are all arches going stable at the same time (in 1 week)? Will you still go ahead with the stable marking if http://bugs.gentoo.org/148429 is not resolved? -Thomas pgpFKGYqGRxKO.pgp Description: PGP signature
[gentoo-dev] Gentoo World Domination. a 10 step guide
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) - Formal approval process (or at least strict criteria) for adding new packages - Make every dev a member of at least 1 arch team - Double the number of developers with aggressive recruiting - 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 - Drop all arches and Gentoo/Alt projects except Linux on amd64, ppc32/64, sparc, and x86 - Reduce the number of projects by eliminating the dead, weak, understaffed, and unnecessary projects - Project status reports once a month for every project pgp89OuXfijll.pgp Description: PGP signature
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
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
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
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
- 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 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] New project: Gentoo Seeds
On Tue, 19 Sep 2006 21:11:17 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: why does it need to be part of releng ? releng and seeds will be doing similar tasks, releasing stage tarballs. -Thomas pgpIH4JTTufWm.pgp Description: PGP signature
Re: [gentoo-dev] New project: Gentoo Seeds
On Tue, 19 Sep 2006 20:00:59 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: [1] http://www.gentoo.org/proj/en/seeds/ Why is this being done as a top level project instead of as a subproject of Release Engineering? -Thomas pgpNbVfRl5I2l.pgp Description: PGP signature
[gentoo-dev] [adopt-a-dev] New Resource Offers and Requests
Below are all of the community member offers and developer requests made in the last 7 days. As always, the full list of offers and requests can be found on our project page http://gentoo.org/proj/en/userrel/adopt-a-dev/index.xml -Thomas Community Member Offers === None this week. New Developer Requests == Resource: A PCI-E SCSI controller (needs to be U160 or better and not wider than PCI-E x4; must have an external connector to use with tape drives) or a SCSI-iSCSI converter Purpose: To maintain iSCSI packages and to maintain a lot of the backup packages dealing with tape drives. Name: Robin Johnson // Location: Burnaby, BC, Canada pgpXZbMjUvYDe.pgp Description: PGP signature
[gentoo-dev] [adopt-a-dev] New Resource Offers and Requests / 2 Policy Changes
There are two adopt-a-developer policy changes. The max value limit for each item has been raised from $100 to $250. Things are going well and we plan on removing the limit entirely in the future. We're just waiting for an accountant to get back to Christel about some questions we have relating to taxes on personal gifts. We want the information so that we can inform developers about possible taxes on high value items and where to find more information. The other change relates to the maximum number of open requests per developer. During the user relations meeting we opted to limit the number of open requests to 4 per developer. If the developer has 4 open requests and needs something more urgently he or she can always ask us to remove an item to make room for a more urgently needed item. This is a temporary policy. In a few weeks we will evaluate if we want the policy to be permanent or if we want to try something else. Below are all of the community member offers and developer requests made in the last 7 days. I missed sending this out last week, but I'm working on automating these e-mails, so it shouldn't happen in the future. As always, the full list of offers and requests can be found on our project page http://www.gentoo.org/proj/en/userrel/adopt-a-dev/index.xml -Thomas Community Member Offers === Offered Resource: GNU Autoconf, Automake, and Libtool ; ISBN 1578701902 Name: Kurt Hindenburg Location: Indianapolis, IN, USA Last Modified: 2006-09-02 14:46:44 New Developer Requests == Resource: Any ethernet card that is known to work in Linux and Mac OS X on a PowerMac G5. Purpose: To do testing of Java and other packages on ppc, ppc64, and maybe even ppc-macos. Name: Joshua Nichols Location: Boston, MA, USA Last Modified: 2006-08-31 16:18:17 Resource: orinoco gold usb wireless device Purpose: To help with the drivers. Name: Steev Klimaszewski Location: Tulsa, OK, USA Last Modified: 2006-08-31 16:05:37 Resource: Battery for a Japanese Sharp Mebius PC-CB1-CD to replace a dead battery (model number CE-BN12). Purpose: So that Steev isn't stuck to a power outlet. Name: Steev Klimaszewski Location: Tulsa, OK, USA Last Modified: 2006-08-31 16:08:12 Resource: A bluetooth USB dongle from this list ( http://www.holtmann.org/linux/bluetooth/features.html ) Purpose: Replacement of a usb dongle, required to perform development and tests on kdebluetooth and other bluetooth-related applications running on Gentoo. Also required to keep an up-to-date bluetooth guide. Name: Ioannis Aslanidis Location: Tarragona, Spain Last Modified: 2006-09-02 14:41:41 Resource: Intel Pentium 4 Northwood - 2.0A GHz Processor ( http://www.pricegrabber.com/search_getprod.php/masterid=535580/search=intel+pentium+4+2.0+ghz/ ) (2.0GHz, 512KB, 400 MHz, Socket 478 - MPN: BX80532PC2000D) Purpose: general development work, improve productivity Name: Chris White Location: CA, USA Last Modified: 2006-09-02 17:33:26 Resource: Any linux-supported DEC Alpha workstation with at least a 400MHz processor, =128MB of memory, a supported PCI video card, and a CD-ROM (bonus if it can read CD-RW without a problem). Purpose: Support for the alpha architecture in the Gentoo Installer. Name: Andrew Gaffney Location: St. Louis, MO, USA Last Modified: 2006-09-04 15:29:05 pgpxgjkCvNG8t.pgp Description: PGP signature
[gentoo-dev] [adopt-a-dev] New Resource Offers and Requests
Greetings Fellow Developers, New items are being added to the Adopt a Developer project page[1] all the time. However, developers who don't check the project page won't know about all the new stuff. Similarly, users won't be aware of new developer needs unless they check the project page. So, I'd like to send weekly e-mails to gentoo-dev@gentoo.org with lists of new offers and requests. If this is a problem, or if you think 7 days would be too frequent, or if this type of thing is unwanted, let me know. The e-mails will contain [adopt-a-dev] in the subject line so that they can easily be filtered. Below is a list of new offers and requests made in the last 7 days. The weekly e-mails will contain something similar to this. The complete list of developer requests and community member offers (currently at 8 requests and 23 offers) is available on our project page. [1] http://www.gentoo.org/proj/en/userrel/adopt-a-dev/index.xml -Thomas Community Member Offers === Offered Resource: Xen Virtual Server, Unlimited storage within reason, 100MB+ Ram, 100Mbit Burstable, 5Mbit dedicated, unlimited throughput. Backup and Restore points can be created by request. Name: Ryan Gibbons Location: Fort Worth, Texas, USA Last Modified: 2006-08-16 13:15:05 Offered Resource: Hitachi HTS721010G9SA00 100GB, 7200rpm, 2.5 SATA HD. Name: Richard Fish Location: Phoenix, AZ, USA Last Modified: 2006-08-13 18:25:04 Offered Resource: Hitachi HTS541080G9SA00, 80GB, 5400rpm, 2.5 SATA HD. Name: Richard Fish Location: Phoenix, AZ, USA Last Modified: 2006-08-13 18:25:15 Offered Resource: TDK 4800B IDE 52x CD-RW internal drive (beige) Name: Steve Dibb Location: West Jordan, UT, USA Last Modified: 2006-08-14 05:35:12 Offered Resource: Sharp Zaurus SL-5500, dock and charger. Name: Tom Wesley Location: UK Last Modified: 2006-08-15 11:11:20 Offered Resource: Belkin Nostromo n50 Speedpad. Name: Thomas Heinrichsdobler Location: Germany Last Modified: 2006-08-18 19:56:32 New Developer Requests == None in the past 7 days. pgpTGLxKghEmb.pgp Description: PGP signature
Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]
You should look for existing tools which could be enhanced before suggesting a new one. `bugz post` (from www-client/pybugz) allows you to submit a new bug report from the command line. Why don't you go and patch that to do all of the automated things you want it to do and then come back and show us? -Thomas On Wed, 16 Aug 2006 12:52:03 +0200 Enrico Weigelt [EMAIL PROTECTED] wrote: * Denis Dupeyron [EMAIL PROTECTED] schrieb: Hi folks, just a few thoughts: So yes, I'd love to see something like this someday. And I'd love to help implementing it if such a decision was taken. But the question remains : it obviously looks useful, but do we need it ? I already suggested an bug-reporting tool, which automatically collects all the necessary data, several weeks ago. This tool is simply called by commandline and asks the users several questions. Then it files an bug with some certain syntax and uploads necessary information (emerge --info, pkg-db extracts, ...). Maybe this also could take some load from the bug wranglers, because based on the user's answers, the bugs could be formatted and assigned to the right persons without manual interaction. I also like to have such an tool, and like to contribute. So, now, let's start :) Some points which (IMHO) have to be discussed: * shall we directly access BGO ? * what data should be sent ? * how to gather this data (directly look into /var/db/pkg) ? * what questions should be asked ? * should this tool create usual bugs or separate user-support bugs ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list pgpwACxb7MVjx.pgp Description: PGP signature
Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]
On Wed, 16 Aug 2006 18:11:24 +0200 Enrico Weigelt [EMAIL PROTECTED] wrote: I'm working on my own tool, written in java. That's great. Have you or are you going to setup a project page somewhere (maybe sourceforge.net)? You should be aware that java isn't available on every platform that Gentoo supports and isn't Free software. virtual/jre | a a a h i m m p p p s s s x x | l m r p a 6 i p p p 3 h p 8 8 | p d m p 6 8 p c c c 9 a 6 6 | h 6 a 4 k s 6 - 0 r - | a 4 4 m c f | a b | c s | o d | s --+-- 1.3 | ~ + 1.4.1 | + + 1.4.2 | + + + + ~ + 1.5.0 | ~ ~ ~ ~ ~ ~ ~ pgp84btXqOJWV.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: AT emerge info cruft attachments on bugs.g.o
On 11 Aug 2006 00:00:00 + [EMAIL PROTECTED] (Christian 'Opfer' Faulhammer) wrote: Tach Jeroen, 0x2B859DE3 (PGP-PK-ID) Jeroen Roovers schrieb: One solution might be to open your own AT bug, make the stabilisation bug depend on it, and use the AT bug to have ATs post their `emerge info`. Then, when testing and stabilisation is finished for your arch, close the AT bug and remove your alias from the stabilisation bug's CC list. I for one could live with this solution to the problem, which I hope you understand by now. This sounds quite interesting...maybe some arch devs should comment on that. The only problem I see is when two ATs test at the same time and open two separate bugs for the same arch. And another problem: Other arches don't see the problems in the depending bug and are unlikely to comment on it. Besides the points you mentioned, it would create a lot of bug spam. There would be the a new bug depends on this bug e-mail when the AT files the bug, then there would be the a bug that depends on this bug has changed state e-mail when the arch dev closes the AT's bug, and then there would be the e-mail from the arch dev when he/she comments on the original bug saying arch-xyz stable -Thomas pgpsF5RKCaBpJ.pgp Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft attachments on bugs.g.o
On Thu, 10 Aug 2006 19:50:55 +0200 Jeroen Roovers [EMAIL PROTECTED] wrote: I propose the `emerge --info` included in arch testers' comments on stabilisation bugs should rather be posted as attachments. The AT comments clog up the bugs and are usually not interesting at all to devs other than those who are arch devs for the relevant arches. It would certainly improve my RSI not to have to scroll past them. Why do arch testers need to post `emerge --info` if everything works? Shouldn't we be able to trust that they have sane CFLAGS, proper FEATURES, and an up to date system? On a minor note, I'd also like to see bug reporters use canonical package names in bug descriptions, including the category (and preferably the specific version, not some =foo-3*!!!one, not to mention specifying no version at all). Including the category means arch devs won't need to guess/discover which of a few hundred categories a package is meant to reside in. I totally agree. An AT or arch team member should know which category, package, and version to test from the bug summary alone. -Thomas pgp53iXA6klQv.pgp Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft attachments on bugs.g.o
On Thu, 10 Aug 2006 23:58:46 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: It's not about trust, it's about knowing what the CFLAGS/FEATURES were. That way if someone else reports a failure, you can compare the reports and see what differences might be triggering the fault. I get that posting `emerge --info` provides a known good set of CFLAGS/USE-flags/FEATURES/toolchain versions/etc which can be useful at times. However, we don't require that developers post their emerge --info when a package works, so why do we require that ATs do it? -Thomas pgpdK7lzralER.pgp Description: PGP signature
Re: [gentoo-dev] client+server packages - build which one?
On Tue, 8 Aug 2006 16:46:08 +0200 Enrico Weigelt [EMAIL PROTECTED] wrote: How can I get an patch downloaded from some location and then applied ? I've inspecting some ebuilds in the portage tree and learned how to apply patches in the files/ subdir. Now I need to know, how to download the patches (simply add them to $SRC_URI ?) and then get them referenced for applying ? This list is not the 'teach me how to write ebuilds' mailing list. If you want help writing ebuilds, #gentoo-dev-help on irc.freenode.net is the place for it. You should read the following documents all the way through before asking for help: http://devmanual.gentoo.org/ http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml -Thomas pgpEE1WfwrHIr.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for advanced useflag-syntax
On Tue, 8 Aug 2006 16:50:18 +0200 Enrico Weigelt [EMAIL PROTECTED] wrote: * Jan Kundrat [EMAIL PROTECTED] schrieb: On Tue, 8 Aug 2006, Enrico Weigelt wrote: For example: I've got several headless server systems where I now have to run some X applications. I only need xlib (and its deps) on this system, not the whole X distribution. In a monolithic world, I would have to install *everything*, from server to tools, just for getting some libs. Or you could have used the minimal USE flag. And what does this flag exactly say at this point ? $ grep minimal /usr/portage/profiles/use.desc minimal - Install a very minimal build (disables, for example, plugins, fonts, most drivers, non-critical features) Install only xlib ? Install xlib and some further ones ? Which ones ? Install all libs ? Look at the ebuilds and you will find the answer to these questions. -Thomas pgph43QwSXaOH.pgp Description: PGP signature
[gentoo-dev] Adopt a Developer needs Developer Requests
Hello, The Adopt a Developer[1] project hasn't gotten any requests[2] from developers needing hardware or shell accounts or books or anything else, so I'm just writing a little note to encourage any developer (who has been a developer for at least 6 months) who could use extra stuff to improve Gentoo to please request it. As mentioned before, to test the waters, we are only dealing with items worth about $100US or less. Some ideas for things you could request: used PDAs (the pda herd really could use some help), GPS units to help with the gps herd, extra RAM to improve compile times, a hard drive, Logictech mice (sys-apps/locomo), TV tuner card (for PVR packages), wireless cards to help the wireless herd, etc, etc. Arch team members could request hardware to test hardware specific packages on their architecture. A few community members have offered[3] hosting with shell access if anyone could use that to improve Gentoo. [1] http://www.gentoo.org/proj/en/userrel/adopt-a-dev/index.xml [2] http://www.gentoo.org/proj/en/userrel/adopt-a-dev/request.txt [3] http://www.gentoo.org/proj/en/userrel/adopt-a-dev/index.xml#doc_chap8 -Thomas pgpkNVc1I6VuJ.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for advanced useflag-syntax
On Mon, 7 Aug 2006 15:26:44 +0200 Enrico Weigelt [EMAIL PROTECTED] wrote: The bad thing is that those things don't get neither into the upstrem nor other distros. ^--- This should be a warning flag ---^ If other distros aren't doing it and upstream isn't doing it, then it may no be that great of an idea. -Thomas pgpLQVi8H7Dgw.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Masking practics
On Mon, 7 Aug 2006 23:01:45 +0200 Enrico Weigelt [EMAIL PROTECTED] wrote: Obviously, not everyone wants to be vigilant - but if you aren't - then you don't get to whine about it when it breaks. well actually I guess you do... So, you don't have any intention to help people who don't have such an eagle-eye on single chars, even it could be easy ? Users can help themselves. The D is in the exact same place (right before the ']') and in a different color (dark blue). You can use grep to find the downgrades: emerge -uD world -vp | grep D\] or grep D\] email.txt pgprcuY92v48z.pgp Description: PGP signature
Re: [gentoo-dev] Developer Upgrade! Steve Dibbs
On Mon, 07 Aug 2006 00:20:07 +0100 Christel Dahlskjaer [EMAIL PROTECTED] wrote: It is with geat pleasure that I can knight Steve (aka beandog) a 'real dev'. Welcome aboard Steve :) -Thomas pgpsuf54EbUFn.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Overlays: Status Report
On Fri, 04 Aug 2006 21:02:15 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: I think we're ready to announce the service, but before we do, I thought it'd be a good idea to get feedback from the wider dev community. I've got an overlay on overlays.gentoo.org. It is working out very well. Thank you for providing such a useful service. It saves me the time of setting up and running my own svn hosting and web pages. I have 2 suggestions. On the wiki[1], there is an image in the upper left that says gentoo overlays, but it links to gentoo.org. Could that be changed to link to overlays.gentoo.org? As far as I can tell, there is no link back to overlays.gentoo.org from the trac pages. The other suggestion I have is for the homepage[2] and RSS feed. Would it be possible to get the committer's username listed? Thanks again to everyone in the overlays project for all the hard work. [1] http://overlays.gentoo.org/dev/tcort [2] http://overlays.gentoo.org -Thomas pgpmiQgtQ2iJ1.pgp Description: PGP signature
[gentoo-dev] New Project: Adopt a Developer
Hi, The User Relations project has a new sub-project, Adopt a Developer. The project aims to connect developers who need resources (ie hardware, technical books, shell accounts, etc) with people and companies from the community who want to donate resources. The concept is explained in detail on the project page: http://www.gentoo.org/proj/en/userrel/adopt-a-dev/ -Thomas pgpbd2SikkZpY.pgp Description: PGP signature
Re: [gentoo-dev] net-im/aim masked for removal
On Wed, 2 Aug 2006 16:18:04 -0700 John Myers [EMAIL PROTECTED] wrote: On Wednesday 02 August 2006 16:12, Enrico Weigelt wrote: * Donnie Berkholz [EMAIL PROTECTED] schrieb: I've masked net-im/aim, AOL's proprietary offering. It hasn't seen a release in years, it's binary-only, and it's far less capable than any other client out there. BTW: could be introduce an separate (optional) masking method for such proprietary stuff ? I believe (don't have time to check right now) you'll want to look into ACCEPT_LICENSE http://bugs.gentoo.org/show_bug.cgi?id=17367 pgpftTnRA6JrJ.pgp Description: PGP signature
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
On Thu, 27 Jul 2006 22:19:14 -0400 Luis Francisco Araujo [EMAIL PROTECTED] wrote: The users explicitly compromise to (just to make it clear): [1,2,3,4] People who participate in open projects like Gentoo come and go. What happens if/when the proxy maintainer decides to leave? Who will take care of the package? Maybe the mailing list could also be used to find users to proxy maintain abandoned packages? I know there already exist some developers working as proxy, well, i appreciate if they got any comment or observation about this idea. This is just a way of giving some organization to this kind of cooperative mechanism at some degree. And an 'official' representation inside Gentoo if we agree with it. I work with a user (Kai Huuhko) to maintain media-sound/quodlibet, media-libs/mutagen, and media-plugins/quodlibet-*. I have a dev overlay on overlays.gentoo.org where Kai and I both have commit access. We both work on the ebuilds in the overylay and exchange ideas over e-mail. After the ebuilds are complete and tested, I commit them to the official tree. Kia helps with bugs too. So far it has worked very well for us and we haven't had any problems with the arrangement. Having a helper saves me time and energy, which allows me do other Gentoo related tasks. -Thomas pgpXTAZUK3SsB.pgp Description: PGP signature
Re: [gentoo-dev] architectures which support Java
On Fri, 21 Jul 2006 10:10:42 +0200
Krzysiek Pawlik [EMAIL PROTECTED] wrote:
Joshua Nichols wrote:
Doesn't support:
alpha
Alpha has compaq-{jdk,jre} which requires nast hacks with glibc and
doesn't work - details are in virtual/{jdk,jre} bugs.
compaq-{jdk,jre} were masked by YosWinK on July 7th. The latest version
was 1.3, upstream is dead, the packages are binary only, and they were
compiled against an older version of glibc. LD_PRELOAD Hacks Bug:
http://bugs.gentoo.org/84306
The alpha team is actively seeking a replacement. So far SableVM and
kaffe look the most promising. SableVM's sdk (not in the tree yet)
works for basic things, but doesn't compile ant-core because it is
missing tools.jar. kaffe doesn't pass all of the tests for 'make check'
but improvements are being made. kaffe also has a JIT for alpha, but it
is currently broken. We'll continue to work on the issue, but right now
Gentoo/alpha doesn't support Java.
-Thomas
pgpQxCRfFL8wj.pgp
Description: PGP signature
Re: [gentoo-dev] Modular X (7.0) stable on x86
On Fri, 30 Jun 2006 12:28:30 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: - I'm offering to stable any interested arch for 7.1. PPC, SPARC and MIPS have already taken me up on this. I will be starting this very soon (within 2 hours at most), so respond ASAP if you would like to save yourself a lot of work. I hope I'm not too late. Please include alpha when you stable 7.1. -tcort pgpQXDg340Mng.pgp Description: PGP signature
Re: [gentoo-dev] [experiment] Sunrise try 2
What I need: (from proponents) - A list of issue sunrise wants to address (each point 2 lines at most) - How it will be implemented (from critics) - What is wrong with the model (each point 2 lines at least, 4 at most) - What you'd do as alternative as the criticized point ( 2 lines again) Before people start replying, they should make sure they are familiar with the updated model/policies (read: they've changed since the original discussion on -dev). The new stuff is available at: http://gentoo-sunrise.org/cgi-bin/trac.cgi/wiki/SunriseFaq and http://gentoo-sunrise.org/cgi-bin/trac.cgi/wiki/HowToCommit pgpdZ34r8hJ2R.pgp Description: PGP signature
Re: [gentoo-dev] [experiment] Sunrise try 2
On Sat, 24 Jun 2006 15:36:23 +0200 Luca Barbato [EMAIL PROTECTED] wrote: It isn't in the format useful for a discussion point by point, genstef is converting it, I hope. Yes, this is true. I was just pointing out that things have changed since the original proposal and that before people begin bringing up their points, they should check to see if the issues have already been addressed. -Thomas pgphydpPSsqFo.pgp Description: PGP signature
[gentoo-dev] variable quoting, setting optional variables to , and depending on virtual/libc
What is the proper quoting style for using epatch? In the tree there
are about 3 different styles...
epatch ${FILESDIR}/some-fix.patch # used by 7326 ebuilds
epatch ${FILESDIR}/some-fix.patch# used by 3092 ebuilds
epatch ${FILESDIR}/some-fix.patch# used by 1434 ebuilds
What is the proper quoting style for defining the S variable? In the
tree there are about 3 different styles...
S=${WORKDIR}/${MY_P}# used by 5270 ebuilds
S=${WORKDIR}/${MY_P} # used by 43 ebuilds
S=${WORKDIR}/${MY_P} # used by 2259 ebuilds
What is the purpose of setting DEPEND and RDEPEND to if DEPEND and
RDEPEND are optional[1][2]? Isn't that just a waste of disk space /
bandwidth? DEPEND=virtual/libc seems like a waste too as it is an
implicit system dependency[3], any reason for using it?
DEPEND= # used by 1479 ebuilds
RDEPEND=# used by 884 ebuilds
DEPEND=virtual/libc # used by 809 ebuilds
[1]
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1#doc_chap_pre2
[2]
http://devmanual.gentoo.org/ebuild-writing/variables/index.html#optional-variables
[3]
http://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency
pgptiYOfnSCWC.pgp
Description: PGP signature
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 08 Jun 2006 09:20:18 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: Please keep the games bugs in bugzilla. Making this change is a direct change in games team policy without any prior notice to the games team and without our permission. No one needs permission to put ebuilds from bugs.gentoo.org into an overylay. The ebuilds, assuming they have the proper header, are all Distributed under the terms of the GNU General Public License v2. ~tcort pgpp7kESK1ig9.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
On Thu, 1 Jun 2006 14:10:04 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Thu, Jun 01, 2006 at 03:00:13PM -0500, Grant Goodyear wrote: Paul de Vrieze wrote: [Thu Jun 01 2006, 02:44:39PM CDT] I would like the council to discuss GLEP 49 Incidentally, I drafted a competing GLEP Realize you'ure after keeping it open, but there is more to the tree I would like the council to nail down the details of what package manager specific data can and cannot be put in gentoo-x86 as well as what the requirements and process of replacing or providing an alternative to portage will be. Getting the specifics down in writing will avoid a lot of headaches down the road as non-portage package managers mature. There are a lot of sides to this discussion, almost all of the possible view points were expressed on [EMAIL PROTECTED] All of it is available in the mailing list archives for review, so I'm also asking that the subscribers to [EMAIL PROTECTED] please refrain from starting another flamewar. -tcort pgpInSj1J2hlr.pgp Description: PGP signature
Re: [gentoo-dev] Security/QA Spring Cleaning
On Tue, 23 May 2006 13:44:09 -0700 Brian Harring [EMAIL PROTECTED] wrote: Couple more reports generated (in the parent dir, dropped keywords, imlate, packages that have just ~arch, ebuild metadata verification, and ebuild has been unstable for arch X for greater then N days). Seems like we have a lot of people generating reports aliz http://gentoo.tamperd.net/stable/ blubb http://blubb.ch/gentoo/amd64/ tcort http://dev.gentoo.org/~tcort/imlate/ http://dev.gentoo.org/~tcort/dropped/ ferringb: http://gentooexperimental.org/~ferringb/reports/ halcy0n: http://dev.gentoo.org/~halcy0n/imlate/ http://dev.gentoo.org/~halcy0n/keyword-moves/ hansmi: recently sent the output of imlate.py to [EMAIL PROTECTED] Would it be possible to get a centralized place for all of this stuff? Could a reports.gentoo.org or something similar be setup to run scripts/programs every hour or two? ~tcort pgpAfgcExCelA.pgp Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
On Sat, 20 May 2006 14:54:18 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: *Primary Package Manager* There is one primary package manager. Gentoo has always been about choice, could you explain what is the rationale behind having only one primary package manager? All ebuilds in the tree must function with the primary package manager. I definitely see this is as a requirement. One thing I am wondering is, who is responsible for testing the over 24,000 ebuilds in the tree to make sure that they work with the new package manager? Is it the package manager team, arch teams, package/herd maintainers, arch/herd testers, or others? The primary package manager is maintained on official gentoo infrastructure, under control of gentoo developers. I don't really see this as a requirement. Many Linux distributions use package managers that they don't have direct control over. Ubuntu uses apt, Mandrake uses rpm, etc. ~tcort pgp64t2IttlC2.pgp Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
On Sat, 20 May 2006 17:11:57 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: The primary package manager is maintained on official gentoo infrastructure, under control of gentoo developers. I don't really see this as a requirement. Many Linux distributions use package managers that they don't have direct control over. Ubuntu uses apt, Mandrake uses rpm, etc. Those are binary distributions. Even they have extensions in their own package managers. Binary distribution is easier than from source. One of the strengths of Gentoo is formed by the package manager. If the package manager is out of control of gentoo, this means that Gentoo no longer has control over its future or its features. I definitely agree that Gentoo needs a team of people to deal with the primary package manager, it is one of the most important tools in a Linux system. It is especially important in Gentoo where the package manager is, at this point in time, required to install a standard desktop system. I disagree that the package manager needs to be directly maintained by Gentoo. Since Gentoo will never depend upon a piece of non-Free software[1], it is safe to assume that the package manager is Free software (aka open source). Because of this, we will never be locked-in, helpless, or under the control of an external project. If we dislike the direction in which it is going or want to add our own features, then we are free to do so either by submitting patches upstream, adding our own custom gentoo patches to the stock sources, or by forking the project entirely. So what I suggest is the following: While it is desirable that the primary package manager be maintained on official gentoo infrastructure, under the control of gentoo developers, it is not required. During the path to becoming the primary package manager, the package manager maintainers must be asked if they would like their project to be an official Gentoo project. The package manager maintainers have the right to refuse such an offer if there is a team of at least 3 Gentoo developers that understand the package manager source code and are willing to deal with bugs, testing, feature enhancements, modifications, and integration. I hope the above is an acceptable compromise. It aims at making the project an official Gentoo project while still allowing package managers that aren't under Gentoo's direct control. In that case there are still Gentoo developers who have a handle on the code and can make any modifications / enhancements / feature changes that are required by Gentoo. [1] http://www.gentoo.org/main/en/contract.xml pgpMG26YbC1mC.pgp Description: PGP signature
Re: [gentoo-dev] Signing everything, for fun and for profit
On Fri, 19 May 2006 17:10:53 +0100 Chris Bainbridge [EMAIL PROTECTED] wrote: Well, that would be incompatible with a single signature. I don't really see that point, but then I've been spoiled with broadband for years. Do we really have many users on dialup that it would inconvenience? It doesn't only affect dialup users. I exclude all of the x11/gnustep/gnome/kde/games/xfce/... stuff on some servers I run. It cuts down a little on bandwidth, sync time, and saves disk space. ~tcort pgphnXlOB0hPR.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 11:23:19 +0200 Wernfried Haas [EMAIL PROTECTED] wrote: We really should figure that stuff out before we start integrating an externally written package manager we have no influence on whatsoever No influence? Last I checked, the number of Gentoo developers on the project out numbered the number of non-Gentoo developers 5 to 1. See http://paludis.berlios.de/Authors.html -- ,__, +--+ | Thomas Cort [EMAIL PROTECTED] (oo) |SAVE LARRY| | Gentoo Linux Developer (__))\ +--+ | alpha, amd64, sound ||--|| * | | http://dev.gentoo.org/~tcort pgppZvzq3BbhE.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 15:48:04 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: I also recommend that the package is masked in all Gentoo profiles where a release is built against, since again, it is 100% incompatible and upstream has now said that they have no intentions on making it compatible. rpm, stow, and dpkg are 100% incompatible with portage and I'm fairly certain that upstream has no intentions of making them compatible, yet they are in the tree and stable on many arches. Are you also suggesting that we mask them too? ~tcort pgpQupl89kblC.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Tue, 16 May 2006 16:15:49 +0100 Stephen Bennett [EMAIL PROTECTED] wrote: The next question is where to put it. The options as I see them are under default-linux/x86/ or in a top-level paludis/ a la hardened, selinux, embedded, and the like. The latter is easier to exclude for those worried about tree size, though the impact there should be minimal. Neither way produces significantly more duplication, since we can make use of multiple profile inheritance. If anyone has any preference or other input, I'd like to hear it. I don't understand the logic behind putting it under default-linux/x86/. Is palidus Linux/x86 only? Could you explain why default-linux/x86/ is a good option? -- ,__, +--+ | Thomas Cort [EMAIL PROTECTED] (oo) |SAVE LARRY| | Gentoo Linux Developer (__))\ +--+ | alpha, amd64, sound ||--|| * | | http://dev.gentoo.org/~tcort pgpDdhlDnWPcS.pgp Description: PGP signature
Re: [gentoo-dev] Heritage
On Sat, 06 May 2006 21:22:56 -0700 Joshua Jackson [EMAIL PROTECTED] wrote: I've noticed a disturbing trend with the website redesign. Larry is disappearing from the site. That is utterly disturbing! I too enjoy Larry the cow, and would like to keep him around and improve his visibility on the site. I think he makes a nice mascot for Gentoo. ~tcort pgpynvUzOJHHX.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Thu, 04 May 2006 11:44:18 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: However, if you have a separate tree per-arch, that tree can be tested and approved for release as a single unit. How big would this tree be? Would it be every package? How will this make the arch teams' life easier and/or the users' experience better? I still fail to see how this will work any differently than what we have today. Today we have ~arch, someone tests the package for stability on an arch system, and marks it stable. The tester is effectively integrating the package into a stable system. Maybe you could explain how the procedure might go with branches for getting a package from just put into the tree to ~arch to arch and what happens with version bumps. ~tcort pgp4rW3LFoaWO.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, 28 Apr 2006 21:42:57 +0200 Bryan Østergaard [EMAIL PROTECTED] wrote: So.. What can we do to improve things? I think that there should be some sort of organized way of connecting potential mentors and potential recruits. There is a very enthusiastic user who has been contributing great work to my overlay, but I cannot find anyone to mentor him (I've e-mailed [EMAIL PROTECTED] as well as [EMAIL PROTECTED] without much success). Maybe we should create a list of developers who are willing to mentor new devs? It would make finding a mentor much easier. ~tcort pgptBnvwxt1RL.pgp Description: PGP signature
Re: [gentoo-dev] QA Proposal v3
* In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. The QA team does not want to override the maintainer's wishes by default, but only wish to do so when the team finds it is in the best interest of users and fellow developers to have the issue addressed as soon as possible. Maybe there should be something more here about dealing with maintainers who are refusing to cooperate. What if the maintainer reverts the changes that the QA team makes? * The QA team will maintain a list of current QA Standards with explanations as to why they are problems, and how to fix the problem. The list is not meant by any means to be a comprehensive document Why isn't this list meant to be comprehensive? I know that there will be QA problems that come up that you haven't thought about yet, but it would be really really nice to have a list with all of the QA problems that could come up and how to fix them. It would help new developers avoid mistakes and it would benefit the QA team by giving them a document that they can direct devs to when there is a problem. ~tcort -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-core] Google Summer of Code and Gentoo
Alec Warner wrote: always portage portage portage. :) Can't you people think of another project to pick on^H^H^H^H^H^H^H^H that needs help? What about a Gentoo stats? ~tcort -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] Google Summer of Code and Gentoo
I had some trouble with my mail client and this got sent to the wrong list. Please ignore it. Sorry for the spam. ~tcort -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Improving Gentoo User Relations
Perhaps we should have a page explaining all of the ways someone can help / contribute to Gentoo. There is no central place (that I know of) for finding out what you can do as a user to make your favorite distribution become even better. The Free Software Foundation has a nice page here: http://www.gnu.org/help/help.html I was thinking we could have something similar to that for Gentoo. The list would include stuff like becoming an AT/HT, becoming a dev, writing documentation, translating docs, linking to Gentoo.org from your blog/website, telling your friends, starting a Gentoo user group, fixing bugs, writing good bug reports, answering questions on the forums/irc/ml, giving away Gentoo CDs, buying t-shirts from the Gentoo store, etc, etc. -tcort -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Sandboxes
Thoughts on ideas on this somewhat more focussed idea? ( or at least I think it's more focused :P ) Will there be restrictions on what can go into these overlays? There are some ebuilds that aren't allowed in the main portage tree. One example is winex-cvs (see app-emulation/winex-cvs/winex-cvs-3000.ebuild for details). Another example... an overlay dev could take an existing ebuild that has RESTRICT=fetch and modify it to fetch the package directly without user interaction. Cheers! -Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Making the developer community more open
A developer could then take these ebuilds, make sure they don't do anything malicious, or break QA, or whatever, and act as the bridge between the portage tree and the users actually working on the ebuild and keeping things up to date and working. The easiest way to handle contrib as far as that big warning is to make it a separate tree. That way, folks who want the flexibility get it, but those who prefer not to risk it, don't have to worry about it. As well, contribs becomes another fertile developer recruitment ground. Why would the packages need a big warning/overlay/eclass if they were checked by a developer to make sure they don't do anything malicious, or break QA, or whatever? There are many user contributed ebuilds that have made their way into portage after being reviewed by devs that don't have any such warnings. I don't think creating a contrib overlay as an official part of Gentoo would be a good idea because making it an official Gentoo project conveys a certain level of quality. If the quality is there, then why not add the ebuilds to portage in the first place? If the quality isn't there, then you will have a lot of unhappy users complaining that an official Gentoo overlay broke their system. Having a non-Gentoo sponsored contrib overlay wouldn't be a good idea either IMO because the contributors wouldn't be contributing to Gentoo, and they wouldn't be interacting as much with the Gentoo developer community. Sure they would learn a lot of the skills required to be a Gentoo developer, but they wouldn't be increasing the value of anything in portage (unless they got a proxy to commit some of their work to portage). Also, there are many overlays out there already. Adding another one won't help with making the developer community more open. Additionally, I don't personally know of a lot of people who actually use third party overlays except to get an ebuild for a particular package they want or to beta test ebuilds. -Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Making the developer community more open
The process for getting unstable ebuilds from bugzilla to portage could even be automated to the extent that when an ebuild is put into bugzilla it gets auto committed to the tree but masked unstable. I don't think that auto committing user submitted ebuilds is safe, even if they are masked. For instance, someone could put something malicious in global scope in the ebuild. Stuff in global scope gets interpreted whenever the ebuild is sourced. More info on scope: http://www.gentoolinux.org/proj/en/devrel/handbook/handbook.xml?part=3chap=1#doc_chap3_sect4 -Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
One of the bigger problems is that we have a huge user community who are keen on contributing, but we have such a high barrier for entry to the developer community. There are the arch tester[1] projects (x86, amd64, ppc, alpha (soon), and maybe others). Those lower the barrier a lot while still requiring some level of knowledge (passing the ebuild quiz). A lot of ATs eventually become devs. Maybe the various AT projects could be advertised more, like the x86 AT team was this week in GWN[2]. [1] http://www.gentoo.org/proj/en/base/x86/arch-testers-faq.xml#whoat [2] http://www.gentoo.org/news/en/gwn/20060320-newsletter.xml -Thomas -- gentoo-dev@gentoo.org mailing list
