Re: [gentoo-dev] Project summaries - Alpha Arch Team
Robert Buchholz wrote: > Note that we have a Summer of Code student this year who is working on a > project to gather both hardware and software statistics from Gentoo > users. If you have any special requirements for your platform, I am > sure he has open ears. No need to invent two wheels at the same time. Yes, I'm all ears :-) Sebastian
[gentoo-dev] Re: Training points for users interested in helping out with ebuild development
Ciaran McCreesh posted 20090506223757.106ca...@snowcone, excerpted below, on Wed, 06 May 2009 22:37:57 +0100: > If a question asks "what's wrong with this code?", you know there's > something wrong and you can spend time researching to find out what it > is. But people need to be able to recognise mistakes even when they're > not looking for them, and to know when something's wrong even if they > haven't been told to find the mistake -- being able to do this requires > having a good immediate knowledge of certain parts of the material. You're right, but that's where the history comes in. If the most recent code/ebuilds has/have been crap, needing lots of corrections, etc, they probably need some more pre-dev mentoring. If it's good quality, well, perhaps they're ready to go into apprenticeship, aka actively mentored new dev. After all, the commits from current devs aren't always perfect, as can be seen by the comments on the commit-feed from time to time. Plus, as I said, with a pre-arrangement, it's possible to do email reasonably close to real-time as well, close enough they'd not have time to look it up unless they had /some/ idea what was going on. But it's also possible to structure those questions a bit differently. Provide several samples of code, some of which have problems, some of which don't. Ask them what they'd change if anything, and why. Throw some in from the commit feed which might have minor stuff, plus a couple of known critically wrong examples. Tell them you'll expect a rough "what's wrong" (for the group of several samples) in say 10/20/whatever minutes, and fixes within an hour/2/whatever. There's no reason that can't be done via email, and throwing in some live commit feed action might make it a bit interesting. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Project summaries - Alpha Arch Team
On Wednesday 06 May 2009, Tobias Klausmann wrote: > I've been toying with the idea of offering something akin to > Debians popularity contest tool. Some people are rather > uncomfortable with data gathering tools that send stuff to some > strangers, so I don't know how well it would work. I list this > idea here, since I have just about no idea what actual alpha > hardware is used with Gentoo out there. Knowing which packages > are actually *used* (instead of just being stabilized for the > heck of it) would be nice. Added benefit of that would be that > users helping with testing would reduce workload. Hi Tobias, a late Happy Birthday from my side first. Note that we have a Summer of Code student this year who is working on a project to gather both hardware and software statistics from Gentoo users. If you have any special requirements for your platform, I am sure he has open ears. No need to invent two wheels at the same time. I'm putting Sebastian in CC directly, if you are looking for the project mentor, that is me. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development
On Wed, 6 May 2009 21:19:00 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > There's a saying that the mark of an expert isn't that he knows > everything, but that he knows where to look to find it when he needs > it. Which is certainly a necessary skill. > In the Gentoo development environment, what's so pressing that a few > hours' delay checking a reference to make sure something's done > correctly is a problem? If it's not a problem "on the job", why make > it a problem "for the interview"? The first problem is that people rarely put in the effort to do the looking up if they can instead get away with a bad solution off the top of their head. A good number of developers just go with the first hack they can think of rather than putting in a bit more work to do things properly. The second is that if people can't think of certain things off the top of their head, they're not going to think of them after detailed study. If a question asks "what's wrong with this code?", you know there's something wrong and you can spend time researching to find out what it is. But people need to be able to recognise mistakes even when they're not looking for them, and to know when something's wrong even if they haven't been told to find the mistake -- being able to do this requires having a good immediate knowledge of certain parts of the material. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Retiring
Peter Faraday Weller posted 1241642515.3120.16.ca...@localhost.localdomain, excerpted below, on Wed, 06 May 2009 21:41:54 +0100: >> Maybe dead projects are cleaned like treecleaners ? > > This actually sounds like a pretty good idea, and one that I might > actually be interested in. > > Someone working within such a project would have to be in close > communication with most/all of the team leads within Gentoo. I feel that > this would be a better solution than asking for (semi-)regular updates > from the teams - having someone to have a chat with the team lead is > much less formal and more relaxed way of ensuring that things are well. > If it seems that the project is having problems staying alive, a call > for help could be put out. If there is no improvement, the project could > be referred to the Gentoo Council to see if it should be > removed/abolished, otherwise... > > Opinions/ideas welpcome! Hmm... and said person/project might do well to be in close contact with the council (maybe even /on/ the council) as well... which fits in rather nicely with the council election season coming up... Talking about which, those considering running for council may wish to pay special attention to the current series of project status updates as well, with an eye toward any actions that may be needed to help out particular projects, and/or revive/close/merge others. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: Training points for users interested in helping out with ebuild development
Mart Raudsepp posted 1241633816.25192.2.ca...@localhost, excerpted below, on Wed, 06 May 2009 21:16:56 +0300: > On Wed, 2009-05-06 at 17:25 +, Duncan wrote: >> Christian Faulhammer posted: >> >> > recruiters do quite long IRC sessions with the applicant. Apart from >> > questions not found in the quiz they want people to elaborate on >> > answers they made. >> >> As others have occasionally noted, the assumption seems to be that >> developers "do" IRC. > > Are you suggesting that recruiters should do long e-mail exchanges with > the applicants instead, having no real time conversations, leading to no > idea about the applicants real knowledge (when there is not much time to > do research after a question is posed), attitude and so on? Noting that mail turnaround can be seconds or minutes, particularly when needed and arranged beforehand... like say an IRC session might be... There's a saying that the mark of an expert isn't that he knows everything, but that he knows where to look to find it when he needs it. I'd suggest that applies here. In the Gentoo development environment, what's so pressing that a few hours' delay checking a reference to make sure something's done correctly is a problem? If it's not a problem "on the job", why make it a problem "for the interview"? Basically, I'd argue there's no vital information obtainable by an IRC interview that can't be obtained in an email exchange. There's certainly /some/ additional information available in the instant format, but I'd argue it isn't vital information given a longer view and a history to work with, and in fact, that said additional information is quite trivial. I'd argue that real knowledge and attitude should easily be apparent by the time of a serious interview, whether it's via IRC or mail, in any case. As the developer's handbook points out, the first step in the process is simply "helping out". What's the bug submission history? Patches? Sunrise and/or project overlay and/or AT record? Whether on the various devel and project lists or IRC channels, what has been the candidate's attitude? Do they take well suggestions from others, yet are able to take their own positions and defend them technically when necessary? Are they able to discern when it's a big deal and when it's not? When they screw up, do they apologize, then work to fix it themselves, asking for help when needed, or are they either slacking off waiting for someone else to fix their mess, or refusing offered and needed (time-wise or technically) help? Are you saying that history, generally of months if not years[1], is easily faked, and that an IRC session is better at detecting such fakes than an email exchange of approximate equal depth would be? If you are, I must say I disagree. I just don't see it. [1] There's a place for shorter term commitments, see the SoC, bugday, simply pitching in with patches or testing, etc, but those aren't Gentoo devhood. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Retiring
On Wednesday 06 May 2009 21:40:51 Roy Bamford wrote: > On 2009.05.06 19:32, Peter Faraday Weller wrote: > > On Wed, 2009-05-06 at 01:45 +0300, Markos Chandras wrote: > > > On Tuesday 05 May 2009 23:45:14 AllenJB wrote: > > > > [..snip..] > > > > > I am sure there are some developers which can offer a great amount > > > > of time to > > > > > help/revibe slacking or dead projects ( e.g. userrel, newsletters > > > > etc ). The > > > > > thing is that leadership on several projects is inactive hence > > > > users > > or devs > > > > > who are willing to help are getting demotivated. It would be really > > > > nice each > > > > > individual project to perform a clean up like: > > [snip] > > > > Looking 'active' is very important to attract new people to > > > > project. > > > > > Is this so hard? > > [snip] > > > The only issue I have with the idea is that projects with dead > > members > > and slacking leaders are unlikely to perform such a task, so you'll > > never get any updates from them, so devs will be demotivated to work > > on > > $project, and thus we enter the vicious cycle again... > > > > welp > > Welp, > > Not so. > > These projects would be delegated upwards to the council and either > scrapped offically, or some recruitment process started to breath new > life into them. > > Maybe dead projects are cleaned like treecleaners ? Indeed. No need to have 100 projects while 80 of them are considered dead. Cleaning them should be another assignment for treecleaners or a new group of developers who are willing to do this. I think treecleaners have enough to do with all the dead packages on the tree :P -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sound/Sunrise] Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Retiring
On Wed, 2009-05-06 at 19:40 +0100, Roy Bamford wrote: [..snip..] > > [snip] > > The only issue I have with the idea is that projects with dead > > members > > and slacking leaders are unlikely to perform such a task, so you'll > > never get any updates from them, so devs will be demotivated to work > > on > > $project, and thus we enter the vicious cycle again... > > > > welp > > > Welp, > > Not so. > > These projects would be delegated upwards to the council and either > scrapped offically, or some recruitment process started to breath new > life into them. > > Maybe dead projects are cleaned like treecleaners ? This actually sounds like a pretty good idea, and one that I might actually be interested in. Someone working within such a project would have to be in close communication with most/all of the team leads within Gentoo. I feel that this would be a better solution than asking for (semi-)regular updates from the teams - having someone to have a chat with the team lead is much less formal and more relaxed way of ensuring that things are well. If it seems that the project is having problems staying alive, a call for help could be put out. If there is no improvement, the project could be referred to the Gentoo Council to see if it should be removed/abolished, otherwise... Opinions/ideas welpcome! welp
Re: [gentoo-dev] Retiring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009.05.06 19:32, Peter Faraday Weller wrote: > On Wed, 2009-05-06 at 01:45 +0300, Markos Chandras wrote: > > On Tuesday 05 May 2009 23:45:14 AllenJB wrote: > [..snip..] > > I am sure there are some developers which can offer a great amount > of time to > > help/revibe slacking or dead projects ( e.g. userrel, newsletters > etc ). The > > thing is that leadership on several projects is inactive hence > users > or devs > > who are willing to help are getting demotivated. It would be really > nice each > > individual project to perform a clean up like: [snip] > > > > Looking 'active' is very important to attract new people to > project. > > > > > Is this so hard? [snip] > The only issue I have with the idea is that projects with dead > members > and slacking leaders are unlikely to perform such a task, so you'll > never get any updates from them, so devs will be demotivated to work > on > $project, and thus we enter the vicious cycle again... > > welp > Welp, Not so. These projects would be delegated upwards to the council and either scrapped offically, or some recruitment process started to breath new life into them. Maybe dead projects are cleaned like treecleaners ? - -- Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoB2bkACgkQTE4/y7nJvau9rgCdEnTDAizW16ACkZYm/Ei0i3gF XhQAoNED5Cgsr+YwxQ3EK34acLCTu1oF =wOxS -END PGP SIGNATURE-
Re: [gentoo-dev] Project summaries
> Future projects: > revdep-rebuild support for mono! > AOT support > Getting Mono tests to not fail in Sandbox. > Reducing the bus-factor. I have too much of this stuff in my head. I > should write docs... Later. Add to your todo: Making mono working on KDE4. It has bindings, but i dont have guts for testing nor making it work ;] signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Retiring
On Wed, 2009-05-06 at 01:45 +0300, Markos Chandras wrote: > On Tuesday 05 May 2009 23:45:14 AllenJB wrote: [..snip..] > I am sure there are some developers which can offer a great amount of time to > help/revibe slacking or dead projects ( e.g. userrel, newsletters etc ). The > thing is that leadership on several projects is inactive hence users or devs > who are willing to help are getting demotivated. It would be really nice each > individual project to perform a clean up like: > > 1) have an internal discussion about its goals and future > 2) Remove dead members and elect a new leader if necessary > 3) Update the page > 4) Publish its status > 5) Assist for help is necessary > > Looking 'active' is very important to attract new people to project. > > Is this so hard? This is a really good idea, and I think that such an operation should be performed (and perhaps even enforced as a yearly or twice-yearly thing). The only issue I have with the idea is that projects with dead members and slacking leaders are unlikely to perform such a task, so you'll never get any updates from them, so devs will be demotivated to work on $project, and thus we enter the vicious cycle again... welp
Re: [gentoo-dev] Project summaries
On Wed, 6 May 2009 08:49:53 +0200 Christian Faulhammer wrote: > Hi, > > any project lead/member can post an answer to this mail for a status > report: Gentoo .NET progress Currently doing good. Nothing much to report. Everything is shiny and well-oiled. SVN ebuilds of trunk and branches were recently committed to the main tree, which will help when people report bugs. Generally trying to maintain as little distance between the main tree and the overlay as possible, so user feedback can be utilized most efficiently. ~arch is really the testing branch for Mono packages, IOW, but I try to fix bugs real quick when they're reported so most of you never notice they were there. Cool new apps which everyone should be using: Tasque for managing your everyday scheduling needs. Monsoon shiny bittorrent client Bareftp easy and accessible ftp client Cool old apps which everyone should be using: Tomboy notetaking application Banshee the best media-player out there Beagle desktop search Gnome-DoLOOK! SHINY! And of course mod_mono, for your ASP.NET needs. What we need: People who care about portable.NET enough to make it great. People who use the ASP.NET features. I can probably debug it for you, but if there's a bug in mod_mono, I won't discover it before you do. Notable successes: Bumping Mono-2.4 before Novell :-) Shaving bugs assigned to dot...@gentoo.org down to a reasonable level. Attracting users to Gentoo through our .NET offering. Future projects: revdep-rebuild support for mono! AOT support Getting Mono tests to not fail in Sandbox. Reducing the bus-factor. I have too much of this stuff in my head. I should write docs... Later.
Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development
On Wed, 2009-05-06 at 17:25 +, Duncan wrote: > Christian Faulhammer posted > 20090506083356.4a561...@gentoo.org, excerpted below, on Wed, 06 May 2009 > 08:33:56 +0200: > > > Apart from growing into your job (that's what happened with me), > > recruiters do quite long IRC sessions with the applicant. Apart from > > questions not found in the quiz they want people to elaborate on answers > > they made. > > As others have occasionally noted, the assumption seems to be that > developers "do" IRC. While it's certainly a useful thing for those that > do it, I believe I've seen a few developers speak up from time to time > that say they do little if any IRC at all, doing their Gentoo comms via > email (including the lists), bugs, and of course commits. Does the way > remain open for such recruits? This subthread would suggest not, that > IRC is now considered not just convenient or useful, but mandatory. I'd > call that a shame, as it could well block otherwise productive potential > devs. Are you suggesting that recruiters should do long e-mail exchanges with the applicants instead, having no real time conversations, leading to no idea about the applicants real knowledge (when there is not much time to do research after a question is posed), attitude and so on? -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project summaries - Alpha Arch Team
Hi! So where are we at with alpha currently? Xorg-1.5 As some of you know, xorg-1.5 abandoned the "classic" way of interfacing with PCI and AGP cards in favor of using libpciaccess. That, in turn expects support from the kernel in the form of /sys/devicesresourceN files. Unfortunately, alpha until recently hat no support for those PCI resources (which is partly due to the way alpha IO space is structured and partly due to a crucial extension not being available on old Alphas (older than EV5). As such, we weren't able to keyword or stabilize Xorg-1.5 until recently, when 2.6.30-rc* saw support finally being added. Naturally, packages depending on >=xorg-1.5 had to be held off, too. The -rc kernels are keyworded ~alpha so people can test. So far, -rc3 and rc4 are looking good, so we will keyword xorg and deps soon (I'm aiming for this weekend) and if all goes well, we will have it stable, soon. Note that this will mean that people with EV4-Alphas will *not* be able to use Xorg-1.5 just now. I feel that those machines are so slow that very few will run X11 anyway, if there are Gentoo installations on those to start with. Glibc/Toolchain --- Glibc has had a bug for ages (regarding ceil() and friends, bug number 264335) which should really be fixed. Upstream is umm.. their usual selves about it. On top, a patch for fdatasync() (bug 264336) is available which upstream... well, you get it. Workload Currently, the alpha arch team consists of me (the nominal lead) and armin76 who helps a lot with getting stable request answered in a timely manner. Also, we're in the process of recruiting mattst88 as an arch tester. He's currently deep in exam-land at university, so the process is on hold for now. Users/Community --- Aside from those on the team and one or two other devs, I've had little to no direct feedback from Gentoo alpha users. I try to write about Alpha regularly on my blog (available on the planet) and I'm easily reachable as Blackb|rd on Freenode (#gentoo-alpha, naturally). I've been toying with the idea of offering something akin to Debians popularity contest tool. Some people are rather uncomfortable with data gathering tools that send stuff to some strangers, so I don't know how well it would work. I list this idea here, since I have just about no idea what actual alpha hardware is used with Gentoo out there. Knowing which packages are actually *used* (instead of just being stabilized for the heck of it) would be nice. Added benefit of that would be that users helping with testing would reduce workload. In essence: we're busy and I'd love to get more feedback what people (both users and devs) think we could do better, or more/less of. Regards, Tobias, who turned 42 in octal today -- The only problem with troubleshooting is that sometimes, trouble shoots back.
[gentoo-dev] Re: Training points for users interested in helping out with ebuild development
Christian Faulhammer posted 20090506083356.4a561...@gentoo.org, excerpted below, on Wed, 06 May 2009 08:33:56 +0200: > Apart from growing into your job (that's what happened with me), > recruiters do quite long IRC sessions with the applicant. Apart from > questions not found in the quiz they want people to elaborate on answers > they made. As others have occasionally noted, the assumption seems to be that developers "do" IRC. While it's certainly a useful thing for those that do it, I believe I've seen a few developers speak up from time to time that say they do little if any IRC at all, doing their Gentoo comms via email (including the lists), bugs, and of course commits. Does the way remain open for such recruits? This subthread would suggest not, that IRC is now considered not just convenient or useful, but mandatory. I'd call that a shame, as it could well block otherwise productive potential devs. If it's not assumed mandatory, perhaps a bit more care should be taken to avoid creating that impression, thereby discouraging potentially valuable recruits. Maybe the world has moved on and email, etc, is now as impractical for development as snail mail. If so, I suppose it has left us old fogies behind, but somehow, I don't believe it's gone /that/ far yet, nor can I believe it will in the intermediate term future, at least. If it were, after all, this list should be near deserted. It's obviously not. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] yet another modprobe change (.conf)
looks like modprobe is changing yet again such that all files in /etc/modprobe.d/ have to end in ".conf". feel free to fix your ebuilds (a simple rename), but i'll do it whenever i notice. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] An Introduction to Gentoo Prefix
On Tuesday 05 May 2009 21:18:14 Fabian Groffen wrote: > While some of you may have heard of it, we -- the Prefix team -- have > the impression that for most developers the Gentoo Prefix project is in > general an unknown, hidden and vague project, that primarily generates a > lot of commits. Therefore, we have decided to try and explain what > Gentoo Prefix is, and why we Prefix devs are so passionately about it. >[..] o_O Amazing work guys. Thank you for your time and effort :) -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sunrise/Sound] Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in mail-mta/courier: ChangeLog courier-0.61.2.ebuild
On Monday 04 May 2009 09:43:04 Thomas Anderson wrote: > > filter-flags '-fomit-frame-pointer' > > filter-flags in global scope? You should put that in > src_unpack/src_prepare. it shouldnt exist at all -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: x11-misc/xkbdata
# Rémi Cardona (05 May 2009) # Masked for removal in 30 days, maybe less # has been blocked by xkeyboard-config for _years_ # see bug #196650 x11-misc/xkbdata The future is now, rejoice! Cheers, Rémi
Re: Training points for users interested in helping out with ebuild development (was: Re: [gentoo-dev] Retiring)
Le mardi 05 mai 2009 à 01:59 +0200, Olivier Huber a écrit : > Hi, > [...] > , I propose to add a bug-with-patch alias or > something like that. > > Cheers, > You mean something like the "Inclusion" keyword in bugzilla ? Or maybe a separate keyword that would indicate unreviewed patches. It's sad we don't have the ability to set per attachment status other than obsolete in our bugzie but we can still figure ways to work without it. -- Gilles Dartiguelongue Gentoo
Re: [gentoo-dev] Gentoo Council Reminder for May 14
Updated meeting agenda can be found here: http://dev.gentoo.org/~dev-zero/council/meeting-agenda-20090514.txt Changes: - Added the issue of removing old eclasses to the list. Cheers, Tiziano Am Sonntag, den 03.05.2009, 23:47 +0200 schrieb Tiziano Müller: > This is your friendly reminder! Same bat time (typically the 2nd & 4th > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ > irc.freenode.net) ! > > If you have something you'd wish for us to chat about, maybe even vote > on, let us know! Simply reply to this e-mail for the whole Gentoo dev > list to see. > > For more info on the Gentoo Council, feel free to browse our homepage: > http://www.gentoo.org/proj/en/council/ > > Following is the preliminary meeting agenda. It consists of two EAPI-3 > related topics as well as two almost rusty topics where we should > finally make a decision to be able to move on. > > > EAPI 3: Short discussion of the progress > > > zmedico will provide an update on the progress of the implementation. > Short discussion of problems and implementation decisions if needed. > > > EAPI 3: PMS approval > > > Goal: Approve EAPI-3 extension of the PMS. Any open questions should be > on the mailing list before the meeting. > > > GLEP 54: Dealing with live SCM packages > --- > > Goal: Since no consensus is reached or progress has been made voting > seems appropriate. > > > Handling EAPI versioning in a forwards-compatible way > - > > Goal: Since no consensus is reached vote on the implementation for the > problem solved in GLEP 55. > > > Handling static libraries more flexibly > --- > > Goal: Decision-making by consensus. > Should we move forward with USE=static-libs to control > building of static libraries? Should/Must this be an EAPI feature? > > > Define EAPI development/deployment cycles > - > > Goal: Start discussion about EAPI development/deployment. For example: > Collect problems of eapi introductions in the past, like reverting > ebuilds to former eapis to get them stable, not waiting for the pm > support a certain eapi before requesting stable keywords for ebuilds > using the new eapi, Collect problems of EAPI development like > feature-freeze, late feature removals (due to implementation problems). > Eventually develop a lightweight EAPI development model. > > > Cheers, > Tiziano -- Tiziano Müller Gentoo Linux Developer, Council Member Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development
Petteri Räty a écrit : Currently we really don't need to fail that many people as those who end up at that point in the process almost always have good enough skills as they have contributed via overlays for quite a while. Ditto on that. Most recruits I've been actively watching these past few months (Ford_prefect, nirbheek and now mrpouet) have all been "trained" that way : - they send us patches for ebuilds - we tell them how they are wrong and they fix 'em - after a while, they get access to the overlay - we still whack them with the cluebat when they break stuff But the whole overlay process is very positive because it's hands-on experience. The ebuild quiz is usually a very good time for them to reflect on all the work they did and they understand more why we had to whack them a few times. Things make much more sense for them. All in all, I would say overlays + the ebuild quiz make for very good recruits. I have yet to be disappointed by this recruitment process. Cheers, Rémi
