Hi all,
After lots of people complaining to me at IRC, mail and others, I'd
like to ask you developers to improve commits and particularly their
messages.
1 - The most complained annoyance is by far commits that break SVN,
making it unreliable for users... and if you recall we don't have
releases to point to users and have them to stay away from live svn
;-) Okay, people will say (me included) SVN doesn't make our lives
easy and $ANOTHER would help, but raster already said "SVN IT IS",
thus let's try:
- svn status -- without -q, check lines starting with "?" and
either "svn add" them, or "svn propedit svn:ignore $directory" and
list it there. This way we avoid missing files (and missing ignores!)
- svn diff, read what you're committing, see if it does make
sense, if you're committing more than you should (tests, debug, etc)
- make && install && test. If you added a compile-time toggle,
test with and without your option
2 - The second most complained is commit messages. Okay, we're a fun
project and we all commit funny messages, but try to provide some
insightful details, try to make the first line 72 chars and make it a
summary. Please comment the design of your newly added feature, if
there are missing details comment it too. If it is a bug fix, then try
to explain how you fixed it, maybe a test case that verifies your fix.
If it is a leak fix, some details on how you found it, how you fixed
it. -- I do know some cases are harder to provide tests, like E17,
but then let's try to be more descriptive!
3 - The third most complained is mixed commits. Particularly bugfixes
that contain formatting and whitespace changes. Please either commit
the cleanup first, then the fix or vice versa, but not together. "svn
diff" may help you there. These mixed commits are nasty because often
the bug fix is not complete, or breaks something else, and when you
look at the diff you immediately say "WTF, 500 lines of changes to fix
this?!!?!? It will take lots of time to figure out the changes". And
usually the formatting/whitespace is tricky, because lines look alike,
then you start to ignore or waste hours staring at a line to figure it
out. Consider the following example (not real):
+
-
+ fnc();
- fnc();
+ x = i + l;
- x = j + 1;
+ // comment heer
+ // comment here
Now make it hundreds of blocks like this, it is quite hard to spot
that "x = i + l" changed to "x = j + 1", as you start to ignore stuff
as they are all irrelevant in the sibling lines.
4 - The fourth annoyance is related to the previous and is could be
called "commit torrent" or "ssh over svn" or "gcc over svn" and is the
result of people committing every line or test they do, then
committing couple of changes, then commit removing debug code, then
another fix... I don't know the reason, maybe people want to copy
stuff to their compile servers, and instead of scp it there, they
commit and the compile server automatically svn up && make, but it is
annoying. These commit should all be merged/squashed into a single one
and avoid people running into them.
If you follow SVN you'll definitely know the dude that tops all the
annoyances is our beloved top committer: Rasterman :-D As I complained
a lot to him about these facts in IRC, I know of some excuses, some I
do agree like "increase number of testers", but he could do better.
Problem is that he is the "example to be followed" and thus we tend to
get worse and not better, thus I again would like to see some
consideration here.
As we're approaching a release, I'd like to ask you all, including
Raster, to try to be kind and improve over these topics.
Comments? Suggestions?
BR,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
