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. > > 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 ------------------------------------------------------------------------------ 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
