Re: [gentoo-dev] Re: udev - mdev
Walter Dnes waltd...@waltdnes.org writes: On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao r...@gentoo.org wrote: mdev would need to switch to the netlink hotplug interface. I think that's quite unlikely, since mdev is not a daemon. Perhaps by the time /proc/sys/kernel/hotplug is gone, mdev advocates will have settled on some early udev fork. [1] Do you realize this would effectively kill linux in the embedded device area? Udev, even without the systemd code, is simply to large for embedded devices. But surely most embedded devices do not need hotplug functionality, they have a known, fixed, set of devices. So should static nodes in /dev/ not be sufficient?
[gentoo-dev] Packages up for grabs: app-editors/xemacs and app-xemacs/*
If you are looking to pick up ~130 packages in one quick move, then wait no longer and add yourself to the xemacs herd! You'll get app-editors/xemacs and all the packages in app-xemacs/* You will inherit a few open bugs, but nothing high priority. XEmacs editor and package release happen quite infrequently and we are fully up-to-date right now. After 21 years I figured it was time for some change, so I've now started to use GNU Emacs, and thus I no longer have an interest in maintaining XEmacs. My main reason for switching is that extensions are all written for GNU Emacs these days and with XEmacs pretty much stagnant its compatibility layer is no longer up to dealing with these. If you are using xemacs and want to maintain these, please let me know. I have some scripts to automate updates that aren't available elsewhere. I won't drop the packages to maintainer-needed and I'll monitor the xemacs alias for now to tell people this is no longer maintained. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: udev - mdev
On Sat, Jul 14, 2012 at 12:35 AM, Sylvain Alain d2racing...@gmail.com wrote:
Hi all, about the Mdev stuff, Slashbeast from Funtoo.org started that
project a while ago.
https://github.com/slashbeast/mdev-like-a-boss
I think that it's actually working pretty good on his box.
Some Coredevs from Funtoo are actually running with that stuff.
I don't think anybody has ever suggested that it's not possible to run
mdev instead of udev: as Walter has proved, it is indeed possible.
The question Olivier and William are making is (if I understand
correctly) if you don't need the features of udev, then why not use
only devtmpfs. I think everyone agrees that mdev doesn't have (and
probably never will nor want) all the features that udev has.
Seeing all the trouble some people have taken to make their systems
work with mdev just to avoid having to use an initramfs, I really
wonder how much effort it would have taken the simple task of learning
one step more when updating kernels and switch to use an initramfs.
Then again, everyone is entitled to work in the features (or
anti-features) they want. It is FLOSS after all.
Just the 0.02 ${CURRENCY} of a happy udev/systemd user (I'm really
happy the merged the two project trees).
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
[gentoo-dev] Recruitment process is moving back to quizzes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Gentoo Community, If you are not a recruit, mentor, or wannabe mentor you may stop reading now. We (recruiters) decided to revert back to the quizzes for the recruitment process. The web application does not work as we expected. There are a few open bugs, nobody is working on improving this application and it's been quite a bit of pain to use it during the (long) recruitment process. We understand that quizzes is not an ideal way to hire people either, but they worked ok for all these years and it is the only alternative we have at the moment. Hopefully, we will manage to improve the web application on a future GSOC project. If you have already submitted your answers on the web application, that is fine. However, I would strongly advise future recruits to complete the quizzes instead. If you don't, we will ask you to do so when we pick you up. Obviously, this will lead to extra delay and frustration. This does not apply to Arch Testers. The recruitment process for Arch Testers will still be through the web application - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJQATyUAAoJEPqDWhW0r/LChrEP/jWD8lcuPt9hldcD1ckMk5JT 1ixaZExOUj061Mm4moHAXhNE4AGzMnqeKv0tJ1mZDFoj1ad5xNdKlWa4Vw70LV+R 2g5NMV0CZW8yjJsBpBhimt5ND9qEY4oOfFoOBJi27JbbmgRIteq0RQI1hUXDvs7h Y0/z0UofiTvPqUpifJldjZ5rkl5NyIKobGz9CjnDDq4RpuhvOtZt3hRtJ/X/TtZ1 w1PYfYt3+i3IQ8ne94max9h4vVJjLuTSNiKAWrKi9Fc4ZHjMbBV9GYU4NTYkpD+b lbAmJSsnog+mFGG4gtXrszxZ5NG5QQ/70QzqneVp68arob1LybBqzlYhaw8OycKp +689JwgZFiD8/c/q/8j52Dr6z8eeYyjkFqKeaW6zI+P+milMa/J+8YfChwcdKQqQ 8Ui+pyyf9pPtd6E968PgxJYuFngLlaFLDRkPGTRRoATGkrW5FF7kkSdhjXeHSt0j tUCgPZCYaEabVJRs5A3kQx/JDb8CwvoAODtljvl5VJcFql62Zx59fwkK3QPGxBuH wdQgnH29F94XLHHbLkjTcdAwNndahLTZQhqr2rVPMhjKnU4VLdZTAY292tDy5vDw luD/KbJPjamUnlpr1B2uUSO76wIDFnOBjKtz0FaeO1rZDBctjdbiCDKgzdsPaEui r+Ar+nTCVZ9xoTbk+oIO =hOTY -END PGP SIGNATURE-
[gentoo-dev] Last rites: app-laptop/omnibook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (14 Jul 2012) # Does not work with recent kernels (#339758) # Does not build (#426542) # Removal in 30 days app-laptop/omnibook - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJQAT/kAAoJEPqDWhW0r/LCkxEP/2JkpjQPIpHU7t+bH6J60/yl N8mS7AEWMG796dn1Rwr41PyR0GwAukNCkObV2WKq6epczoeR0KWzRrG5M2iXAGHP dZT5GpyMlqqQNby/vZKvMMArG6QfAbE/wL54TFJdUVAlub/G3Kq1W1jWDFbF2TCf OaYZhxPq7RcNd2sVibjjvc8de1voeS1SQifILqZ4dLsAY3J+wk3xML3GUdQ4JwAV q/h39kuoM/ouYgPIJT4lVLP6Fe565/ybOhFhluJ9jpbCQZU0EKuMipUuVqPUdaFZ j+30bte8gl2rKAJbAWJSHU7RxvocHQy636RjEuqer+zhUl9eYrQhstudm/iM+iIx 1j80WDfMUM1UMsHQD2Ow5yH5gZjgG5/T8qRR7+P32Nj/0QcEhac6iMLLWVjItp1Y 4Nne/j21eucdnrtj0PN/MdXwNYA+WwboOMxR5Z4Kxu/jdFf/dEFrEybb4BCgqC4o cIHKCPwzL457s7tONQ6GA66w9y14/y9tWWsVtbNQcnI0N8LEmihTn2Vmuc3/cNKr zh63YmXgwqOLKa9s7zG2Xol72l+1xvVdBz2hpDlNIYnvaq6VSQNAQbZoGoc11muT uHSAf9HL0hEpdNBEJfbQYOJBBL0sJMd9f3zAzdVQK+ttddSznH21bb4gfPdFAVWT Z9vPnGqRixlFAh93vHWR =myO7 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: using array variables in qt4-r2.eclass
On Fri, Jul 13, 2012 at 3:50 PM, Alexis Ballier aball...@gentoo.org wrote:
On Fri, 13 Jul 2012 15:26:58 +0200
Davide Pesavento p...@gentoo.org wrote:
[...]
+ # backward compatibility for non-array variables
+ if [[ -n ${DOCS} ]] [[ $(declare -p DOCS 2/dev/null
21) != declare -a* ]]; then
+ dodoc ${DOCS} || die dodoc failed
+ fi
+ if [[ -n ${HTML_DOCS} ]] [[ $(declare -p HTML_DOCS
2/dev/null 21) != declare -a* ]]; then
+ dohtml -r ${HTML_DOCS} || die dohtml failed
+ fi
}
maybe issue an eqawarn in that case telling people to convert to
arrays; some time later make this an ewarn telling non-array support
will be removed and again later make this a die :)
(if you take that route i would expect you to start converting
packages to use arrays)
We have no intention of deprecating non-array variables in qt4-r2
eclass.
why ? having two codepaths for the same thing, one being inferior,
sounds like a good reason to deprecate the inferior one :)
A.
Maintaining these two codepaths has practically zero cost, while
forcing every ebuild using qt4-r2 to switch to arrays would waste
developers' time which is better spent elsewhere.
Furthermore, the non-array variant is not necessarily inferior,
because it allows you to use bash globbing, brace expansion, etc...
Thanks,
Pesa
[gentoo-dev] Re: udev - mdev
Graham Murray posted on Sat, 14 Jul 2012 07:13:56 +0100 as excerpted: Walter Dnes waltd...@waltdnes.org writes: Do you realize this would effectively kill linux in the embedded device area? Udev, even without the systemd code, is simply to large for embedded devices. But surely most embedded devices do not need hotplug functionality, they have a known, fixed, set of devices. So should static nodes in /dev/ not be sufficient? Well, there's (kernel-side) devfs as well, as others have mentioned. Meanwhile, embedded can mean different things to different users of the term. I expect few would argue that onboard boot devices on embedded are likely to change, but there's a lot of (arguably embedded) devices with USB-host support these days, and some form of dynamic device-nodes, even if it's just devfs, can make that much more flexible and easier to deal with. What's interesting is the potential on such devices for USB-based storage, displays, sound, net and HID, blurring the definition of embedded even further, altho one would hope nobody tries to connect all of those up to the same host USB port (via hub) at the same time as I can just imagine the bandwidth management headaches trying to do so, thus implying 2-3 USB host-ports, minimum. -- 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] RFC: using array variables in qt4-r2.eclass
On Sat, 14 Jul 2012 12:29:59 +0200
Davide Pesavento p...@gentoo.org wrote:
On Fri, Jul 13, 2012 at 3:50 PM, Alexis Ballier aball...@gentoo.org
wrote:
On Fri, 13 Jul 2012 15:26:58 +0200
Davide Pesavento p...@gentoo.org wrote:
[...]
+ # backward compatibility for non-array variables
+ if [[ -n ${DOCS} ]] [[ $(declare -p DOCS 2/dev/null
21) != declare -a* ]]; then
+ dodoc ${DOCS} || die dodoc failed
+ fi
+ if [[ -n ${HTML_DOCS} ]] [[ $(declare -p HTML_DOCS
2/dev/null 21) != declare -a* ]]; then
+ dohtml -r ${HTML_DOCS} || die dohtml failed
+ fi
}
maybe issue an eqawarn in that case telling people to convert to
arrays; some time later make this an ewarn telling non-array
support will be removed and again later make this a die :)
(if you take that route i would expect you to start converting
packages to use arrays)
We have no intention of deprecating non-array variables in qt4-r2
eclass.
why ? having two codepaths for the same thing, one being inferior,
sounds like a good reason to deprecate the inferior one :)
A.
Maintaining these two codepaths has practically zero cost, while
forcing every ebuild using qt4-r2 to switch to arrays would waste
developers' time which is better spent elsewhere.
Furthermore, the non-array variant is not necessarily inferior,
because it allows you to use bash globbing, brace expansion, etc...
And arrays stopped to allow that overnight?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] sys-auth/nss-ldapd is looking for a maintainer
sys-auth/nss-ldapd is looking for a maintainer. This is the preferred NSS LDAP by RHEL6. I just haven't been using it and haven't been keeping up with releases. I'm only aware of two bugs: https://bugs.gentoo.org/show_bug.cgi?id=287727 https://bugs.gentoo.org/show_bug.cgi?id=234555 One is asking for a bump and one is asking for some USE flag fixes. -- Doug Goldstein
Re: [gentoo-dev] Recruitment process is moving back to quizzes
Hi, Markos Chandras wrote: We (recruiters) decided to revert back to the quizzes for the recruitment process. The web application does not work as we expected. I've been considering recruitment for many years and I made my first effort to prepare for recruitment about two years ago, but I haven't finished the quizzes yet. I'm very happy to learn that a web application did not work out (sans the wasted effort of course). I don't know what a web app could bring that the quiz format can't. understand that quizzes is not an ideal way to hire people either, but they worked ok for all these years I don't know.. Subjectively I don't think they work ok at all, since I still haven't finished them even after many years. But it's totally possible that they actually *do* work ok, and that I really absolutely *must* know everything they ask about before starting recruitment. Not sure. and it is the only alternative we have at the moment. Thinking outside of the quiz^Wbox and getting to know people is a good alternative. It takes time too of course, but no quiz or web app can replace it. //Peter
Re: [gentoo-dev] Re: udev - mdev
Canek Peláez Valdés wrote: Seeing all the trouble some people have taken to make their systems work with mdev just to avoid having to use an initramfs, I really wonder how much effort it would have taken the simple task of learning one step more when updating kernels and switch to use an initramfs. I think udev, systemd, and initramfs are orthogonal concepts. FWIW I've built more or less deeply embedded Linux systems with Gentoo and without, for years. I stopped using init scripts long before I started using Gentoo in 2004. systemd is in most regards a significant improvement over everything that was previously available. The few regards where it isn't are outweighed fairly easily by the value of same process management both on desktop Linux and embedded Linux. On deeply embedded systems with say 2 or 4 Mbyte flash I might choose something other than systemd however. As was pointed out, such a system may also not need to be very dynamic, so losing udev is not neccessarily a problem. If they do need to be dynamic, then will have to make some room for udev as well. Anyone who tries to argue that initramfs would be good for me to have on my systems should brace themselves for a mouthful of foul swedish language coming their way! ;) //Peter
Re: [gentoo-dev] Re: udev - mdev
On Sat, Jul 14, 2012 at 4:02 PM, Peter Stuge pe...@stuge.se wrote: [snip] Anyone who tries to argue that initramfs would be good for me to have on my systems should brace themselves for a mouthful of foul swedish language coming their way! ;) I don't think anyone has argued it's good for anyone. An initramfs it's just now the only supported way (by udev and systemd) to have a separated /usr partition. If your /usr is in the same partition as /, then udev and systemd supports your configuration *without* an initramfs. I have it like that in a couple of servers, and actually I only use an initramfs in my laptop and desktop because I like plymouth. If your /usr is in a separate partition as /, and you don't want to use an initramfs, you're free to do so. Only then udev (and systemd, if you use it) will not support your configuration, and any problem you encounter will be ignored in their mailing lists/bugzillas. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: udev - mdev
Canek Peláez Valdés wrote: An initramfs it's just now the only supported way (by udev and systemd) to have a separated /usr partition. Yes sure. I considered separate partitions in the 90s, let's just say that I don't see the problem that many on the internet cry about. Using multiple filesystems in a system allows doing very nice things, but /usr /var /whatever is waay too clumsy, to do the nice things there needs to be more cleverness, which we're not neccessarily ready for just yet. //Peter
Re: [gentoo-dev] sys-auth/nss-ldapd is looking for a maintainer
On 07/14/2012 02:49 PM, Doug Goldstein wrote: sys-auth/nss-ldapd is looking for a maintainer. This is the preferred NSS LDAP by RHEL6. I just haven't been using it and haven't been keeping up with releases. I'm only aware of two bugs: https://bugs.gentoo.org/show_bug.cgi?id=287727 https://bugs.gentoo.org/show_bug.cgi?id=234555 One is asking for a bump and one is asking for some USE flag fixes. I'll take it, starting with the bump and hopefully getting upstream to accept a --enabled/disable for kerberos. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: udev - mdev
Canek Peláez Valdés posted on Sat, 14 Jul 2012 16:29:19 -0500 as excerpted: If your /usr is in the same partition as /, then udev and systemd supports your configuration *without* an initramfs. I have it like that in a couple of servers, and actually I only use an initramfs in my laptop and desktop because I like plymouth. If your /usr is in a separate partition as /, and you don't want to use an initramfs, you're free to do so. Only then udev (and systemd, if you use it) will not support your configuration, and any problem you encounter will be ignored in their mailing lists/bugzillas. BTW, any gentooish documentation out there on rootfs as tmpfs, with /etc and the like mounted on top of it, operationally ro, rw remounted for updates? That's obviously going to take an initr*, which I've never really understood to the point I'm comfortable with my ability to recover from problems so I've not run one since my Mandrake era, but that's a status that can change, and what with the /usr move and some computer problems I just finished dealing with, I've been thinking about the possibility lately. So if there's some good docs on the topic someone can point me at, I'd be grateful. =:^) I'm aware of the issues with /etc/mtab and have googled a bit on the workarounds, but that looks like a decent amount of work, and if I'm going to do that, I might as well invest the time and do it right, initr*, full tmpfs rootfs with everything non-volatile mounted on top, the whole shebang! -- 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] Re: udev - mdev
On Sat, Jul 14, 2012 at 7:38 PM, Duncan 1i5t5.dun...@cox.net wrote: BTW, any gentooish documentation out there on rootfs as tmpfs, with /etc and the like mounted on top of it, operationally ro, rw remounted for updates? That's obviously going to take an initr*, which I've never really understood to the point I'm comfortable with my ability to recover from problems so I've not run one since my Mandrake era, but that's a status that can change, and what with the /usr move and some computer problems I just finished dealing with, I've been thinking about the possibility lately. So if there's some good docs on the topic someone can point me at, I'd be grateful. =:^) I doubt anybody has tried it, so you'll have to experiment. I imagine you could do it with a dracut module. There is already a module that will parse a pre-boot fstab (/etc/fstab.sys). The trick is that you need to create the root filesystem and the mountpoints within it first. The trick will be how dracut handles not specifying a root filesystem. However, if anything I think the future trend will be towards having everything back on the root filesystem, since with btrfs you can set quotas on subvolumes and have a lot more flexibility in general, which you start to lose if you chop up your disks. However, I guess you could still have one big btrfs filesystem and mount individual subvolumes out of it onto your root. I'm not really sure what that gets you. Having the root itself be a subvolume does have benefits, since you can then snapshot it and easily boot back off a snapshot if something goes wrong. Rich
[gentoo-dev] Re: udev - mdev
Rich Freeman posted on Sat, 14 Jul 2012 19:57:41 -0400 as excerpted: On Sat, Jul 14, 2012 at 7:38 PM, Duncan 1i5t5.dun...@cox.net wrote: BTW, any gentooish documentation out there on rootfs as tmpfs, with /etc and the like mounted on top of it, operationally ro, rw remounted for updates? That's obviously going to take an initr*, which I've never really understood to the point I'm comfortable with my ability to recover from problems so I've not run one since my Mandrake era, but that's a status that can change, and what with the /usr move and some computer problems I just finished dealing with, I've been thinking about the possibility lately. So if there's some good docs on the topic someone can point me at, I'd be grateful. =:^) I doubt anybody has tried it, so you'll have to experiment. Anybody /anybody/, or anybody on gentoo? FWIW, there are people running it in general (IIRC much of the discussion was on Debian, some on Fedora/RH), but I didn't see anything out there written from a gentoo perspective. Gentoo-based docs/perspective does help, as one isn't constantly having to translate binary-based assumptions into gentooese, but there's enough out there in general that a suitably determined/ motivated person at the usual experienced gentoo user level should be able to do it, without having to be an /extreme/ wizard. But so far I've not been /that/ motivated, and if there was gentoo docs available, it would bring the barriers down far enough that I likely /would/ then have the (now lower) required motivation/determination. Just looking for that shortcut, is all. =:^) I imagine you could do it with a dracut module. There is already a module that will parse a pre-boot fstab (/etc/fstab.sys). The trick is that you need to create the root filesystem and the mountpoints within it first. The trick will be how dracut handles not specifying a root filesystem. While I do know dracut is an initr* helper, you just made me quite aware of just how much research I'd have to do on the topic. =:^\ I wasn't aware dracut even /had/ modules, while you're referring to them with the ease of familiarity... However, if anything I think the future trend will be towards having everything back on the root filesystem, since with btrfs you can set quotas on subvolumes and have a lot more flexibility in general, which you start to lose if you chop up your disks. However, I guess you could still have one big btrfs filesystem and mount individual subvolumes out of it onto your root. I'm not really sure what that gets you. Having the root itself be a subvolume does have benefits, since you can then snapshot it and easily boot back off a snapshot if something goes wrong. The big problem with btrfs subvolumes from my perspective is that they're still all on a single primary filesystem, and if that filesystem develops problems... all your eggs/data are in one big basket, good luck if the bottom drops out of it! One lesson I've had drilled into my head repeatedly over now two decades of computer experience... don't put all your data in one basket! It's a personal policy that's saved my @$$ more than a few times over the years. Even with raid, when I first setup md/raid, I set it up as a nice big (partitioned) raid, with a second (similarly partitioned) raid as a backup. With triple-digits gigs of data (this was pre-terabyte-drive era), a system-crash related re-add and resync would take /hours/. So when I rebuilt the setup, I created over a dozen (including working and backup copies of many of them) individual raids, each in its own set of partitions on the physical devices, some raids of which were further partitioned, some not, but only the media raid (and its backup) were anything like 100 gigs, and with many of even the working raids (plus all backups) not even activated for normal operation unless I was actually working on whatever data was on that raid, and in general even most of the the assembled raids with rw mounting not actively writing at the time of a crash, re-add and resync tended to be seconds or minutes, not hours. So I'm about as strong a partitioning-policy advocate as you'll get, tho I do keep everything that the pm installs, along with the installation database (so /etc, /usr, /var, but not for instance /var/log or /usr/src, which are mountpoints), on the same (currently) rootfs of 8-ish gigs, with a backup root partition (actually two of them now) that I can point the kernel at from grub, if the working rootfs breaks for some reason. So the separate /usr/ thing hasn't affected me at all, because /usr/ is on rootfs. But as I said I had some computer hardware issues recently, and they made me aware of just how nice it'd be to have that rootfs mounted read-only for normal operation -- no fsck/log-replay needed on read-only-at-time-of- crash mounts! =:^) So I'm pondering just how hard it would be... -- Duncan - List replies
Re: [gentoo-dev] sys-auth/nss-ldapd is looking for a maintainer
On Sat, Jul 14, 2012 at 6:25 PM, Matthew Thode prometheanf...@gentoo.org wrote: On 07/14/2012 02:49 PM, Doug Goldstein wrote: sys-auth/nss-ldapd is looking for a maintainer. This is the preferred NSS LDAP by RHEL6. I just haven't been using it and haven't been keeping up with releases. I'm only aware of two bugs: https://bugs.gentoo.org/show_bug.cgi?id=287727 https://bugs.gentoo.org/show_bug.cgi?id=234555 One is asking for a bump and one is asking for some USE flag fixes. I'll take it, starting with the bump and hopefully getting upstream to accept a --enabled/disable for kerberos. Thanks a bunch Matt. -- Doug Goldstein
Re: [gentoo-dev] sys-auth/nss-ldapd is looking for a maintainer
On 07/14/2012 09:17 PM, Doug Goldstein wrote: On Sat, Jul 14, 2012 at 6:25 PM, Matthew Thode prometheanf...@gentoo.org wrote: On 07/14/2012 02:49 PM, Doug Goldstein wrote: sys-auth/nss-ldapd is looking for a maintainer. This is the preferred NSS LDAP by RHEL6. I just haven't been using it and haven't been keeping up with releases. I'm only aware of two bugs: https://bugs.gentoo.org/show_bug.cgi?id=287727 https://bugs.gentoo.org/show_bug.cgi?id=234555 One is asking for a bump and one is asking for some USE flag fixes. I'll take it, starting with the bump and hopefully getting upstream to accept a --enabled/disable for kerberos. Thanks a bunch Matt. also getting proper selinux support for it :D -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Recruitment process is moving back to quizzes
On 15 July 2012 04:46, Peter Stuge pe...@stuge.se wrote: Markos Chandras wrote: understand that quizzes is not an ideal way to hire people either, but they worked ok for all these years I don't know.. Subjectively I don't think they work ok at all, since I still haven't finished them even after many years. I agree that they don't work ok -- it only seems that way because people are still joining us. The first time I did the quizzes, it took me 9 months. After having been away for a couple of years, I recently returned as Gentoo dev, and the second time I did the quizzes it took me 3 months. I've seen others take a long time doing them as well. Davide (pesa), one of our most valued contributors in the Qt team, took close to two years I think. I think this way we lose much valuable developer time. These people could have had commit access and done much valuable work so much earlier, if there wasn't this obstacle of the quizzes... We should think about what kind of people we want to attract as future Gentoo contributors, and what are the best ways of introducing them to the tasks they would need to perform, and the knowledge they would need to have. I'm happy to see that some effort was made, and we now know that the web app is not working. What other ways can we think of that might improve the recruitment process? But it's totally possible that they actually *do* work ok, and that I really absolutely *must* know everything they ask about before starting recruitment. Not sure. The topics touched in the quizzes are things that a Gentoo developer should know. I just don't think the way they work is conducive to a good learning experience for most people. and it is the only alternative we have at the moment. Thinking outside of the quiz^Wbox and getting to know people is a good alternative. It takes time too of course, but no quiz or web app can replace it. What I noticed in my own experience as lead of our Qt team, is that getting people started on the real work, being part of the developer community and process, is a good way to introduce them to how we do things in Gentoo. The Qt team has its official overlay, and it is easy for us to give new contributors access to it. That way they can learn to write ebuilds and eclasses, and how to improve them, commit them, and get used to a good workflow. Hanging out in the IRC channel and taking part in discussions is an invaluable part of this as well. I'm sure a lot of mentors do things in similar ways. And maybe others have things to add to this. We could have a portal page (e.g. on the wiki) with links to all the relevant documentation for new developers (dev handbook, devmanual, foundation info, gleps, etc) that they should have knowledge of. Then recruits can read these while they are doing work with their mentor, in an overlay (either an official team overlay, or betagarden). We could also develop a collection of tasks that a mentor can choose from to give their recruits to do. Hopefully this way we can train people in a more organic way. Then when the mentor deems a recruit ready, they could have an interview with one of the recruiters, and get commit access to the official tree as usual. Anyway, these are some of my ideas. What do you think? -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
