| Message ID | 20160926103447.31830-4-david@craven.ch |
|---|---|
| State | New |
| Headers | show |
Why are we removing this?
On Mon, Sep 26, 2016 at 12:34:45PM +0200, David Craven wrote:
* gnu/packages/linux.scm (linux-libre-beagle-bone-black): Remove.
---
gnu/packages/linux.scm | 7 -------
1 file changed, 7 deletions(-)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 243a71c..6f7986d 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -339,13 +339,6 @@ It has been modified to remove all non-free binary blobs.")
#:defconfig "multi_v7_defconfig"
#:extra-version "arm-generic"))
-(define-public linux-libre-beagle-bone-black
- (make-linux-libre %linux-libre-version
- %linux-libre-hash
- '("armhf-linux")
- #:defconfig "omap2plus_defconfig"
- #:extra-version "beagle-bone-black"))
-
;;;
;;; Pluggable authentication modules (PAM).
--
2.9.0
It's for the original beagle bone I think, not the beagle bone black, so it's named wrong at best. I'm using the generic kernel for my bbb. Unless someone has a bb board and wants to test this, it's just code no one is using.
Hello,
@David: the following question is nothing against you, I just
took the opportunity to ask, sorry for the thread hijacking.
On Mon, Sep 26, 2016 at 3:23 PM, John Darrington wrote:
> Why are we removing this?
Is it just me finding this changelog format usefulness to be
very low ?
I've come to understand this is a standardized way of doing it,
but... Can someone point me to an explanation about why they
are done like this ?
I read a few on this ML since a few weeks and am almost daily
wondering "WTF ?" There's often no explanation about the reason
why the changes are made...
Thanks
Vincent Legoll <vincent.legoll@gmail.com> writes: > @David: the following question is nothing against you, I just > took the opportunity to ask, sorry for the thread hijacking. > > On Mon, Sep 26, 2016 at 3:23 PM, John Darrington wrote: >> Why are we removing this? > > Is it just me finding this changelog format usefulness to be > very low ? > > I've come to understand this is a standardized way of doing it, > but... Can someone point me to an explanation about why they > are done like this ? > > I read a few on this ML since a few weeks and am almost daily > wondering "WTF ?" There's often no explanation about the reason > why the changes are made... It is acceptable to add an explanation between the summary line and the changelog block. We’ve done so in the past. See one of commits e465d9e19087ab150f7e31f21c09e4a147b93b36, dfdaea32e90fd226aa98028a196fca3d2d371a94, 7f39e131805857614a171b51cbf432b4285ba1e6, 4c0416ae1709e08c311d32af4823fac9d73364ee, … for examples. ~~ Ricardo
On Mon, Sep 26, 2016 at 04:24:10PM +0200, Vincent Legoll wrote:
Hello,
@David: the following question is nothing against you, I just
took the opportunity to ask, sorry for the thread hijacking.
On Mon, Sep 26, 2016 at 3:23 PM, John Darrington wrote:
> Why are we removing this?
Is it just me finding this changelog format usefulness to be
very low ?
I entirely agree.
Our current convention for commit messages is aesthetically pleasing,
but useless. It is redundant to put in the message WHAT has changed.
That can be easily determined by running "git show". What is much
more usefull is the reason WHY we changed it.
Recently, on another project, I came across a line of code which I
was pretty sure was pointless. I was about to delete it - but I
decided to check first. So I ran "git blame" to find out which
commit had added it. Then I ran git show to get the full details
of that commit. Fortunately, the person who had committed it 5 years
ago had mentioned exactly why it was needed. - and it was there
for a very valid reason too. Had we been using the Guix convention,
this would probably have been deleted and consequences would have
followed.
I vote that we make the reason for a commit to be compulsory. All
other details optional.
J'
> I entirely agree. I'm not alone :-) > Our current convention for commit messages is aesthetically pleasing, > but useless. It is redundant to put in the message WHAT has changed. > That can be easily determined by running "git show". What is much > more usefull is the reason WHY we changed it. +1 > Recently, on another project, I came across a line of code which I > was pretty sure was pointless. I was about to delete it - but I > decided to check first. So I ran "git blame" to find out which > commit had added it. Then I ran git show to get the full details > of that commit. Fortunately, the person who had committed it 5 years > ago had mentioned exactly why it was needed. - and it was there > for a very valid reason too. Had we been using the Guix convention, > this would probably have been deleted and consequences would have > followed. Been there, done that... > I vote that we make the reason for a commit to be compulsory. All > other details optional. +1, more details is better than less, LKML-style...
On Mon, Sep 26, 2016 at 06:49:34PM +0200, John Darrington wrote: > Our current convention for commit messages is aesthetically pleasing, > but useless. It is redundant to put in the message WHAT has changed. > That can be easily determined by running "git show". What is much > more usefull is the reason WHY we changed it. I find the GNU changelog style to be very useful when reading the Git log. There are certain types of commits that we make over and over again, especially with packages (updates, adding inputs, etc), and I find it helpful when their commit messages follow a common format. I agree that commits that don't conform to one of those types should have some explanation. This is why I often rewrite commit messages when I am committing on behalf of somebody else. But there is a value to "aesthetic" consistency. It's just like having standards for code style in my opinion. It helps a lot when reading others' commits.
On Mon, Sep 26, 2016 at 01:31:09PM -0400, Leo Famulari wrote:
On Mon, Sep 26, 2016 at 06:49:34PM +0200, John Darrington wrote:
> Our current convention for commit messages is aesthetically pleasing,
> but useless. It is redundant to put in the message WHAT has changed.
> That can be easily determined by running "git show". What is much
> more usefull is the reason WHY we changed it.
I find the GNU changelog style to be very useful when reading the Git
log.
There are certain types of commits that we make over and over again,
especially with packages (updates, adding inputs, etc), and I find it
helpful when their commit messages follow a common format.
I agree that commits that don't conform to one of those types should
have some explanation. This is why I often rewrite commit messages when
I am committing on behalf of somebody else.
But there is a value to "aesthetic" consistency. It's just like having
standards for code style in my opinion. It helps a lot when reading
others' commits.
I don't object to a having a common style. I just wish that the information
that we put in our messages a) gave the rationale for the change; and b) didn't
merely repeat information which git show could have told me.
J'
> I don't object to a having a common style. I just wish that the information > that we put in our messages a) gave the rationale for the change; and b) didn't > merely repeat information which git show could have told me. So is anyone against this change or just my commit message? Would someone like to suggest a better one?
> So is anyone against this change or just my commit message? Would > someone like to suggest a better one? The discussion about changelog style is orthogonal to this patch, LGTM, with your explanation to John's question, we can see why this change is done. Let's not hold this hostage to $OTHER_SUBJECT...
> Recently, on another project, I came across a line of code which I > was pretty sure was pointless. The guy who wrote that line should have included a comment in that case. The git history isn't a replacement for code commenting. Code needs to be readable without looking at it's history.
On Mon, Sep 26, 2016 at 08:06:13PM +0200, David Craven wrote: > > I don't object to a having a common style. I just wish that the information > > that we put in our messages a) gave the rationale for the change; and b) didn't > > merely repeat information which git show could have told me. > > So is anyone against this change or just my commit message? Would > someone like to suggest a better one? If it's true that this kernel variant is not for the BBB, and you are using a generic kernel successfully on the BBB, then I see no problem with this change. But I'm not an expert on this subject. Be sure to add a comment explaining the change in the commit message ;)
Hullo, On 26/09/16 18:49, John Darrington wrote: > I vote that we make the reason for a commit to be compulsory. +1, s/commit/non-trivial commit/ I agree that it should be more strongly encouraged, if just to make people aware that it's actually allowed — plenty aren't. If no-one submits a proposal, I will. > All other details optional. -1, but I think *that* would require more than a mere vote anyway ;-) <blah> I found the strict commit format annoying at first. Then I started following the guix-commit list for fun and edutainment. Then I tried following another commit list. I have seen the light. That curated list of changes might ‘duplicate’ the diff in certain trivial cases, but it saves more people far more time than it cost me to write. </blah> Kind regards, T G-R
John Darrington <john@darrington.wattle.id.au> writes: > On Mon, Sep 26, 2016 at 04:24:10PM +0200, Vincent Legoll wrote: > Hello, > > @David: the following question is nothing against you, I just > took the opportunity to ask, sorry for the thread hijacking. > > On Mon, Sep 26, 2016 at 3:23 PM, John Darrington wrote: > > Why are we removing this? > > Is it just me finding this changelog format usefulness to be > very low ? > > > I entirely agree. > > Our current convention for commit messages is aesthetically pleasing, > but useless. It is redundant to put in the message WHAT has changed. > That can be easily determined by running "git show". What is much > more usefull is the reason WHY we changed it. > > > Recently, on another project, I came across a line of code which I > was pretty sure was pointless. I was about to delete it - but I > decided to check first. So I ran "git blame" to find out which > commit had added it. Then I ran git show to get the full details > of that commit. Fortunately, the person who had committed it 5 years > ago had mentioned exactly why it was needed. Our conventions for commit logs, which follow the GNU Coding Standards for Change Logs (see section 6.8 of the GNU Coding Standards), is that explanations belong in the comments of the code itself, not in the commit log. If that had been done in the example you give above, you would have known why the line was needed in a small fraction of the time that it must have taken you to perform all the steps above. However, I agree that commits that _remove_ code should include the rationale in the commit log, if the reason is not obvious and if there's no sensible place to put the explanation in the code. What do you think? Mark
On Tue, Sep 27, 2016 at 08:14:38PM -0400, Mark H Weaver wrote:
Our conventions for commit logs, which follow the GNU Coding Standards
for Change Logs (see section 6.8 of the GNU Coding Standards), is that
explanations belong in the comments of the code itself, not in the
commit log. If that had been done in the example you give above, you
would have known why the line was needed in a small fraction of the time
that it must have taken you to perform all the steps above.
That can work in simple instances - where the change is a one liner or at least
where the change is confined to a few consecutive lines in one file. But not
all changes are that simple. Sometimes it is necessary to make a change which
involves lots of small changes in lots of different places in lots of different
files. In such cases it would be rediculous to append a comment to each line
changed. In fact I have seen such code from the 1980s where almost every 4th line
has a comment like:
mode++; /* JMD 09/2/1981: Increment the mode count otherwise the crud wangler overflows
in the case where grunger regurtitates */
The occasional such comment is ok, but when it's every third line it does nothing
for readability nor comprehensibility.
However, I agree that commits that _remove_ code should include the
rationale in the commit log, if the reason is not obvious and if there's
no sensible place to put the explanation in the code.
What do you think?
Well I certainly agree that adding a reason for a change is a good idea. Even if
we do also have text in the message which is superfluous.
J'
Note to self: Must write an improved version of gnulib's git-log-to-changelog script
which will satisfy the die-harders.
Hi, Vincent Legoll <vincent.legoll@gmail.com> skribis: > Is it just me finding this changelog format usefulness to be > very low ? The change log is just a log of changes, not the place where we explain the why and how—this rather goes to comments. See <https://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html> for the rationale. Ludo’.
John Darrington <john@darrington.wattle.id.au> skribis: > I don't object to a having a common style. I just wish that the information > that we put in our messages a) gave the rationale for the change; and b) didn't > merely repeat information which git show could have told me. The rationale should really go to comments in the code: <https://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html>. A notable exception is reverts or removals: for these, I think it’s best to have an explanation in the code, so that someone browsing the history can understand why that happened. Ludo’.
Mark H Weaver <mhw@netris.org> skribis: > Our conventions for commit logs, which follow the GNU Coding Standards > for Change Logs (see section 6.8 of the GNU Coding Standards), is that > explanations belong in the comments of the code itself, not in the > commit log. If that had been done in the example you give above, you > would have known why the line was needed in a small fraction of the time > that it must have taken you to perform all the steps above. > > However, I agree that commits that _remove_ code should include the > rationale in the commit log, if the reason is not obvious and if there's > no sensible place to put the explanation in the code. > > What do you think? +1 Ludo’.
Hello,
On Wed, Sep 28, 2016 at 11:11 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> <https://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html>
I read this and still am on the opposite side.
The "changelog entries are like an undo list" is a WTF, to me this is what
`patch -R` is for...
My take on that (the newbie wanting to grasp it) is that I do the following:
- read git changelog entries titles in gitk (or a ML, or a gitweb)
- if oneliner title looks interesting for a subject I'm currently
trying to learn
- I read the full changelog entry
- if that is still interesting me, then I go read the code
Is there something equivalent with the GNU-styled CLs, that does not require
me to read every patch ? Because that's not scaling very well, especially in
languages that I'm not proficient in.
My example is LKML, the changelogs are an extremely valuable tool to understand
things, to debug, etc... I just love this level of details put into changelogs.
Tastes & colors...
Hi, Vincent Legoll <vincent.legoll@gmail.com> skribis: > On Wed, Sep 28, 2016 at 11:11 PM, Ludovic Courtès <ludo@gnu.org> wrote: >> <https://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html> > > I read this and still am on the opposite side. > > The "changelog entries are like an undo list" is a WTF, to me this is what > `patch -R` is for... Not quite, because the change log shows the language-level view of the changes, which can be hard to infer by looking at a diff. It makes it easy to answer questions such as “when did we change this function?”, “when did we introduce that variable”, etc. > My take on that (the newbie wanting to grasp it) is that I do the following: > - read git changelog entries titles in gitk (or a ML, or a gitweb) > - if oneliner title looks interesting for a subject I'm currently > trying to learn > - I read the full changelog entry > - if that is still interesting me, then I go read the code I see. The commit title is definitely what you’re interested in here. I understand it can be frustratingly short, but then again it’s no substitute for the full discussions or code explanations, IMO. > Is there something equivalent with the GNU-styled CLs, that does not require > me to read every patch ? Because that's not scaling very well, especially in > languages that I'm not proficient in. > > My example is LKML, the changelogs are an extremely valuable tool to understand > things, to debug, etc... I just love this level of details put into changelogs. AIUI Linux-style commit logs are not change logs, but explanations. I still strongly believe that explanations believe in code. Ludo’.
Hello, >> The "changelog entries are like an undo list" is a WTF, to me this is what >> `patch -R` is for... > > Not quite, because the change log shows the language-level view of the > changes, I don't understand "language-level view of the changes" > It makes it easy to answer questions such as “when did we change this > function?”, “when did we introduce that variable”, etc. This looks suspicously close to *-blame functionality, looks script (or any other automated way) -material to me. Personally I've never done this by searching changelogs (and here I show my lack of participation in GNU-standardized projects)... > I see. The commit title is definitely what you’re interested in here. Yes, but this is a layered (recursive) approach, I dig a level when the previous one looked interesting, or backtrack. This allows to cheaply skip irrelevant material (with a small miss rate). > I understand it can be frustratingly short No, for my usage it's totally useless, I never had to search that way, way less efficient that a git blame (+ refinements) > but then again it’s no substitute for the full discussions or code explanations [...] > AIUI Linux-style commit logs are not change logs, but explanations. I > still strongly believe that explanations believe in code. Let's agree to disagree Cheers
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm index 243a71c..6f7986d 100644 --- a/gnu/packages/linux.scm +++ b/gnu/packages/linux.scm @@ -339,13 +339,6 @@ It has been modified to remove all non-free binary blobs.") #:defconfig "multi_v7_defconfig" #:extra-version "arm-generic")) -(define-public linux-libre-beagle-bone-black - (make-linux-libre %linux-libre-version - %linux-libre-hash - '("armhf-linux") - #:defconfig "omap2plus_defconfig" - #:extra-version "beagle-bone-black")) - ;;; ;;; Pluggable authentication modules (PAM).