Lea Wiemann <lewiemann@xxxxxxxxx> writes:
> 1. I'm working full-time on this, so I might produce patches that
> loosely depend on one another at a peak rate of 2-3 per day. (I can
> do other project-related stuff while my patches are waiting for
> review, but only so much of course.) Do you have any experience with
> working with full-time developers on Git? Do you see problems with my
> potentially high patch frequency?
As long as experienced people on the list review patches, I do not see a
problem.
There seems to be a misconception (not you particularly but some parts
of the list audience in general) that a review cycle of a patch sent
to the list is a dialog between the submitter and me. It is _NOT_.
If it has rooms for improvements, other people would help you polish
it, which happens often. However, if it is very well done, I'd also
like other people to say so after reviewing more often.
> 2. I'll be changing my own API. In other words, the API is really
> unstable while I work on this (with the only user of the API being
> Gitweb, which I'll update as I go). Is that OK for the pu branch?
It does not _have_ to even land on 'pu'. Sending the patches to the list,
asking interesting parties to look at them, _and_ having people actually
review them is more valuable part.
If your series will become big, I do not mind (re)merging it from time to
time in 'pu' to give it a wider exposure. If you want to go this route,
you would have a publicly fetchable repository of your own to house your
changes (repo.or.cz?).
I do not even mind merging the branch to 'next' if the series is 'next'
worthy, but that places heavier responsibility on your part to keep the
history of that branch clean.
> 3. I try to be careful with my commits, but it might still cause more
> work for whoever reviews my patches, compared to reviewing larger
> chunks. (That's because some of the stuff I write might end up being
> deleted or rewritten later.)
One thing you could do, when sending out [PATCH v$n] for the value of $n
greater than 1, is to mention what the improvements are since the previous
round in the message (typically after the three-dash separator). This
helps reviewers who have already seen your previous iteration. The full
rationale of the change needs to be kept in the proposed commit log
message.
For example, your first patch may look like this:
Subject: [PATCH] Git.pm: Add rev_parse() sub
This adds a rev_parse() sub to return the 40-byte object name
from given "extended SHA-1" expression.
Signed-off-by: A U Thor <au.thor@xxxxxxxxxxx>
---
<<diffstat and patch>>
Then after Pasky and others suggest improvements, your second message will
appear on the list:
Subject: [PATCH v2] Git.pm: Add parse_rev()
This adds 'parse_rev()' sub to return the 40-byte object name from
given "extended SHA-1" expression. It returns undef if the given
string is malformed.
Signed-off-by: A U Thor <au.thor@xxxxxxxxxxx>
---
Changes relative to v1 are:
* Fixed indentation;
* Use -q to squelch non-fatal errors so that they do not leak
to the STDERR;
* Improved in-code documentation.
<<diffstat and patch>>
Some people also sends an interdiff between v$n-1 and v$n as a separate
message, and it helps reviewing when the change is big.
--
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
