On Thu, Sep 9, 2010 at 6:23 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Thu, 9 Sep 2010 18:35:46 +0200 Cedric BAIL <cedric.b...@free.fr> said: > >> On Thu, Sep 9, 2010 at 6:15 PM, Gustavo Sverzut Barbieri >> <barbi...@profusion.mobi> wrote: >> > 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", >> >> Not only him, count me on this too. > > :) nb... we WILL have releases. we WILL have stable 1.0.x branches that are > "fixes only" with actual releases. trunk shall always be "development head" - > ie 1.1 "in preparation" for anything already out as 1.0 etc.
anyway, do you agree with the rest? :-) >> > 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? >> >> I agree with all the remark, and maybe it would be good to have a wiki >> page that describe our policy commit. >> -- >> Cedric BAIL >> >> ------------------------------------------------------------------------------ >> 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 > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
