classifying and the distinction between different types of commits

[Danny Allen]

Hi Alexander,
* If a commit says that it fixes something but doesn't have a bug report attached, that is ok (commit needs to be important though, remember the 5% rule!)
* Yes, people have been misusing this category - it is only meant for commits that make things either faster, or use less memory, or in rare cases, the interface more streamlined ("now this can be done in 2 clicks instead of 10")
* "Other" is for commits that don't really fit elsewhere: for example, I used to select commits that were really interesting or funny even if they otherwise wouldn't be important (like someone writing in the message something really important they learned, etc.)

Thanks,
Danny


----- Original Message -----
From: "Alexander van Loon" <a.vanloon at alexandervanloon.nl>
To: digest at kde.org
Sent: Tuesday, 28 December, 2010 10:45:15 PM
Subject: classifying and the distinction between different types of commits

Currently I’m busy with classifying, and I noticed again how much
trouble I’m having with deciding which type to designate to commits. For
example:

     1. Do we only mark commits which refer to a bug number as a bug
        fix, or also those without if the comment tells us that it fixes
        a crash without referring to a bug number?
     2. What falls in the optimize category? In practice far too much in
        my eyes it seems, what does really belong there? Is it safe to
        designate everything which isn’t visible to the end user as
        optimize while designating everything which is as a feature?
     3. What is ‘other’ used for?

It seems to me we also need Classification Guidelines?

_______________________________________________
Digest mailing list
Digest at kde.org
https://mail.kde.org/mailman/listinfo/digest