From owner-freebsd-hackers@freebsd.org Thu Sep 3 12:34:47 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0F13B3E4E49 for ; Thu, 3 Sep 2020 12:34:47 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bj0ck6Y7bz4Mm8; Thu, 3 Sep 2020 12:34:46 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f16b900210e09d63681001b.dip0.t-ipconnect.de [IPv6:2003:cd:5f16:b900:210e:9d6:3681:1b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 1C4AC2DABA; Thu, 3 Sep 2020 12:34:46 +0000 (UTC) (envelope-from se@freebsd.org) To: Dmitry Salychev References: <20200903071401.GA24815@ds-laptop> From: Stefan Esser Cc: freebsd-hackers@freebsd.org Subject: Re: Tracking FreeBSD-CURRENT Message-ID: <6ea7df0a-f62f-d4b4-da88-cc7d96635fc4@freebsd.org> Date: Thu, 3 Sep 2020 14:34:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.2.1 MIME-Version: 1.0 In-Reply-To: <20200903071401.GA24815@ds-laptop> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WdBdyjfx7Rclgem7ie0PsreSYlwKj6jWr" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 12:34:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WdBdyjfx7Rclgem7ie0PsreSYlwKj6jWr Content-Type: multipart/mixed; boundary="f4lcwwN6ltG3OLyV2O8FER7LCrdCPCXpu"; protected-headers="v1" From: Stefan Esser To: Dmitry Salychev Cc: freebsd-hackers@freebsd.org Message-ID: <6ea7df0a-f62f-d4b4-da88-cc7d96635fc4@freebsd.org> Subject: Re: Tracking FreeBSD-CURRENT References: <20200903071401.GA24815@ds-laptop> In-Reply-To: <20200903071401.GA24815@ds-laptop> --f4lcwwN6ltG3OLyV2O8FER7LCrdCPCXpu Content-Type: multipart/mixed; boundary="------------066F23E93B711912C05255FE" Content-Language: en-US This is a multi-part message in MIME format. --------------066F23E93B711912C05255FE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Am 03.09.20 um 09:14 schrieb Dmitry Salychev via freebsd-hackers: > Dear FreeBSD Hackers, >=20 > I'm looking for an advice about tracking development branch on my lapto= p. >=20 > There're several steps described in details at [1] which make it clear > what to do, but I'm trying to understand do I really need to track > FreeBSD-CURRENT to develop a driver, for instance, if I want to keep my= > current laptop running r354233 patched locally. Any new code must be committed to -CURRENT first, before it may be merged into the stable branches (and then will make it into a release). While working with an up-to-date -CURRENT is best, you may keep it at some revision for a few weeks or even months during your development, but may have to rebase it to the then latest -CURRENT revision before the final commit. Since -CURRENT makes no guarantees with regard to kernel interfaces and data structures, there is a small risk, that you'll have to adopt to changes between when you "froze" your -CURRENT source tree and the tree at the time of commit. Staying current is not much of a problem, though. On my system, the "svn up" of the -CURRENT source tree generally finishes in less than 10 seconds and "make buildworld" takes only a few minutes, if you enable META_MODE - and if there are any collisions you'll notice them just when the conflicting changes are fresh and it is easy to assess what needs to be done to adapt your code. > I believe that I'm not the first person in this situation and there mig= ht > be existing solutions I'm not aware of. Definitely not, and I know that some developers fork -CURRENT at some suitable point and merge from the official repository only every few weeks. This will obviously not be a good approach, if you are working with data structures that are in the process of being significantly modified, e.g. to improve the scale-ability of the filesystem or network code. Regards, STefan --------------066F23E93B711912C05255FE-- --f4lcwwN6ltG3OLyV2O8FER7LCrdCPCXpu-- --WdBdyjfx7Rclgem7ie0PsreSYlwKj6jWr Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFqEEo3HqZZwL7MgrcVMTR+u171r99UQFAl9Q4uQFAwAAAAAACgkQR+u171r99USv EQf9EE4lMfbQAmSwY/qW6axHIme5PAPwAZLnupvvQ4NGWvFxFt9XqCX63bFGH3dhdocMYNYItmdZ /inHeBKdfqsG6FZVgJMBHroIDgaji4dSE+ks0UV2GO0+6bX4Txl5OgG7j2Jh1MMrbl+sjo+7k6LX 8k8YNvTy9X80FigkH0FXh9d3T1lj85Wd4XFJE0tWyn3a4/7VHdvfCrs7UlQgCvUIN5jbK4FaAAvK dhIGWsXb0VoQzkuub6CjlbwA1SKHt6ZLki0ynkNocFHDjvPl2hAP03R8YXJtCbhmBuW1I+F7r5eo Uzib82gsrnFIv4UaK0J9/GWbHCZVVU23E8/dsvmMHg== =ti5d -----END PGP SIGNATURE----- --WdBdyjfx7Rclgem7ie0PsreSYlwKj6jWr--