Helping on Git development

Hi,

I have being using Git for some time now and I am very satisfied with it. Now I'm considering giving back by helping on its development. Is there any bug listing which I can check if there is some point I can help? Any suggestions on other ways to help are also welcomed. :-)

Thanks,

Eduardo R. D'Avila

On 14 September 2011 13:05, Eduardo D'Avila <erdavila@gmail.com> wrote:

Hi Eduardo, as stated in the README,

The messages titled "A note from the maintainer", "What's in git.git (stable)" and "What's cooking in git.git (topics)" and the discussion following them on the mailing list give a good reference for project status, development direction and remaining tasks.

Additionally, I think the README should include something like

If you are looking to contribute to the project, a good place to start is http://git-blame.blogspot.com/p/note-from-maintainer.html and in Documentation/howto/maintain-git.txt

because it took me forever to find them, and contributing will be difficult until you have read them.

Regards,

Andrew Ardill

Andrew Ardill <andrew.ardill@gmail.com> writes:

I am moderately averse to hardcoding that URL that is guaranteed not to survive the maintainer change in our README file. The howto/maintain-git document mentions the periodical "A note from the maintainer" posting to the list that has the same text, which is a more appropriate reference.

As to contributing to the project, right now, I think we have enough people who want to write code and documentation for Git, but what we lack are bandwidth to (this is not meant to be an exhaustive list):

 - review the patches on the list and help perfecting them;

 - distilling random wishes from the end user community while winnowing
   chaffs that are unrealistic or do not fit well with the grand scheme of
   things, to come up with a concrete proposal and a patch series to move
   the discussions forward in a productive way;

 - "on boarding" new contributors, helping them to become a useful member
   of the community, teaching how to write a good bug report and how to
   sell a new feature (i.e. "the perfect patch");

 - dig list archives to point people at age-old discussions to non-issues
   that have long been resolved to squelch noise; and

 - remind original submitter, people who were involved in the discussion,
   and people who should have been involved but who weren't, of a worthy
   but stalled topics from time to time.

The first two need to come from more experienced folks whose judgement I can trust (iow, not a newbie task). Others are "project secretary" tasks that can be helped by anybody who is good at tracking things, perhaps except for the last one that needs a good taste when judging which topic is worthy of reminders.

Junio C Hamano wrote:

[...]

[...]

I also should (reluctantly) mention that the Debian bug tracker has been accepting bugs from outsiders and provides a service like this. Caveats:

 - it only tracks bugs that affect Debian (usually meaning
   platform-independent bugs).  Occasionally bugs from Windows users
   have been reported there and it's been okay.

 - the interface might seem quirky if you're not used to it.
   Documentation is at http://www.debian.org/Bugs/

 - no guarantee of a quick response.  When there is a response,
   usually it is "here are some thoughts; now let's take this to
   git@vger.kernel.org".

 - if the bugtracker gets swamped with reports from outside without
   manpower to match, the policy re bugs from outside Debian might
   change.

Bug listing: [1]. To subscribe to receive bug reports by email: [2].

Thoughts welcome, as always. Jonathan

[1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=git;include=tags:upstream;exclude=tags:fixed-upstream;exclude=tags:moreinfo;exclude=severity:wishlist
[2] http://www.debian.org/doc/manuals/developers-reference/resources.html#pts-commands
Summary: an email to pts@qa.debian.org whose body contains the two
lines "subscribe git", "keyword git = bts" would do the trick.

On Wed, Sep 14, 2011 at 11:29:28AM -0700, Junio C Hamano wrote:

Is there such a thing as enough coders? :)

Two things that got me started on git, and that I think are still relevant today:

  1. Scratch your own itch. Surely git doesn't do something that you
     wish it did. Or did it faster. Or whatever. Try to dig up past
     discussions on the list to make sure you're not doing something
     that has already been tried and rejected, and then start hacking.
     Your patches may be terrible at first, but I think there are people
     willing to guide you if you actually have running code.

  2. Read the list. People will report bugs. Try reproducing them,
     bisecting them, creating minimal test cases, narrowing the issues
     down to certain configurations or a certain bit of code, etc.
     Sometimes that will lead you to propose a solution. Sometimes
     you'll just add to the discussion, and then somebody with more
     familiarity can pick up the topic from there. But you'll have
     helped them by doing some of the work, and you'll have learned more
     about how git works.

-Peff

Jeff King <peff@peff.net> writes:

Ever heard of the Mythical Man-Month ;-)?

I thought it was clear from my message but probably I wasn't clear enough, so let's make it clear. I didn't mean to ay "we have enough -- we need no more -- we reject new applicants".

I was simply saying that there already are many people who scratch his own real itch, and we are short of the bandwidth to review them all. It would not help the project at all to add more people who scratch some random non-itches that nobody is actually interested in (e.g. an entry in an unmaintained "bug tracker" that may list irrelevant and stale non issues).

Yes. In the earlier steps in the above, you may find out that the report was actually not a bug at all (e.g. old issue that has long been fixed, pebcak, or wrong expectation), but even in such a case, reporting your finding would help others.

On Wed, Sep 14, 2011 at 04:34:38PM -0700, Junio C Hamano wrote:

I thought git was a silver bullet. :)

Yeah, that may be. But I don't look at it as "we have enough itch-scratchers, so we don't need more". I see it as survival of the fittest. You may post a patch series that needs a lot of help, but nobody else cares, and it dies off. Or your series may be interesting enough that it draws attention, to the detriment of somebody else's series (which may take longer to get reviewed and merged). But natural selection only works if we have a diverse population to select from.

The downside, of course, is that somebody may end up wasting time going down a fruitless road. But for a new contributor, hopefully they learn something in the process.

Very much agreed. I think big organizations like mozilla have people who do nothing but bug triage. We are not that big, but it has proven to be one area that is easy to break out and distribute to other people.

-Peff

On 15 September 2011 10:08, Jeff King <peff@peff.net> wrote:

Does git even have an issue tracker? I have not seen one anywhere.

Would a link to the wiki be more appropriate? Perhaps even a 'getting started' page that collates information like this?

At the moment, while it is easy enough to find the information needed to understand how the project fits together if you know where to look, there isn't any concise summation of roles and pain points. The note from the maintainer goes over the procedures fairly well, and the what's cooking gives a good idea of what features are being worked on, but it seems a little disconnected.

When kernel.org comes back online I may have a go at creating such a page. Any thoughts?

Andrew

Andrew Ardill <andrew.ardill@gmail.com> writes:

"Getting started" that describes how they got started, collectively maintained by people who got started recently, may serve as a good guide for people who follow. And if it is done as a wiki, you are free to create and update without asking permission from the community ;-).

On Thu, Sep 15, 2011 at 04:24:22PM +1000, Andrew Ardill wrote:

No. The general philosophy so far has been that the mailing list serves the same purpose, and that if messages go by without comment on the list, it's probably because they weren't that interesting to people (i.e., in a bug tracker, they would have also sat untouched).

That being said, the mailing list is free-form, which can make it harder to search and analyze. Something that organizes the information like a bug tracker could be useful, but only if somebody (or somebodies) is dedicated to keeping the information up to date and free of cruft.

-Peff