On 08/01/2012 02:56 PM, Prasanna Santhanam wrote:
On Wed, Aug 01, 2012 at 08:42:51AM -0400, Rohit Yadav wrote:
On Aug 1, 2012, at 5:46 PM, Wido den Hollander <w...@widodh.nl> wrote:
On 08/01/2012 04:50 AM, Alex Huang wrote:
So currently, there are three ways for a patch to be received:
1. Email (see the workflow Wido proposed) 2. Reviewboard 3. Submitted
with a bug.
Email and ReviewBoard are the most visible, and it seems most people are
using ReviewBoard rather than email.
We should remove the email and submit with a bug options.
Are you sure? For larger patches I agree that e-mail isn't that easy,
but it seems to work with various other projects.
I personally like e-mail and 'hate' all kinds of various systems where I
have to log in with different credentials.
I totally agree with Wido, besides the review board workflow has a serious
ownership issue:
When I submit a git formatted patch it would strip the commit
message and author info, signature and retain only the unified diff.
The reviewer and/or committer have to do the extra work of
downloading the patch, applying/verifying it and then committing it.
During the process they may change the original commit message and
author signature (and they lose their ohloh points :)
Further, the contributor is then required to go back and close the
submission. Well one can use their mailbox from where they can
import the patches, git am works. Or when the committer is
downloading the diff anyway, why not download the actual git
formatted patch emailed by an author and git apply? Just a
suggestion.
This was tried in the past and backfired when non-committers send
through patches that get formatted by mail clients and have CRLF
issues when applied by the committer.
I think this happens when people attach their patches, but if you send
them with "git send-email" they will go through just fine.
HTML mail clients and stuff make garbage of patches. That's why I'm
again HTML e-mail on this mailinglist.
I agree Reviewboard has extra workflow involved but it integrates the
review comments closely with the mailing list so it isn't as different
from patches in the email in my opinion. It additionally provides
pretty diff tools online. If not I would have to put the patch through
my own diff tool.
The current pain points as I see are :
1) ReviewBoard removes the author information from the diff
2) git am doesn't always work
Again, I think because people did not use "git send-email"
3) extra workflow step of submitter closing the patch request
These probably should be addressed by tooling.
Do you mean reviewboard tooling or tooling for patches through e-mail?
Wido
If somebody finds a typo or small bug, should they really go through all
the hoops for submitting a small patch?
Imho that shouldn't be necessary.
Wido
