Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: jdgordon: r28078 - trunk/apps/radio

Re: jdgordon: r28078 - trunk/apps/radio

From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Wed, 15 Sep 2010 23:17:59 +1000

On 15 September 2010 22:35, Marianne Arnold <m.arnold_at_telecolumbus.net> wrote:
> Am 15.09.2010 14:01, schrieb Jonas Häggqvist:
>
>>
>> Does anyone have any ideas? (besides "everyone should accept the way I
>> want it")
>>
>
> Every now and then there is something where I wish to be able to edit my own
> commit message and I know that it is technically possible but needs setting
> up on the server side. Maybe it could also help here to add a bit more info
> to or correct the message afterwards at least. (funman even suggested being
> able to edit other one's commit messages.)
>
> Regards, Marianne.
>

I really think this is a bad idea.

Who is the commit log for? If it is for users (which I will include
devs which don't know the area of the commit, i.e codec commits and
myself) then the message is almost never long enough to actually
explain what it is about. If it is for devs then it should only be
long enough to quickly explain what, the diff itself should explain
everything else.

When is it read? users only read it when it happens (or soon (<6m)
afterwards ) to see what development they might have missed, probably
looking for keywords of interest to them. Devs (speaking from my
experience here) do the users thing, but when the message is actually
important is when you are trying to track down a possible breaking
change, and even then (as I said a few replies ago) the message isnt
even the first thing I look for.) And then when I find a possible
change I look at the diff before rereading the message (because I know
it cant possibly explain everything).

So I go back to what I said at the start, that the problem isnt in the
content of the commit messages, it is that *users* don't have a better
mechanism to follow development and they are resorting to the commit
log which isnt up to the task.

A blog on the other hand would fix this (almost-) completely. Anyone
who commits something of general interest could do a quick write up,
or someone else could do it if the committer didn't (for absolutely
any reason), we could get immediate feedback from users and devs
regarding the change as a whole (maybe for more explanation, or
whatever), we could of course tag each article so people who dont care
about optimisation commits could just ignore those articles. (That
doesn't mean we would post every single change, but if anyone thought
one was worth mentioning it could be).

Doings this means devs don't need to worry about making sure the
message isnt (necessarily) intelligible to people who dont need to
understand it (but would be to those that do)

Jonathan
Received on 2010-09-15

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy