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 _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
