Issue 232: 22nd April 2012 out and Akademy talk questions

Sun May 6 16:50:39 UTC 2012

Oh, I forgot to mention that I do NOT include bug fixes that fix bugs that appeared due to changes in master (i.e. fixes to bugs that have never found their way into a stable release). There are lots of them and there is little to no value for users to know that something that broke on master yesterday has been fixed. They don't even know it broke.

mutlu

----- Ursprüngliche Message -----
Von: mutlu_inek <mutlu_inek at yahoo.de>
An: List for co-ordinating production of the KDE Commit-Digest. <digest at kde.org>
CC: 
Gesendet: 21:17 Freitag, 4.Mai 2012
Betreff: Re: Issue 232: 22nd April 2012 out and Akademy talk questions

Hi Marta,

See my answers inline below. Please forgive the awful formatting, Yahoo email sucks for plain text email.

Cheers,

mutlu
________________________________
Von: Marta Rybczynska <kde-i18n at rybczynska.net>
An: digest at kde.org 
Gesendet: 20:27 Samstag, 28.April 2012
Betreff: Issue 232: 22nd April 2012 out and Akademy talk questions

Hello all,
I've just submitted #232 to Dot.Thanks to Multu and Jaka!

I have also some questions for you about the way you work on the Digest and 
the things you'd like to see in the future. If you have any other comments, 
add them too!

0. Are you a developer?

No. I can code a tiny bit, mostly Python and scripting in Bash and HTML. I tried to teach myself C++, but I have not found the time to devote myself to learning C++ to the extent that I could contribute to KDE's code base.

1. What do you do when you're reviewing a commit (deciding if it should be 
included or not)? Do you look in the source code? Do you read the commit 
message?  Is the length of this message important? Are the special tags 
(DIGEST, REVIEW, BUG...) important? Do you look at the commiter name?

I browse through the list of commit messages.
First of all, I find that many can be disregarded easily, if they are one-liners and refer to icons, renamed strings, version bumping, tests, comments, refactoring, etc.
Second, I ignore everything that adds no new value to KDE from a user perspective. That is, new APIs, methods, classes, signals. Of course, there may be an exception to this, if it is clear that there is a really cool new feature behind what is going on. But this is rarely the case. And if I don't know about it (through the commit message itself, or though blog posts or mailing list messages I happen to read), I don't think it is worth looking at the code to determine, whether anything will come out of this. Eventually, there will be a commit regarding the new feature that will name it and make it easy for us to include it.

Third, I have a close look at all tagged commits (DIGEST, REVIEW, BUG...). I include most of them. I include all DIGESTs without review. I include most BUGs, if a) they are not insanely trivial (e.g. a wrong string) and b) there are not too many bug fixes for that specific application that week. If I encounter 10 bug fixed to KDEPIM, I choose the ~5 most important ones and get rid of the others. I read though all REVIEWs, but I end up including few of them. Too often, they do not consist of features or bug fixes that are visible to or interesting for the users.

Fourth, I rarely look at the source code. I do this only, if I assume that a commit message might contain something interesting despite seeming dull. There are rarely clues to this end, thus I don't do it more that maybe once a week

Fifth, I do look at the commiter's name, but only out of curiosity. It doesn't really factor into my decision-making process.

2. What happens if you find too many interesting commits (above our 5% rule)?

I try to see whether there are many bug fixes or small and similar features for a project and then try to eliminate the less relevant bug reports (see previous answer). If I don't get below the 5%, bad luck. Most of the time, though, I am, so I don't worry much about it.

3. What do you do if you see many commits from a single project, where you 
feel that none of them should be included separately?

See the previous answers. I may, however, decide not to get rid of any of them, if the flurry of commits is actually features and if they are unrelated to one another.

4. When classifying, how do you make the difference between a feature and
a bug fix?

I find this to be mostly straight-forward: bug is a fix to a previously existing functionality and a feature is new functionality. Often, though, commits will be tagged "BUG", but are in fact features. This happens since some users perceive the lack of a functionality common in similar programs as a bug, which it is not (IMHO).

5. When classifying, how often do you remove commits?

I think on average I remove 1 to 2 in 10 commits I chose.

6. When writing a summary, what commits you include? With long messages? From 
well-known projects? With many changes in many files? With the tags?

7. Do you want more people to include the DIGEST tag? If so, when?

I think it is great. More people should use it. I would suggest that it be used when significant new functionality in introduced or when the application gains something the users would be interested in (e.g. a major refactoring that leads to speed improvements or significantly increased stability).

8. Do you want more such special tags? Which ones?

Didn't we have a discussion about this?

9. Do you have other suggestions?

We should by Danny a beer. Or two.

Thanks in advance for all input you have. It will make the presentation better 
and, I hope, improve the workflow between us and the developers.

Thanks all,
Marta
_______________________________________________
Digest mailing list
Digest at kde.org
https://mail.kde.org/mailman/listinfo/digest
_______________________________________________
Digest mailing list
Digest at kde.org
https://mail.kde.org/mailman/listinfo/digest