Re: [Tracker] tracker-miner-rss 0.3

[Philip Van Hoof <spam pvanhoof be>]

On Wed, 2010-01-27 at 03:20 +0100, Roberto -MadBob- Guido wrote:
> On Wed, 2010-01-27 at 01:38 +0100, Philip Van Hoof wrote:
> > Would you guys be interested in getting this piece of software into
> > Tracker's repository and project?
 
> This may be interesting, I've just some consideration:

Sure

> - do you not have problems adding more external dependencies? Given that
> the compilation of miner-rss may be switched at ./configure time, I
> suppose libgrss will stay outside your repository (it is not pertinent
> with Tracker itself ;-) ). If you are ok, I'm ok: this was just an alert
> about extra dependencies miner-rss has

We can probably deal with it if we make all those new dependencies
optional, and only if all dependencies are met then is the subdir of
tracker-miner-rss compiled. AC_CONDITIONAL or something ;)

> - libgrss API is not stable yet, and by sure will change soon. Code may
> need to be aligned often, especially in near future: this is a
> relatively young project, many refinements are needed. This is to make
> you aware of the moving target it is at the moment

Sure, a library being a young project is less of a problem. What they do
need to do is make regular releases, though. And put a proper .pc file
at the right place and stuff like that ;), so that we can easily make it
an optional dependency.

Else we need to pull in their code into our repository. Which is far
from nice (and called forking).

> - we would like to continue work on the miner-rss, especially now we are
> considering a feed reader depending on it in our schedule. But I suppose
> giving away commit power for the Tracker's repository to people is not
> so easy. Is it possible to permit us to handle the project with how
> little limitations possible? Do your team has resources enough to sync
> with us?

Giving out commit power comes down to requesting a GNOME git account and
getting our consent that you are the maintainer of that subdirectory,
together with some reasonable maintainer-rules that we have ourselves.

Rules like that every merge or commit going to master should have had at
least one review of at least one of the other maintainers.

And rules that we usually do feature development in feature branches.
And that each individual commit in master should be consistent and not
break the software (and especially not break the unit tests) (so learn
about `git rebase -i master` :-p)

In said feature branches you can go ahead. We're not dirty of feature
branches. Just make them and push (to) them often and fast if you prefer
working that way.

> So said, I've not particular problems about inclusion of this code in
> the Tracker mainstream, and I thank for your attention ;-)

Okay. For me it's okay to in that case begin the process on bringing it
to our master repository!

If you need a sponsor for GNOME git accounts, you can for example
mention the Tracker project (and me, if you need an individual
sponsoring for you. I don't remember the exact rules, you can find them
on a live.gnome.org page somewhere. If you need multiple sponsors then
I'm sure the other guys on our team can help out too).

You can prepare the work in a branch, and ask for a review for pushing
the merge to master.

You can also do this work on a gitorious clone, of course. We have the
git wizards who can cope with distributed remote git repositories ;)


ps. If anyone on the team has objections, respond! JÃrg, Martyn, Mikael,
Ivan, Carlos? Jamie?


Cheers,

Philip

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be