From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y0b5f-0007Xt-Gj for bitcoin-development@lists.sourceforge.net; Mon, 15 Dec 2014 19:13:55 +0000 X-ACL-Warn: Received: from mail-oi0-f47.google.com ([209.85.218.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Y0b5e-0007qT-99 for bitcoin-development@lists.sourceforge.net; Mon, 15 Dec 2014 19:13:55 +0000 Received: by mail-oi0-f47.google.com with SMTP id v63so8525944oia.6 for ; Mon, 15 Dec 2014 11:13:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1WAp0j5SD6KSNke6LsYPKBOUSdWIW6Ga62S6EBbVw48=; b=Pa744BMqIhZM5ymnt3JLwxR9AMQb7ZJXLotC+EpLmSrDpQldlYBG6Vis78MMxZD0DA YsgFO0k5FDK8l6Xes6KscSx82W+C/kH6P3qlemzs1hMmcMlfQRan+F2unP5+4xkF47SO 5dAwrp2ZNOlGjBOuX6OUf1kRl8onwYj+U1CDY4QdZAqG4hJMmzcy5CacPMKObDrnrj+E p/aVc9QJcA7q/1NjG4p7BRS99GR4q16ADlBA1188qdO0uGzH80t6HF65+rfZBizdf8i3 697yMrifNwhK/L6Ozltwuxq7XmvdXR1Zn2CrEle+pgiHhXeRTuG+b2lEeePoQSrvqstJ 8HsQ== X-Gm-Message-State: ALoCoQkHGb1pLb/1FXltGyiliXWhYbVFAcvo+0B7CcQzs2x8pqNI7Ng+hnz3FI2bVNqunA7psY3A MIME-Version: 1.0 X-Received: by 10.182.247.99 with SMTP id yd3mr5621547obc.24.1418668947089; Mon, 15 Dec 2014 10:42:27 -0800 (PST) Received: by 10.182.13.38 with HTTP; Mon, 15 Dec 2014 10:42:27 -0800 (PST) In-Reply-To: References: <20141215124730.GA8321@savin.petertodd.org> Date: Mon, 15 Dec 2014 13:42:27 -0500 Message-ID: From: Cory Fields To: Jeff Garzik Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1Y0b5e-0007qT-99 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 19:13:55 -0000 On Mon, Dec 15, 2014 at 10:20 AM, Jeff Garzik wrote: > On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak wrote: >> >> We all want to see more modular code, but the first steps should just be >> to relocate blocks of code so everything is more logically organised in >> smaller files (especially for consensus critical code). Refactoring should >> come in a second wave preferably after a stable release. > > > This is my opinion as well. In the Linux kernel, we often were faced with a > situation where you have a One Big File driver with > 1MB of source code. > The first step was -always- raw code movement, a brain-dead breaking up of > code into logical source code files. > > Refactoring of data structures comes after that. > > While not always money-critical, these drivers Had To Keep Working. We had > several situations where we had active users, but zero hardware access for > debugging, and zero access to the vendor knowledge (hardware documentation, > engineers). Failure was not an option. ;p > > Performing the dumb Break Up Files step first means that future, more > invasive data structures are easier to review, logically segregated, and not > obscured by further code movement changes down the line. In code such as > Bitcoin Core, it is important to think about the _patch stream_ and how to > optimize for reviewer bandwidth. > > The current stream of refactoring is really a turn-off in terms of > reviewing, sapping reviewer bandwidth by IMO being reviewer-unfriendly. It > is a seemingly never-ending series of tiny > refactor-and-then-stuff-in-a-class-and-make-it-pretty-and-do-all-the-work. > Some change is in order, gentlemen. > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ That's exactly what happened during the modularization process, with the exception that the code movement and refactors happened in parallel rather than in series. But they _were_ done in separate logical chunks for the sake of easier review. The commit tag "MOVEONLY" developed organically out of this process, and a grep of the 0.10 branch for "MOVEONLY" is a testament to exactly how much code moved 1:1 out of huge files and into logically separated places and/or new files. Perhaps it's worth making "MOVEONLY" (which as the name implies, means that code has been copied 1:1 to a new location) use an official dev guideline for use in future refactors. Cory