From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:54617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h9ca8-0006aO-Dp for guix-patches@gnu.org; Thu, 28 Mar 2019 17:29:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h9ca7-0001N4-27 for guix-patches@gnu.org; Thu, 28 Mar 2019 17:29:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:49508) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h9ca6-0001Mt-Nb for guix-patches@gnu.org; Thu, 28 Mar 2019 17:29:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h9ca6-0007Yn-FX for guix-patches@gnu.org; Thu, 28 Mar 2019 17:29:02 -0400 Subject: [bug#34959] Acknowledgement ([PATCH] Add Multiple Common Lisp Packages) Resent-Message-ID: References: <87pnqh4acd.fsf@gmail.com> <87lg15493r.fsf@gmail.com> <87pnqg616m.fsf@elephly.net> <87mule3nm8.fsf@gmail.com> From: Ricardo Wurmus In-reply-to: <87mule3nm8.fsf@gmail.com> Date: Thu, 28 Mar 2019 21:43:04 +0100 Message-ID: <87o95u20iv.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Katherine Cox-Buday Cc: 34959@debbugs.gnu.org Hi Katherine, >> We usually expect one commit per independent change. Could you please >> split up this patch into multiple commits? You can group package >> variants like =E2=80=9Csbcl-trivial-backtrace=E2=80=9D and =E2=80=9Ccl-t= rivial-backtrace=E2=80=9D, but >> separate packages generally each should have their own commit. > > This will be a non-trivial amount of work, and these will have to be > chained against each other since this patch forms a dependency graph. > Given that, can you discuss the benefits of splitting these into > separate commits? Also is it multiple commits, one patch? Or multiple > patches? You can generate one patch per commit with =E2=80=9Cgit format-patch=E2=80= =9D. Separate commits allow us to use the git history to our advantage. We use git not only do we track changes but semantic units of change. We decided on the unit to be individual packages. One effect of this is that the summary line of each commit can be exact. When reading the commit log this keeps surprises to a minimum. If you are an Emacs user I recommend using the Yasnippet =E2=80=9Cadd=E2=80= =9D snippet for quickly generating commit messages for the staged diff. This makes it much easier to create the expected commit messages, especially when there are many commits. (I use this all the time for R package updates and additions.) >>> +(define-public sbcl-trivial-backtrace >>> + (let ((commit-hash "ca81c011b86424a381a7563cea3b924f24e6fbeb")) >>> + (package >>> + (name "sbcl-trivial-backtrace") >>> + (synopsis "Portable simple API to work with backtraces in Common >>> Lisp") >>> + (description "On of the many things that didn't quite get into the >>> Common Lisp standard was how to get a Lisp to output its call stack >>> when something has gone wrong. As such, each Lisp has developed its >>> own notion of what to display, how to display it, and what sort of >>> arguments can be used to customize it. trivial-backtrace is a simple >>> solution to generating a backtrace portably.") >> >> Please break up long lines like this. Please run =E2=80=9C./pre-inst-en= v guix >> lint sbcl-trivial-backtrace=E2=80=9D, which will tell you about this pro= blem. > > I did run linting, but I wasn't sure how to break up description > strings. If I just do line-breaks, will that be OK? Yes. Line breaks are the right tool here. In Emacs you can do M-q while point is on the description string to break up the lines in the expected fashion. >>> + (source >>> + (origin >>> + (method git-fetch) >>> + (uri (git-reference >>> + (url "https://github.com/gwkkwg/trivial-backtrace.git") >>> + (commit commit-hash))) >> >> Throughout you can use =E2=80=9Ccommit=E2=80=9D instead of =E2=80=9Ccomm= it-hash=E2=80=9D =E2=80=94 there is no >> naming conflict. > > Yes, I know. I preferred `commit-hash` because that's what it is -- not > an actual commit. Do we standardize this much, down to variable names? That=E2=80=99s fine. I guessed that you used =E2=80=9Ccommit-hash=E2=80=9D= to avoid a name clash, so I clarified that this is not necessary. Personally, I think it=E2=80=99s best to stick with the established convent= ions as it makes working on Guix less surprising. -- Ricardo