Helping on Git development

Helping on Git development

[Eduardo D'Avila]

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

Re: Helping on Git development

[Andrew Ardill]

On 14 September 2011 13:05, Eduardo D'Avila <erdavila@gmail.com> wrote:
> 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. :-)

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

Re: Helping on Git development

[Junio C Hamano]

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

> On 14 September 2011 13:05, Eduardo D'Avila <erdavila@gmail.com> wrote:
>> 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. :-)
>
> 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

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.

Re: Helping on Git development

[Jonathan Nieder]

Junio C Hamano wrote:

> 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):
[...]
>  - 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
[...]
>  - 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.

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.

Re: Helping on Git development

[Jeff King]

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

> 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):

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

Re: Helping on Git development

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Sep 14, 2011 at 11:29:28AM -0700, Junio C Hamano wrote:
>
>> 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):
>
> Is there such a thing as enough coders? :)

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).

>   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.

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.

Re: Helping on Git development

[Jeff King]

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

> > Is there such a thing as enough coders? :)
> 
> Ever heard of the Mythical Man-Month ;-)?

I thought git was a silver bullet. :)

> 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).

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.

> >   2. Read the list. People will report bugs. Try reproducing them,
> [...]
> 
> 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.

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

Re: Helping on Git development

[Andrew Ardill]

On 15 September 2011 10:08, Jeff King <peff@peff.net> wrote:
> On Wed, Sep 14, 2011 at 04:34:38PM -0700, Junio C Hamano wrote:
>
>> > Is there such a thing as enough coders? :)
>>
>> Ever heard of the Mythical Man-Month ;-)?
>
> I thought git was a silver bullet. :)
>
>> 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).
>
> 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.
>
>> >   2. Read the list. People will report bugs. Try reproducing them,
>> [...]
>>
>> 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.
>
> 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
>

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

>> 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
>
> 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.

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

Re: Helping on Git development

[Junio C Hamano]

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.
>
> Would a link to the wiki be more appropriate? Perhaps even a 'getting
> started' page that collates information like this?
> ...
> When kernel.org comes back online I may have a go at creating such a
> page. Any thoughts?

"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 ;-).

Re: Helping on Git development

[Jeff King]

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

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

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