Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 09, 2016 at 10:34:11AM -0700, Junio C Hamano wrote:

> >    The threading in GitHub comments and pull requests is also not great.
> >    Each PR or issue is its own thread, but it's totally flat inside.
> >    There are no sub-threads to organize discussion, and it's sometimes
> >    hard to see what people are replying to.
> 
> It may be a good UI that is optimized for drive-by contributors.  It
> is just that it is not very well suited (compared to mailing list
> discussions) to conduct high-volume exchange of ideas and changes
> efficiently.

I think that's something to ponder; can we have a workflow where
drive-by contributors can use something that has a lower learning/setup
curve, but long-term contributors might opt for something more powerful?

I think SubmitGit is a step in that direction. It does still require
switching to the mailing list for subsequent conversation, though. It
would be interesting to see something like SubmitGit that puts its own
email in the "From", and that processes email replies into PR comments,
and then subsequent PR comments into emails (i.e., part of my "dream tool"
from earlier). It's not clear to me whether the result would just end up
being irritating for both sides to use (because it doesn't _quite_
conform to the norms of each format). But it would be fun to find out.

-Peff
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]