From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 18 13:12:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9778106564A; Wed, 18 Jan 2012 13:12:28 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id E240B8FC15; Wed, 18 Jan 2012 13:12:27 +0000 (UTC) Received: by lahe6 with SMTP id e6so1199173lah.13 for ; Wed, 18 Jan 2012 05:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=XSIBs7cmn6Vi3bb/kAPpJNacEtI9zTamO2RD71WCuLU=; b=A/K2UZW3ujdJPPYzc0GSQ1uTKwD6UiH1Ug5xA2+biVYG0w4DiZcoXKuLPkKzy0VEA0 RkdcLytm2L+4wA4b9el3mcpXxJfL772Qodau3Ie0P9o87STm6ipnayLCxUBrblglKar0 qgAcuYGcEuvrMBnNeU4Wvq56nWVTW/IJZkMXk= Received: by 10.112.99.5 with SMTP id em5mr5109689lbb.85.1326892346182; Wed, 18 Jan 2012 05:12:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.21.168 with HTTP; Wed, 18 Jan 2012 05:11:54 -0800 (PST) In-Reply-To: References: <4F15C44F.1030208@freebsd.org> <1326836797.1669.234.camel@revolution.hippie.lan> <4F16019F.2060300@FreeBSD.org> <1326843399.1669.249.camel@revolution.hippie.lan> <4F160B99.1060001@FreeBSD.org> From: Eitan Adler Date: Wed, 18 Jan 2012 08:11:54 -0500 Message-ID: To: Igor Mozolevsky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ian Lepore , Andriy Gapon , freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 13:12:28 -0000 On Tue, Jan 17, 2012 at 8:41 PM, Igor Mozolevsky wr= ote: > On 18 January 2012 01:11, Eitan Adler wrote: > >> It takes time to review and test patches. There are a lot of people >> that think "it only takes 30 seconds to download the patch, apply, and >> commit." =C2=A0This is just not true. > > I fully understand that and it is not what I was saying, what I was > saying was about the patches that were being plainly ignored/allowed > to go stale. What you said below is perfectly reasonable once a > committer is actively involved in dealing with a patch, then I, and > anyone else for that matter, would be very reasonably expected to be > involved in the process and understands that someone else is working > on the issue you've address. Often times people don't do this part and submit a "drive by patch." Nothing is wrong with that, but it does make it harder to verify that a fix is correct (especially for hardware support PRs). > The problem, however, lies in the time > between a patch is submitted and is "picked up", if the latter ever > occurs!.. That is where the discouragement occurs. I guess I didn't follow through on all the above. My point was that who wants to spend 3, 4, 7, 10 hours fixing a bug report when they can be working on a shiny new feature (or play games, or anything else but work!)? > I hope I've address what you say here just above :-) and > wholeheartedly agree with everything else you've said, but you are > addressing the problem from a different angle: nobody is ever going to > disagree that _once_ someone has picked up a patch it will take them > time to get it through whatever steps necessary. As I said above, the time it takes to follow through on a PR discourages people from even looking. > But, as I said above, > it's getting to *this* stage that is the lengthy and a disheartening > process... I agree that this is a real problem. Unfortunately I can't think of any good solutions. The bugbusting team maintains a list of "easy" and "quality" PRs which we try to get committers to look at. I also maintain a personal "bugging list" (pun intended) of PRs which I bug other people about. This has helped somewhat (the PRs I bug people about tend to get closed) but it isn't sufficient. >> If you have ideas to make this process easier or more efficient we are >> all eager to hear them. I am especially interested to know what *I* >> could do to help speed things along in areas I don't know well enough >> to commit to. > > The problem, which I suspect is very difficult to overcome in what I > call the "bazaar" environment, is the enforcement. Solving this and other problems is so hard a back has been written on the topic: http://producingoss.com/ > One way to > "encourage" people to fix their code would be to prevent them from > committing to -CURRENT once they pass a certain threshold of > "unattended" patches. Of course then, committers will be whinging that > they'd be resigning if they can't commit to -CURRENT, but quite > frankly, why should anyone have the commit privilege if they can't be > bothered to address the bugs, are those people just using the FreeBSD > project to boost their CV (with great powers comes great > responsibility!)? Wouldn't this discourage even more people from helping? --=20 Eitan Adler