[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Updates to ch02.xml

From: <cmpilato_at_collab.net>
Date: 2003-08-17 19:06:01 CEST

"Matt Blais" <mblais1@yummage.com> writes:

> Actually I was expecting someone to proof my changes, since it's
> generally accepted where I come from that it's not a reasonable
> expectation for a person to be able to proof their own writing.

Yeah, I think that holds pretty much universally.

> I'm a bit confused as to how things work around here. What are the
> standards for accepting patches (and docs, specifically), and who
> decides? I'm feel like I'm getting different opinions about what sort
> of changes are welcome. I thought I read the docs regarding "How to
> help out" with Subversion, but now I'm feeling like I must have missed
> something.

All *suggestions* for changes are welcome -- not all changes. As for
review, that's pretty much ad-hoc. If someone feels like reviewing
your changes (either because they feel they have enough expertise with
the thing being changed, or because they need a break from other
tasks, or because the change purports to scratch some generally felt
itch), they will. If the patch doesn't get reviewed, our patch
manager will file an issue in the database (so the patch doesn't get
lost in the dust and cobwebs of the mail archives).

The general public is free to review any patches they see fit to
review, but of course, they can't actually commit patches unless
they have commit access. So, typically, review is done by someone
with commit access. If the reviewer likes your changes --
essentially, if the reviewer is willing to have his/her reputation
attached to those changes -- your patch will get committed.
Otherwise, you'll get feedback on the patch about what was liked and
not liked, technically or conceptually or both.

Sometimes your patch will get the review of multiple folks, who are
free to argue amongst themselves about the goodness of the approach or
the change itself. At that point, as a patch submitter, it's best to
wait for the fallout to settle and see what the agreed-upon route to
take happens to be.

Yeah, it may be unstructured, but somehow it works. I think most of
our committers have a good feel for what's important enough to spend
cycles on, and what kinds of changes will be controversial.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 17 19:09:11 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.