Re: [Tracker] Another Solaris patch

[Philip Van Hoof <philip codeminded be>]

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