Hi Ralph, I have applied this patch to master. Two notes for future.
ps. I wouldn't make these notes just for a single patch as yours, but as I noticed there's an interest in publishing and pushing multiple such patches I'll make the recommendations now: o. Get the indentation right. Your patch used spaces for indentation. We use tabs for indentation and spaces for alignment as described here: http://pvanhoof.be/blog/index.php/2009/09/25/indentation If you encounter old code that is wrongly indented, adapt the code surrounding your patch to match those indentation rules (but don't adapt the entire file, only the stuff relevant to your changes, as in the end we still care more about git bisect working in a usable way than we care about indentation nazism. Although Martyn, bless our great release maintainer, can be a real pain in the ass when it comes to getting your indentation right. Don't say I didn't warn you ;-). I'm not sure if he's right or not for being so hard on this, but in the end you'll have to yield and do it right or it just wont get in. Hehe. Someday we'll be big and strong like Martyn, bless our great release maintainer, and then you can enforce arbitrary code indentation rules yourself. We love you Martyn. o. Put the component that you committed to upfront the commit message. In this case you could have used 'libtracker-common: what you changed'. When you have multiple components you can separate them with comma's before the colon or you can omit the ones where insignificant changes where made. Ideally you split the commits up per such component. For example if you made changes to the SPARQL endpoint to support a new feature of the filesystem indexer, commit first to the libtracker-sparql and tracker-store components before committing the dependent filesystem indexer changes. Etcetera: Note that we're as a team very much into keeping our git repository usable and clean as an actual code repository with good commit history. So we're not just using it as a code backup or archive like most software developers do. In principle must every commit compile and work (unit tests and functional tests must all pass). BUT we DON'T like huge commits. Each commit must be reviewable easily. Gerrit style. (Always) work in a branch, do git rebase -i master (or origin) to rebase your branch commits on top of master (and merge them, indeed), and then git push rebasedbranch:master or do git checkout master; git merge rebasedbranch; git push origin master. That or just publish to us your rebasedbranch (on github for example) and then we'll push it. Kind regards, Philip - On Fri, 2013-07-05 at 17:06 +0200, Ralph Böhme wrote: > Hi > > here's another one that adds a /proc/meminfo replacement. > > -Ralph > > _______________________________________________ > tracker-list mailing list > tracker-list@gnome.org > https://mail.gnome.org/mailman/listinfo/tracker-list -- Philip Van Hoof Software developer Codeminded BVBA - http://codeminded.be _______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list