vincele

i really dont want any of that as default upon a new install.. less is more its better to have as optional rather then mandatory.

OK thanks. Is my proposition above the right thing to put in the release doc ?
 
EDIT: DONE: https://github.com/igorpecovnik/lib.docs/commit/ed96d5ce1662ae2962770c04b85a9771e6e1e876

Fixed done and committed as explain in https://forum.armbian.com/index.php/topic/3029-mainline-ethernet-driver-h3/

Hello,
 
I know this will be a controversial subject, but I often like to see what's happening in a devel repository by browsing commits.
 
I start by looking at the commit titles (first commit message line) to approximate the interest that particular entry is to me, then if deemed interesting, I'll read the full commit message to understand what it is about, then if still interested I'll go read the code.
 
I think this is a fairly straightforward approach to digging in a codebase or development stream, avoiding to loose time on things outside of interest scope, and allowing to focus on specific subjects.
 
So, in order for this workflow to be doable, the commit messages content need a minimum level of details, which is what I'm asking the community to act upon.
 
Would it be possible to mandate a bit more work on that front ?
 
I'm not against messages like "Whitespace fix", "Typo fix", "Better comment", anything that explains a bit what the code diff is about.
 
WDYT ?
 
PS: I think armbian is not so bad wrt $SUBJECT, it just needs a little bit more. I've seen far worse projects where I wouldn't even ask for better commitmsgs, so take that as an endorsement of the (already good) quality level of the work done.
 
Thanks

Hello,
 
I know this will be a controversial subject, but I often like to see what's happening in a devel repository by browsing commits.
 
I start by looking at the commit titles (first commit message line) to approximate the interest that particular entry is to me, then if deemed interesting, I'll read the full commit message to understand what it is about, then if still interested I'll go read the code.
 
I think this is a fairly straightforward approach to digging in a codebase or development stream, avoiding to loose time on things outside of interest scope, and allowing to focus on specific subjects.
 
So, in order for this workflow to be doable, the commit messages content need a minimum level of details, which is what I'm asking the community to act upon.
 
Would it be possible to mandate a bit more work on that front ?
 
I'm not against messages like "Whitespace fix", "Typo fix", "Better comment", anything that explains a bit what the code diff is about.
 
WDYT ?
 
PS: I think armbian is not so bad wrt $SUBJECT, it just needs a little bit more. I've seen far worse projects where I wouldn't even ask for better commitmsgs, so take that as an endorsement of the (already good) quality level of the work done.
 
Thanks

Hello,
 
I know this will be a controversial subject, but I often like to see what's happening in a devel repository by browsing commits.
 
I start by looking at the commit titles (first commit message line) to approximate the interest that particular entry is to me, then if deemed interesting, I'll read the full commit message to understand what it is about, then if still interested I'll go read the code.
 
I think this is a fairly straightforward approach to digging in a codebase or development stream, avoiding to loose time on things outside of interest scope, and allowing to focus on specific subjects.
 
So, in order for this workflow to be doable, the commit messages content need a minimum level of details, which is what I'm asking the community to act upon.
 
Would it be possible to mandate a bit more work on that front ?
 
I'm not against messages like "Whitespace fix", "Typo fix", "Better comment", anything that explains a bit what the code diff is about.
 
WDYT ?
 
PS: I think armbian is not so bad wrt $SUBJECT, it just needs a little bit more. I've seen far worse projects where I wouldn't even ask for better commitmsgs, so take that as an endorsement of the (already good) quality level of the work done.
 
Thanks

Will do, if we get consensus from native english speakers