From: Jeff King <peff@peff.net>
To: Christian Couder <chriscool@tuxfamily.org>
Cc: git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>,
Junio C Hamano <gitster@pobox.com>,
Scott Chacon <schacon@gmail.com>,
Sam Vilain <sam.vilain@catalyst.net.nz>,
Petr Baudis <pasky@suse.cz>
Subject: Re: GitTogether topics status (4th of October)
Date: Mon, 6 Oct 2008 23:15:09 -0400 [thread overview]
Message-ID: <20081007031509.GA6031@coredump.intra.peff.net> (raw)
In-Reply-To: <200810041816.41026.chriscool@tuxfamily.org>
On Sat, Oct 04, 2008 at 06:16:40PM +0200, Christian Couder wrote:
> As can be seen on the GitTogether page on the wiki:
>
> http://git.or.cz/gitwiki/GitTogether
>
> the planned speakers/topics changed a lot during the last weeks and are now:
I just added two proposed half-hour meetings, both of which I intend to
be a few minutes of me talking followed by group discussion. The topics
are:
1. Helping new developers join the git community
This title is a little bit sneaky. I want to talk about not just how
we can get new developers to help improve git, but also how we can
convince them to adopt workflows that make less work for reviewers
and maintainers. It seems like there are some things that we tell
new people over and over about formatting code, formatting patches,
sending patches, etc. Probably the end goal will be improvements to
SubmittingPatches, but maybe putting similar content somewhere more
visible, or maybe even adjusting our workflows a bit.
I hope to make it useful for veterans (who may _constructively_
complain about the habits of new developers), and new developers,
who may learn something about contributing.
This might overlap a bit with Dscho's "contributing with git" talk
(which I am not sure is a talk about using git to contribute in
general, or using git to contribute to git), but I think the
discussion-like forum will make it different enough to be valuable.
2. What needs refactoring?
I occasionally run up against parts of the code that just make my
eyes bleed everytime I touch them. I think we've made significant
progress in maintanability and bug-avoidance with things like the
strbuf library, refactoring of remote and transport handling, etc.
What areas might still benefit from such refactoring?
-Peff
next prev parent reply other threads:[~2008-10-07 3:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-04 16:16 GitTogether topics status (4th of October) Christian Couder
2008-10-07 3:15 ` Jeff King [this message]
2008-10-07 3:46 ` Nicolas Pitre
2008-10-07 14:38 ` Shawn O. Pearce
2008-10-07 14:46 ` Shawn O. Pearce
2008-10-17 19:18 ` René Scharfe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081007031509.GA6031@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pasky@suse.cz \
--cc=sam.vilain@catalyst.net.nz \
--cc=schacon@gmail.com \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).