xbianonpi / xbian

XBMC on Raspberry Pi, Bleeding Edge
https://xbian.org
GNU General Public License v3.0
294 stars 44 forks source link

RC2 Changelog #546

Closed CurlyMoo closed 9 years ago

CurlyMoo commented 10 years ago

I've put the RC2 image on the XBian website and sourceforge. I also want to create a post about it. Can you @mk01 make a list of what has changed / was updated?

mk01 commented 10 years ago

honestly ? I don't remember. but one liners (at least) are part of all commit logs.

git log --since='1.3.2014' --no-merges --format=%s%b

gives a usable information.

for f in $(find ./ -maxdepth 1 -iname xbian-\* -type d); do [ ! -e $f/.git ] && continue; ( echo $f; cd $f; git log --since='1.3.2014' -g --no-merges --format=%s%b ; ); done > changes.txt

will walk through xbian* folders and export commit messages into changes.txt. but most changes & development since maybe Feb was imx6 support introduction, get rid of any platform dependent code and to match imx6 code base and functionaries to RPI's level. libCEC RPI rewrite with all (but LG specific) bugs fixed. with the never kernel also acceptable USB audio support (on system level), Gotham integration.

CurlyMoo commented 10 years ago

Thanks for reacting on this!

I know how git works :smile:, the problem is that the commits aren't very verbose so it's hard to tell for what you did (globally). That's why i'm asking for you to be a bit more verbose in the future so we can follow-up.

mk01 commented 10 years ago

a while ago I started putting link to github issue in case commit is related to a report. for others, ... are the comments not self-explaining ? sure some degree of preprocessing would be needed to create USER change log from it.

if you want to change approach to that and let's say that required would be such text suitable for direct export - on that one actually we can agree without our usual longer way looking for compromise (which at the end doesn't satisfy neither of us :) )

anaconda commented 10 years ago

The kernel commits are a pleasure to read, e.g. https://github.com/torvalds/linux/commit/fefa8ff810c5ab4c4206aed9d159c4d6fe8d4f1c

Perfect for --pretty=oneline and verbose explanation. That's my dream.

mk01 commented 10 years ago

perhaps we need - one liner for changelog export (with --oneline).

then the rest to make a legacy for future generations. kernel commit logs are fine. for kernel hackers. we have to inform user, not make him bored. (kidding a bit but at end for change log you want more of ${kernel_dir}/Documentation/Changes)

CurlyMoo commented 10 years ago

It just depends on what you are committing. If is just a simple bugfix then a sort message will do (as in your latest commit): e.g. cmdline.txt compression variable is actually preserved as of now.

If it's a big commit, a more verbose message would be more suited: e.g.

XBian was configured using a performance governer. However, instead of just forcing the governor, why not let the user configure it themselves. This commit adds a user configurable governor, but still forces the performance governor when XBMC is playing a video. The performance governor will however stay default.

Setting the new governor can be done by doing ...

The verbose message can then be used in the changelog.

This is at least what i consider a bad commit message: https://github.com/xbianonpi/xbian-package-config-xbmc/commit/e591c09af149962af127f46f4ad8a3d6d19d94fa

syntax fixes doesn't say anything. We need to explode the commit message to see what actually happened, and it indeed was an important fix. This would be more suited:

Due to a syntax issue, the gettext languages weren't processed correctly. Therefor the WIFI credentials dialog couldn't be shown, which is now fixed.

anaconda commented 10 years ago

kernel commit logs are fine. for kernel hackers. we have to inform user Sure, from —oneline a human translates it into a user-friendy message. I’m not convinced the changelog should be generated automagically.

CurlyMoo commented 10 years ago

It would also be great to put some page on the wiki that tells us what is being worked on. Letting the community know that you are working hard on CuBox-I streamlining would be good for the community to hear.

Did you also consider areas in which other developers can contribute? e.g.:

mk01 commented 10 years ago

we are still working on the build platform (+ converting the repos) pushed is

also the img-build part should be tested (img flashed, booted and used).

CurlyMoo commented 10 years ago

I already tested part of the chroot builder and edited the wiki with my results.