Re: [gentoo-dev] ruby_targets_ruby20 missing
On Sun, Sep 1, 2013 at 7:43 PM, Rick "Zero_Chaos" Farina wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > >> ozzie src # emerge -vp ruby >> >> >> These are the packages that would be merged, in reverse order: >> >> Calculating dependencies... done! >> >> emerge: there are no ebuilds built with USE flags to satisfy >> ">=dev-ruby/rake-0.9.6[ruby_targets_ruby20]". !!! One of the >> following packages is required to complete your request: - >> dev-ruby/rake-0.9.6::gentoo (Change USE: +ruby_targets_ruby20) >> (dependency required by "dev-lang/ruby-2.0.0_p247-r1" [ebuild]) >> (dependency required by "ruby" [argument]) > > > So, um, why exactly is ruby 2.0.0 stable if I can't even update my > system anymore? I'm having the same issue across 3 systems so I'm > assuming it's not a bad sync. > > Whatever the current "solution" to not adding ruby20 to RUBY_TARGETS > is, it's not work for me. > > - -Zero My best guess is that there is some package in your world depgraph which is pulling in dev-lang/ruby via an unbounded (unslotted) dependency. This causes portage to try to upgrade to ruby-2.0 automatically, which fails when you don't have ruby20 in RUBY_TARGETS. equery depends seems to show that there are quite a few packages with such dependencies in the tree. Ruby team: Is there something we are missing that would somehow avoid this problem? It is bound to generate some confusion among users.
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
> "TW" == Tom Wijsman writes: TW> Also, please just call it git-3.eclass as it is a major change; any TW> other form of naming will introduce confusion (eg. -r1 < -2), also we TW> probably shouldn't change git-2.eclass as even when masked it doesn't TW> seem like a good thing to break its current API and documentation as TW> well as what actually works in the Portage tree. +1 on all of that. git-3 is a better name than using -r1. And leave git-2 there for at /least/ a year. There are a LOT of out of tree git-2 users. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-09-01 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-09-01 23h59 UTC. Removals: net-p2p/mutella 2013-08-31 15:10:09 pacho dev-cpp/IceE2013-08-31 15:11:16 pacho dev-perl/gnome2-gconf 2013-08-31 15:12:38 pacho media-libs/openinventor 2013-08-31 15:14:01 pacho dev-cpp/libebt 2013-08-31 15:15:16 pacho sys-kernel/ksymoops 2013-08-31 15:16:13 pacho net-p2p/bitstormlite2013-08-31 15:16:48 pacho media-sound/alsa-headers2013-08-31 15:17:59 pacho net-analyzer/openvas-client 2013-08-31 15:18:46 pacho net-analyzer/openvas-libnasl2013-08-31 15:19:07 pacho net-analyzer/openvas-plugins2013-08-31 15:19:27 pacho net-analyzer/openvas-server 2013-08-31 15:19:41 pacho Additions: dev-haskell/network-conduit 2013-08-26 03:43:57 qnikst dev-haskell/iproute 2013-08-26 03:45:15 qnikst dev-haskell/dns 2013-08-26 03:46:25 qnikst dev-haskell/data-endian 2013-08-26 03:48:58 qnikst dev-haskell/network-info2013-08-26 03:50:54 qnikst dev-haskell/regex-tdfa 2013-08-26 03:52:11 qnikst dev-haskell/cipher-aes 2013-08-26 03:55:03 qnikst dev-haskell/crypto-random-api 2013-08-26 04:02:15 qnikst dev-haskell/skein 2013-08-26 04:12:13 qnikst dev-haskell/clientsession 2013-08-26 04:14:38 qnikst dev-haskell/asn1-data 2013-08-26 04:19:05 qnikst dev-haskell/blaze-builder-conduit 2013-08-26 04:21:21 qnikst dev-haskell/asn1-types 2013-08-26 04:24:55 qnikst games-emulation/dolphin 2013-08-26 04:25:00 twitch153 dev-haskell/crypto-pubkey-types 2013-08-26 04:26:17 qnikst dev-haskell/pem 2013-08-26 04:30:25 qnikst dev-haskell/cmdargs 2013-08-26 04:31:59 qnikst dev-haskell/crypto-numbers 2013-08-26 04:34:45 qnikst dev-haskell/crypto-pubkey 2013-08-26 04:36:43 qnikst dev-haskell/cookie 2013-08-26 04:42:43 qnikst dev-haskell/failure 2013-08-26 04:44:21 qnikst dev-haskell/http-types 2013-08-26 04:49:11 qnikst dev-haskell/mime-types 2013-08-26 04:52:36 qnikst dev-haskell/encoding2013-08-26 04:58:10 qnikst dev-haskell/ranges 2013-08-26 04:59:25 qnikst dev-haskell/text-icu2013-08-26 04:59:57 qnikst dev-haskell/stringprep 2013-08-26 05:00:39 qnikst dev-haskell/punycode2013-08-26 05:01:46 qnikst dev-haskell/idna2013-08-26 06:07:11 qnikst dev-haskell/publicsuffixlist2013-08-26 07:30:49 qnikst dev-haskell/socks 2013-08-26 07:33:49 qnikst dev-haskell/zlib-bindings 2013-08-26 08:15:31 qnikst dev-haskell/zlib-conduit2013-08-26 08:16:32 qnikst dev-haskell/tls 2013-08-26 08:20:07 qnikst dev-haskell/cipher-rc4 2013-08-26 08:23:19 qnikst dev-haskell/tls-extra 2013-08-26 08:24:51 qnikst dev-haskell/http-attoparsec 2013-08-26 08:31:18 qnikst dev-haskell/simple-sendfile 2013-08-26 08:35:07 qnikst dev-haskell/vault 2013-08-26 08:35:47 qnikst dev-haskell/wai 2013-08-26 08:38:21 qnikst dev-haskell/warp2013-08-26 08:40:36 qnikst dev-haskell/comonad 2013-08-26 08:55:41 qnikst dev-haskell/transformers-compat 2013-08-26 08:59:54 qnikst dev-haskell/contravariant 2013-08-26 09:02:46 qnikst dev-haskell/semigroupoids 2013-08-26 09:03:10 qnikst dev-util/android-tools 2013-08-26 09:46:32 zmedico dev-haskell/distributive2013-08-26 10:07:21 qnikst dev-haskell/comonad-transformers2013-08-26 10:12:19 qnikst dev-haskell/comonads-fd 2013-08-26 10:28:21 qnikst dev-haskell/generic-deriving2013-08-26 10:30:39 qnikst dev-haskell/profunctors 2013-08-26 10:32:49 qnikst dev-haskell/groupoids 2013-08-26 10:34:57 qnikst dev-haskell/semigroupoid-extras 2013-08-26 10:35:11 qnikst dev-haskell/profunctor-extras 2013-08-26 10:35:25 qnikst dev-haskell/reflection 2013-08-26 10:50:52 qnikst dev-haskell/simple-reflect 2013-08-26 10:51:56 qnikst dev-haskell/lens
[gentoo-dev] ruby_targets_ruby20 missing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > ozzie src # emerge -vp ruby > > > These are the packages that would be merged, in reverse order: > > Calculating dependencies... done! > > emerge: there are no ebuilds built with USE flags to satisfy > ">=dev-ruby/rake-0.9.6[ruby_targets_ruby20]". !!! One of the > following packages is required to complete your request: - > dev-ruby/rake-0.9.6::gentoo (Change USE: +ruby_targets_ruby20) > (dependency required by "dev-lang/ruby-2.0.0_p247-r1" [ebuild]) > (dependency required by "ruby" [argument]) So, um, why exactly is ruby 2.0.0 stable if I can't even update my system anymore? I'm having the same issue across 3 systems so I'm assuming it's not a bad sync. Whatever the current "solution" to not adding ruby20 to RUBY_TARGETS is, it's not work for me. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSI9EQAAoJEKXdFCfdEflKPjAQAICCV5hwk8bJNSBvmaoR9t+k r7fAVnAZtDMFgMK6LBUIlsJU7/Z2YjpuTU25My0aRJEQODUSusYO7YFys6QosnnA hy5651Nj4PL2Zk2PFSfGRTjMyyc32kGJTqaCbOXiBVsKSbKpxzjcyp6HKsbZ/n3m FHHk/NAYOqI11BzB1N9Pet3wYwvj+tJ4Ao+Liu3WrqnfJxo7TTVTZAiTCxrfE1l7 PMsBoGkf7IqrFIC/HoBEE8um3PhSQQmyxXvr49+0MWRhlkQZXKVgD33lQen12jZ0 JBRQQYsLwNPFrSwc4/Y4Us44A3+36eBmVHPQs+EkFKzf5+fO8Ppot0vzmTE4HhHA BkpWp2QKKC9W7UlEq7VenydN+erQ6j+BwqKT4+5sMmczLd+5dNsg4aPAIVRVXrqm AyvoMP7qv6K+jnPOLvg1md7LJpsrSYV9VeKwR2d+mPA+PZWzRfI3O7AwpDVXbAyP VnO7VgebPbpwsW8GXHyq/8P5QuWcSdQbt+pO3j7Lzevb9bAakU43d13WINhEWyMG Tw9FioslSTHKFR5TUvKYD5XgqFB/flUzkJNBH7MhPGpIAYpnAdRwfgPakNt6uTSK VIdRx+6wjeKtlQVBeUt/9iQ34HjGEtT+6XFyXp9iuP/X6h+HInXmCYsguMt8FMvn M+7cUXZYoz4VzHh3qtry =x1aK -END PGP SIGNATURE-
Re: [gentoo-dev] git-r3: initial draft for review [v2]
On Sat, Aug 31, 2013 at 10:48:32PM +0200, Michał Górny wrote:
> Dnia 2013-08-31, o godz. 11:26:30
> Ulrich Mueller napisał(a):
>
> > > On Sat, 31 Aug 2013, Michał Górny wrote:
> >
> > > And time for a small update.
> >
> > In git-r3_checkout:
> >
> > git --no-pager diff --color --stat \
> > ${old_commit_id}..${new_commit_id}
> >
> > I'd rather omit the --color option, otherwise log files will contain
> > escape sequences.
>
> I'd rather leave it. The diff is more for pretty-printing anyway, it
> shouldn't really matter in the logs.
Please don't. I also do not want escape sequences in log files.
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Updated diffs + gdk-pixbuf handling.
Tested with success locally.
--
Gilles Dartiguelongue
Gentoo
Index: gnome2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2.eclass,v
retrieving revision 1.122
diff -u -B -r1.122 gnome2.eclass
--- gnome2.eclass 26 May 2013 14:08:21 - 1.122
+++ gnome2.eclass 1 Sep 2013 15:04:58 -
@@ -258,6 +258,7 @@
gnome2_icon_savelist
gnome2_schemas_savelist
gnome2_scrollkeeper_savelist
+ gnome2_gdk_pixbuf_savelist
}
# @FUNCTION: gnome2_pkg_postinst
@@ -271,6 +272,7 @@
gnome2_icon_cache_update
gnome2_schemas_update
gnome2_scrollkeeper_update
+ gnome2_gdk_pixbuf_update
}
# # FIXME Handle GConf schemas removal
Index: gnome2-utils.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2-utils.eclass,v
retrieving revision 1.31
diff -u -B -r1.31 gnome2-utils.eclass
--- gnome2-utils.eclass 27 Oct 2012 22:24:10 - 1.31
+++ gnome2-utils.eclass 1 Sep 2013 15:04:58 -
@@ -15,6 +15,8 @@
# * GConf schemas management
# * scrollkeeper (old Gnome help system) management
+inherit multilib
+
case "${EAPI:-0}" in
0|1|2|3|4|5) ;;
*) die "EAPI=${EAPI} is not supported" ;;
@@ -50,6 +52,12 @@
# Path to glib-compile-schemas
: ${GLIB_COMPILE_SCHEMAS:="/usr/bin/glib-compile-schemas"}
+# @ECLASS-VARIABLE: GDK_PIXBUF_UPDATE_BIN
+# @INTERNAL
+# @DESCRIPTION:
+# Path to gdk-pixbuf-query-loaders
+: ${GDK_PIXBUF_UPDATE_BIN:="/usr/bin/gdk-pixbuf-query-loaders"}
+
# @ECLASS-VARIABLE: GNOME2_ECLASS_SCHEMAS
# @INTERNAL
# @DEFAULT_UNSET
@@ -74,6 +82,12 @@
# @DESCRIPTION:
# List of GSettings schemas provided by the package
+# @ECLASS-VARIABLE: GNOME2_ECLASS_GDK_PIXBUF_LOADERS
+# @INTERNAL
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# List of gdk-pixbuf loaders provided by the package
+
DEPEND=">=sys-apps/sed-4"
@@ -387,6 +401,46 @@
eend $?
}
+# @FUNCTION: gnome2_gdk_pixbuf_savelist
+# @DESCRIPTION:
+# Find if there is any gdk-pixbuf loader to install and save the list in
+# GNOME2_ECLASS_GDK_PIXBUF_LOADERS variable.
+# This function should be called from pkg_preinst.
+gnome2_gdk_pixbuf_savelist() {
+ has ${EAPI:-0} 0 1 2 && ! use prefix && ED="${D}"
+ pushd "${ED}" 1>/dev/null
+ export GNOME2_ECLASS_GDK_PIXBUF_LOADERS=$(find "usr/$(get_libdir)/gdk-pixbuf-2.0" -type f 2>/dev/null)
+ popd 1>/dev/null
+}
+
+# @FUNCTION: gnome2_gdk_pixbuf_update
+# @USAGE: gnome2_gdk_pixbuf_update
+# @DESCRIPTION:
+# Updates gdk-pixbuf loader cache if GNOME2_ECLASS_GDK_PIXBUF_LOADERS has some.
+# This function should be called from pkg_postinst and pkg_postrm.
+gnome2_gdk_pixbuf_update() {
+ has ${EAPI:-0} 0 1 2 && ! use prefix && EROOT="${ROOT}"
+ local updater="${EROOT}${GDK_PIXBUF_UPDATE_BIN}"
+
+ if [[ ! -x ${updater} ]]; then
+ debug-print "${updater} is not executable"
+ return
+ fi
+
+ if [[ -z ${GNOME2_ECLASS_GDK_PIXBUF_LOADERS} ]]; then
+ debug-print "gdk-pixbuf loader cache does not need an update"
+ return
+ fi
+
+ ebegin "Updating gdk-pixbuf loader cache"
+ local tmp_file=$(mktemp -t tmp.XX_gdkpixbuf)
+ ${updater} 1> "${tmp_file}" &&
+ chmod 0644 "${tmp_file}" &&
+ mv -f "${tmp_file}" "${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache"
+ eend $?
+}
+
+
# @FUNCTION: gnome2_query_immodules_gtk2
# @USAGE: gnome2_query_immodules_gtk2
# @DESCRIPTION:
Index: gdk-pixbuf-2.28.2.ebuild
===
RCS file: /var/cvsroot/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.28.2.ebuild,v
retrieving revision 1.2
diff -u -B -r1.2 gdk-pixbuf-2.28.2.ebuild
--- gdk-pixbuf-2.28.2.ebuild 5 Aug 2013 09:48:12 - 1.2
+++ gdk-pixbuf-2.28.2.ebuild 1 Sep 2013 15:09:12 -
@@ -3,7 +3,8 @@
# $Header: /var/cvsroot/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.28.2.ebuild,v 1.2 2013/08/05 09:48:12 ssuominen Exp $
EAPI="5"
-inherit gnome.org multilib libtool
+
+inherit gnome.org gnome2-utils multilib libtool
DESCRIPTION="Image loading library for GTK+"
HOMEPAGE="http://www.gtk.org/";
@@ -64,19 +65,15 @@
prune_libtool_files --modules
}
+pkg_preinst() {
+ gnome2_gdk_pixbuf_savelist
+}
+
pkg_postinst() {
# causes segfault if set, see bug 375615
unset __GL_NO_DSO_FINALIZER
- tmp_file=$(mktemp -t tmp_gdk_pixbuf_ebuild.XX)
- # be atomic!
- gdk-pixbuf-query-loaders > "${tmp_file}"
- if [ "${?}" = "0" ]; then
- cat "${tmp_file}" > "${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache"
- else
- ewarn "Cannot update loaders.cache, gdk-pixbuf-query-loaders failed to run"
- fi
- rm "${tmp_file}"
+ gnome2_gdk_pixbuf_update
# FIXME: use subslots to get rebuilds when really needed
# Every major version bump???
@@ -86,3 +83,9 @@
elog "emerge -va1 \$(qfile -qC ${EPREFIX}/usr/lib/gtk-2.0/2.*/loaders)"
fi
}
+
+pkg_postrm() {
+ if [[ -z ${REPLACED_BY_VERSIONS} ]]; then
+ rm -f "${EROOT}"usr/$(get_libdir)/${PN}-2.0/2.10.0/loaders.cache
+ fi
+}
Re: [gentoo-dev] net-proxy herd is still looking for help (was: Re: [gentoo-dev] net-proxy herd is empty)
On Sun, Sep 1, 2013 at 10:01 AM, Tom Wijsman wrote: > If you want to help, please join the herd. If nobody joins, we will > likely proceed with dropping it in a month and moving its packages > to maintainer-needed letting everybody want the packages they prefer. > > Another option is to combine the net herds together into a bigger net > herd, as I have previously suggested; we might need to look into that. I'd think twice before doing that. If there is a real synergy (common eclass use, need to manage deps and releases, etc) then it might make sense. Otherwise all you end up doing is delaying the inevitable, except this time with even a larger group of packages moving to maintainer-needed. Herds should be reasonably-sized, and they should be packages that make sense to maintain together - not just collections of packages that fit some theme. We already have categories. If maintainers aren't coordinating across a herd then better to just split it up. Note - I'm not calling for any dramatic changes here - if teams of maintainers are already working closely together by all means keep your herds. However, if a herd is just a dumping ground for packages that nobody really looks at, then it isn't being used properly. Rich
[gentoo-dev] net-proxy herd is still looking for help (was: Re: [gentoo-dev] net-proxy herd is empty)
On Sun, 3 Mar 2013 21:00:19 +0200 Pavlos Ratis wrote: > On Sun, Mar 3, 2013 at 6:16 PM, Tom Wijsman wrote: > > On Sun, 03 Mar 2013 17:00:57 +0100 > > Pacho Ramos wrote: > > > >> As wschlich no longer has enough time for that packages, this herd > >> is now empty. If you want to help, please join the herd. If nobody > >> joins, I will proceed with dropping it and moving its packages > >> maintainer-needed letting everybody want the packages they prefer. > > > > Not joining until others join because I don't want to be the sole > > herd member, but I do want to help out with occasional bumps and > > such if there clearly is a case of lack of manpower. > > > > I'm also interested in stepping up as a maintainer for > > net-proxy/privoxy. > > I am interested in joining the herd. Now we can be 2 members. :) While I joined under the above premise to help out I have became the main maintainer but am unable to cover everything this herd does; Pavlos didn't have much time either to together cover everything. So, we currently have around 48 bugs open at the moment; there are also probably some versions bumps waiting as well, as well as some of the other maintaining tasks that possibly come along. If you want to help, please join the herd. If nobody joins, we will likely proceed with dropping it in a month and moving its packages to maintainer-needed letting everybody want the packages they prefer. Another option is to combine the net herds together into a bigger net herd, as I have previously suggested; we might need to look into that. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Dnia 2013-09-01, o godz. 13:29:27
Gilles Dartiguelongue napisał(a):
>
> Le samedi 31 août 2013 à 18:44 +0200, Gilles Dartiguelongue a écrit :
> > Le samedi 31 août 2013 à 16:49 +0200, Michał Górny a écrit :
> > > Dnia 2013-08-31, o godz. 15:00:43
> > > Gilles Dartiguelongue napisał(a):
> > >
> > > > Le samedi 31 août 2013 à 13:40 +0200, Michał Górny a écrit :
> > > > > > + cat "${tmp_file}" >
> > > > > > "${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache"
> > > > >
> > > > > Why not mv or cp? Also you need '|| die' here since 'cat' can fail
> > > > > writing.
>
> Thanks for pacho's bugzillafu, we've got the original reports here:
>
> https://bugs.gentoo.org/show_bug.cgi?id=413529
> https://bugs.gentoo.org/show_bug.cgi?id=413485
>
> It seems the cat usage was only to avoid handling file permission
> issues.
Then I guess using 'chmod' on the temporary file + 'mv' afterwards.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] rfc: stabilization policies
On 1 September 2013 11:42, hasufell wrote: > On 09/01/2013 12:30 PM, Thomas Sachau wrote: >> they dont search for recruits > > why not? > Will you please ready Thomas e-mail again as a whole? You only "extract" a single sentence and you redirect the other part of it to /dev/null. We (recruiters) only point people to the appropriate places. We can't just go ahead an find a recruit for the eg Gnome team. The Gnome team will have to find good recruits for their team and then "give" them to us to recruit them properly. It's impossible for us to find all the "good" people out there and bring them on board. The individual projects/team need to do that for us. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Le samedi 31 août 2013 à 18:44 +0200, Gilles Dartiguelongue a écrit :
> Le samedi 31 août 2013 à 16:49 +0200, Michał Górny a écrit :
> > Dnia 2013-08-31, o godz. 15:00:43
> > Gilles Dartiguelongue napisał(a):
> >
> > > Le samedi 31 août 2013 à 13:40 +0200, Michał Górny a écrit :
> > > > > + cat "${tmp_file}" >
> > > > > "${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache"
> > > >
> > > > Why not mv or cp? Also you need '|| die' here since 'cat' can fail
> > > > writing.
Thanks for pacho's bugzillafu, we've got the original reports here:
https://bugs.gentoo.org/show_bug.cgi?id=413529
https://bugs.gentoo.org/show_bug.cgi?id=413485
It seems the cat usage was only to avoid handling file permission
issues.
The use of a temporary file itself it to avoid having a corrupted file
if the command fails.
As for immodules I plan to provide patches to fix it after we agree on
this one.
--
Gilles Dartiguelongue
Gentoo
--
Gilles Dartiguelongue
Gentoo
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: stabilization policies
On 09/01/2013 12:30 PM, Thomas Sachau wrote: > they dont search for recruits why not?
Re: [gentoo-dev] rfc: stabilization policies
Rick "Zero_Chaos" Farina schrieb: > On 08/31/2013 03:57 PM, Tom Wijsman wrote: >> On Sat, 31 Aug 2013 20:45:00 +0200 >> Pacho Ramos wrote: > >>> El sáb, 31-08-2013 a las 12:37 -0400, Rick "Zero_Chaos" Farina >>> escribió: [...] I know we are a little OT here but the fifth type of recruit is someone who is very excited, very dedicated, and completely unable to find a mentor. That is where I was for a long time, no one seemed to have the time to mentor me. Personally I think that is a big issue in the growth of gentoo, if we all take a little time out to be mentors there will be more gentoo devs and we will get more done. -ZC >>> >>> I guess we should have a official contact or mail alias to let them >>> contact. If they don't even contact me, I cannot know about them and >>> then mentor them :/ > >> Ah, I like this idea better than the "list on Gentoo Wiki" I was trying >> to approach; the only downside I can imagine if it were a single person >> that might not respond in time (busy / devaway / MIA), so I think we >> should at least aim to make it a mail alias with multiple persons. > >> We could then list people on some project page; but, only their >> forenames or nicknames and not their actual full name and e-mail such >> that their private details can stay private if they wish to. > > > I remember actively seeking out mentors and recruiters on irc for a > while and not getting very far. I think that exposing recruitment to a > wider audience than just the recruiters is a good idea, why limit > ourselves to their bandwidth? This isn't a remark on the performance of > the recruiters, just a note that more people means more bandwidth. Please keep in mind, that recruiters in Gentoo usually only point to possible places with mentors, they dont search for recruits, they dont know, which dev may match as mentor and they dont assign someone. They are mainly involved, when someone found a mentor and got prepared. From my experience, the best way to get started is helping out in the area you are interested in. When you have worked in some area for some time, you likely get noticed, already worked with some devs and have good chances, that someone offers himself as mentor. On the other side, if you just join some places and ask things like "Who will be my mentor, i want to join", it is pretty unlikely, that someone will instantly step up. Keep in mind, that proper mentoring includes a good amount of time to invest, so when someone notices that you are already around for some time and did not quickly disappear again, they may be more willing to assist you in your task of becoming a dev. So with this said, i am not sure, if such a central contact point will really improve the situation, it may instead result in a lot of churn, since people loose interest on their way to dev or shortly after. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
