Karl Fogel wrote:
> "C. Michael Pilato" <cmpilato@collab.net> writes:
>> Exactly. You can't see the diffs when Karl squirrels away patches in his
>> local disk, either, and that's fine. What matters is the change dropped
>> into a live branch -- that's the diff to review. If Karl wants early
>> feedback on his work in progress, then he needs to use a regular feature
>> branch and work within the established policies for commits to our tree.
>
> Things are not quite so easily defined, I think.
>
> For example, attaching successive patches to an issue has never part
> of our process, but I've been doing it (for off-site backups, and to
> provide review opportunities to anyone intensely interested in that
> issue's progress).
>
> 90% of the time, I'm the only one watching those patches. But every
> now and then, I do get reviews, and they're helpful (it happened most
> recently in issue #2959, with both dlr and vgeorgescu). Did I "want"
> those reviews? Well, I didn't expect them, but I was glad to get
> them.
Great benefit to preserve, absolutely. But the nature of our issue tracker
and patch attachments to it are such that folks don't choose to offer their
unsolicited review because the patch flashed across their eyes while reading
email. 'svn diff -c SOME-REV URL-OF-CHECKPOINTS' is no harder for the
competent than launching a web browser and viewing a patch there.
> So there can be fine gradations of desire/need for review. I think
> Justin's instincts are right, that if there's going to be a review
> opportunity at all, we should at least try to make it easy.
And that's the right attitude to have. FWIW, I'd be perfectly happy with
reverting the special mailer changes on svn.collab.net and just having a
sort of known policy that in /checkpoints, our commit policies aren't as strict.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Mon Oct 15 23:18:29 2007