diff mbox

[4/6] gnu: linux-libre-beagle-bone-black: Remove kernel variant.

Message ID 20160926103447.31830-4-david@craven.ch
State New
Headers show

Commit Message

David Craven Sept. 26, 2016, 10:34 a.m. UTC
* gnu/packages/linux.scm (linux-libre-beagle-bone-black): Remove.
---
 gnu/packages/linux.scm | 7 -------
 1 file changed, 7 deletions(-)

Comments

John Darrington Sept. 26, 2016, 1:23 p.m. UTC | #1
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
David Craven Sept. 26, 2016, 1:25 p.m. UTC | #2
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.
Vincent Legoll Sept. 26, 2016, 2:24 p.m. UTC | #3
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
Ricardo Wurmus Sept. 26, 2016, 3:57 p.m. UTC | #4
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
John Darrington Sept. 26, 2016, 4:49 p.m. UTC | #5
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'
Vincent Legoll Sept. 26, 2016, 4:57 p.m. UTC | #6
> 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...
Leo Famulari Sept. 26, 2016, 5:31 p.m. UTC | #7
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.
John Darrington Sept. 26, 2016, 6 p.m. UTC | #8
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'
David Craven Sept. 26, 2016, 6:06 p.m. UTC | #9
> 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?
Vincent Legoll Sept. 26, 2016, 6:22 p.m. UTC | #10
> 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...
David Craven Sept. 26, 2016, 6:28 p.m. UTC | #11
> 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.
Leo Famulari Sept. 26, 2016, 6:34 p.m. UTC | #12
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 ;)
Tobias Geerinckx-Rice Sept. 27, 2016, 10:47 a.m. UTC | #13
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
Mark H Weaver Sept. 28, 2016, 12:14 a.m. UTC | #14
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
John Darrington Sept. 28, 2016, 6:16 a.m. UTC | #15
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.
Ludovic Courtès Sept. 28, 2016, 9:11 p.m. UTC | #16
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’.
Ludovic Courtès Sept. 28, 2016, 9:13 p.m. UTC | #17
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’.
Ludovic Courtès Sept. 28, 2016, 9:15 p.m. UTC | #18
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’.
Vincent Legoll Oct. 3, 2016, 12:49 p.m. UTC | #19
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...
Ludovic Courtès Oct. 3, 2016, 3:40 p.m. UTC | #20
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’.
Vincent Legoll Oct. 4, 2016, 2:32 p.m. UTC | #21
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 mbox

Patch

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).