Lea Wiemann <lewiemann@xxxxxxxxx> writes: > Should I perhaps stay on my branch with these changes, and then merge > when it has stabilized (in 1-3 months)? > > One thing I'd be concerned about is that I might introduce fundamental > issues in my API, since I'm neither a Git nor a Perl expert (yet > ^^). What's the best way to avoid discovering such issues only at the > Big Merge? First of all, we do not do "Big Merge". We merge small and we merge often. Nobody has perfect foresight, so you shouldn't be too afraid of contaminating the public history with experiments that did not pan out well. > Is there anyone who'd be willing to monitor my commits and > give me feedback on a semi-continuous basis? Isn't it what your GSoC mentor is for ;-)? You can seek wider exposure in various different ways: * Send [RFC] patches to the list; that's how this community is supposed to work, although I do not see as much reviews as I would personally want to see from other people these days for some reason [*1*]. I may pick up "next" worthy ones to "next", and perhaps other ones to "pu" as time permits. * Have your repository on repo.or.cz (I thought GSoC student project for git were supposed to be hosted there?) People interested in Perl interface in general and Gitweb in particular can try your progress out. [Footnote] *1* I suspect that maybe there is a misconception that patch submission and review on the list is a dialogue between the submitter and the maintainer. It is _NOT_ the case. I'd rather stay back, sipping my Caipirinha, listening to _other_ people argue and improve the submitted patches, while occasionally giving some guidance to the course of the discussion. And when the polished result emerges finally, apply it to my tree, taking all the credit. _That_ is how the community is supposed to work, isn't it? ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
