From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 18 01:11:35 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 2FFB6106566C for ; Wed, 18 Jan 2012 01:11:35 +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 77C538FC17 for ; Wed, 18 Jan 2012 01:11:34 +0000 (UTC) Received: by lahe6 with SMTP id e6so756393lah.13 for ; Tue, 17 Jan 2012 17:11:33 -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; bh=9E1nACbenymurQYN7/QL3FoYUboKWrgbhBag5MEkeUQ=; b=AX1C9aEzJoHYFFVQASOq7RDqHDS6LEwznrmYmhuiN5NNTZ/vcYzIIhpnsa4mwXe7/n qqBRgwUjTncrxCRk52kmmSoEHekD6wC6WtZAoJUWHjXtx/QAfZ1u8G2DB1+bC2xuIRzV pYSHnR9ZycgI3sY5/cV9YE8pRnwZZrjALJ0uU= Received: by 10.112.85.195 with SMTP id j3mr4612292lbz.59.1326849093164; Tue, 17 Jan 2012 17:11:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.21.168 with HTTP; Tue, 17 Jan 2012 17:11:02 -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: Tue, 17 Jan 2012 20:11:02 -0500 Message-ID: To: Igor Mozolevsky Content-Type: text/plain; charset=UTF-8 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 01:11:35 -0000 On Tue, Jan 17, 2012 at 7:16 PM, Igor Mozolevsky wrote: > Seriously, WTF is the point of having a PR system that allows patches > to be submitted??! When I submit a patch I fix *your* code (not yours > personally, but you get my gist). No other project requires a > non-committer to be so ridiculously persistent in order to get a patch > through. 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." This is just not true. When I take PRs committers 1) Download the PR 2) Read the surrounding code sufficiently to understand what it does 3) Read the patched code to find the bug 4) Read the patch to see if it fixes the bug 5) Ensure that it is the most appropriate way to fix the bug 6) Apply the patch and test the affected issue. 7) Find the person who wrote the original code (or at least one other person) and have them review it - this person usually goes through steps 1-6 too. 8) Apply the patch to head and commit 9) Verify the changes are correct didn't cause any regressions 10) MFC to stable[789] And this assumes the patch was perfect, there really was a bug, and everyone thinks things through properly. The process take anywhere from half an hour for obvious fixes to multiple days in addition to the committer's work, school, and family obligations.. Being persistent sometimes gives the committer the motivation to go through all those steps. As a part of the "bugbusting" team I've taken quite a few bugs and been the "annoying persistent" person for other people. As a result I've closed quite a few bugs. > Such system is plainly wrong---it simply discourages people from > sending "this works for me"(TM) fixes. Yes and no. The system is bad, it shouldn't take 5 years to commit a correct patch, but at the same time "this works for me patches" still need to go through all of the above. > The committers have to realise > three things: they can and do write broken code now and then, most > people who write patches to help the fBSD along don't have the time to > become full time committers (otherwise they'd already be, right?), and > there's only so many times one is willing to bang their head against a > wall with no results---as Einstein pointed out "Insanity: doing the > same thing over and over again and expecting different results"... And we need to work to find ways to fix issues while still ensuring that the above steps are followed. > I'm not saying that responding to reasonable requests from people who > are in the process of testing and committing the patch, but expecting > the end-users to chase committers to have a fix included is plainly > wrong!.. I agree, and we need to work to find systematic solutions to correct patches waiting for someone to take a look without compromising the quality checks committers (should) do. 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. -- Eitan Adler