From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 8C6661381FB for ; Thu, 27 Dec 2012 06:31:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AA6A321C173; Thu, 27 Dec 2012 06:31:20 +0000 (UTC) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 51C6E21C171 for ; Thu, 27 Dec 2012 06:30:42 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id dr12so4217101wgb.35 for ; Wed, 26 Dec 2012 22:30:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WLxhtonOqBqWZ8PlXj5bmzLjGUDJblvrPrOIeyi8pIw=; b=QmbDg+25TfVwbJIH0Z0OH1CqyExIuBBV7nIm/DSDSwCPGixw+PFrjNXzsY4JiqTMrF DNxk4GwhhYX+p2x+iR3SUz7o1Z/A4Hozj+hEnZ4AfIh/jvBbnB8GufNHBG9a3eMeG/Nz YOSxqf9lu4fVqS9uvPTHSt9g5UcWZvH6WsFJcz2kEXVyIHNNDTa/B41Mi7RDPTsRlCkj bifq1bPcZ+GHqwPpmc876HsKDSmWk7VfarR5s/KPzfa0zgQ4gHKnkPBXAJ/mkZjiTuqx KSRyJ1Bu2ZJ0kBpQVPhDrsVOSNodmZ0Via7shPk1diy90nynuZf2i2RaMA5To4ikc6bA OBkQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.194.235.100 with SMTP id ul4mr47518538wjc.7.1356589841008; Wed, 26 Dec 2012 22:30:41 -0800 (PST) Received: by 10.194.13.67 with HTTP; Wed, 26 Dec 2012 22:30:40 -0800 (PST) In-Reply-To: <20121227013246.1c766dc6@marga.jer-c2.orkz.net> References: <50CDFD7F.7040207@orlitzky.com> <50CE62DE.3060608@orlitzky.com> <20121217104006.4f149977@pomiocik.lan> <20121219075656.3d07efab@marga.jer-c2.orkz.net> <20121219100343.61de5cd1@pomiocik.lan> <50DB2824.6040000@gmail.com> <20121227013246.1c766dc6@marga.jer-c2.orkz.net> Date: Thu, 27 Dec 2012 19:30:40 +1300 Message-ID: Subject: Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...) From: Kent Fredric To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: b887f15c-1bef-4be5-bb07-6161ed4438ab X-Archives-Hash: 8cad120d281848cd6d740e3b13007320 On 27 December 2012 13:32, Jeroen Roovers wrote: > > What you want to do is contact your mentor - that is the person who > should be able to point out where to find the actual answer or just > tell you what the answer is - the point of the quizes is to properly > teach you how things work, not how to find out how things work. This poses a logistics problem Imo, because it requires time-bound dedication from a mentor, and it is an incredibly synchronous sort of behaviour. Its good that a mentor can do this, but IMO, needing to contact a gentoo dev to ask a question that could be easily answered by clearer documentation, suggests that there is room for improvement in the documentation. ( Exactly how to improve documentation to be more accessible is of course a hugely challenging issue ) > You can mail or pastebin someone a diff right now or attach it to a bug > report. If every recruit/mentor team worked that way right now, we > would already catch a lot more problems much earlier. "Mail" a bug report, and anything that results in scm + diff -> email -> scm + diff offers a huge problem in terms of data being faithfully transported to me. It may sound trivial, but if you're working on the target box over an SSH connection, getting the patch in an email is not very fun. pick one of ( diff + xclip + paste , diff + sftp + attach , diff + samba + attach ), and the other end having to do ( download attachment / copy-paste-inline-diff ) -> ( get the diff in a file on a machine somehow from email, and compare / apply to CVS ) ^^^ is a very time consuming process filled with potential places for things to go wrong , and this time consuming cost being associated with *every* patch submission will greatly slow contribution. I'm not saying "just use git", though, of course, this is where git shines, because once you have a repository URI, receiving contributions from that repository becomes incredibly simple. There's no reason we /can't/ have a comparable process for CVS to eliminate needless slopping of files around in pastebins/emails, both of which are time consuming and not designed for doing exactly that. ie: instead of "just use a pastebin", it might help to have a formalised/approved pastebin tool that provides CVS diffs in a usable form ( ie: records CVS commit the diff is based upon, generates diffs with a consistent root point, generates diffs in a consistent format instead of relying on the user to remember the right flags to diff ), and then uploads those diffs to either an existing pastebin, or a gentoo controlled one, and has a way of tracking patches for application to ::gentoo so that people can review/reject submissions and submitters can get automated feedback about submissions. ie: > repoman-submit -m "Update Foo to version x.y.z, etc" ## Your changes have been submitted as @gentoo/af6347 ... > repoman-review * @gentoo/af6347 - Update Foo to version x.y.z * @gentoo/afbeef - Update Bar to version x.y.z > EDITOR=vim repoman-review --show @gentoo/af6347 .... > repoman-review --reject @gentoo/af6347 -m "You have x problem y with blah" > EDITOR=vim repoman-review --show @gentoo/afbeef > repoman-review --accept @gentoo/afbeef ## @gentoo/afbeef commited to CVS Yes. This is an oversimplified example. But I hope you see where I'm going with it. The essential points are 1. Doesn't need manual interaction with EMail at any stage 2. Doesn't need manual interaction with a pastebin at any stage 3. Connectedness to bugzilla/email are entirely optional, and emails/bugs should/could refer to submissions in the queue. And we don't *have* to use Git to get this sort of workflow benefits. > A shiny new workflow doesn't magically make Gentoo development easier. > The hard bits aren't usually related to interactive repo access methods. > > We can't get rid of the quizes just because we all now use $shiny. > It really does, it allows people to much more efficiently submit changes to the tree that you wouldn't trust them to "Just do" themselves, ( because they haven't done the quizzes ), but you would trust an approved dev to review and commit. > > Proxy commits should work exactly like recruit/mentor commits: you > review patches and give the nod and then the commits get done. This > workflow is only slightly less convenient with CVS than with git. > Agreed, but there's no reason we /can't/ make the workflow more convenient, and optimising the proxy/recruit contribution workflow would not be something I'd consider "bad". It just absolves us from having to do the repetitive mundane parts of the contribution process so we can spend more time focusing on the contribution itself.