Re: [char-misc-next] mei: request async autosuspend at the end of enumeration
W dniu 25.11.2016 o 04:14, Jeff King pisze: > On Thu, Nov 24, 2016 at 10:37:14PM +, Winkler, Tomas wrote: > >>>>> Cc: <sta...@vger.kernel.org> # 4.4+ >>>> >>>> Looks like git send-email is not able to parse this address correctly >>>> though this is suggested format by Documentation/stable_kernel_rules.txt. >>>> Create wrong address If git parsers is used : 'sta...@vger.kernel.org#4.4+' [...] > The patch just brings parity to the Mail::Address behavior and git's > fallback parser, so that you don't end up with the broken > sta...@vger.kernel.org#4.4+ address. Instead, that content goes into the > name part of the address. > > It sounds like you want the "# 4.4+" to be dropped entirely in the > rfc822 header. It looks like send-email used to do that, but stopped in > b1c8a11c8 (send-email: allow multiple emails using --cc, --to and --bcc, > 2015-06-30). > > So perhaps there are further fixes required, but it's hard to know. The > input isn't a valid rfc822 header, so it's not entirely clear what the > output is supposed to be. I can buy either "drop it completely" or > "stick it in the name field of the cc header" as reasonable. Well, we could always convert it to email address comment, converting for example the following trailer: Cc: John Doe <j...@example.com> # comment to the following address: John Doe <j...@example.com> (comment) Just FYI. Though I'm not sure how well this would work... Best, -- Jakub Narębski
Re: [char-misc-next] mei: request async autosuspend at the end of enumeration
W dniu 25.11.2016 o 04:14, Jeff King pisze: > On Thu, Nov 24, 2016 at 10:37:14PM +, Winkler, Tomas wrote: > >>>>> Cc: # 4.4+ >>>> >>>> Looks like git send-email is not able to parse this address correctly >>>> though this is suggested format by Documentation/stable_kernel_rules.txt. >>>> Create wrong address If git parsers is used : 'sta...@vger.kernel.org#4.4+' [...] > The patch just brings parity to the Mail::Address behavior and git's > fallback parser, so that you don't end up with the broken > sta...@vger.kernel.org#4.4+ address. Instead, that content goes into the > name part of the address. > > It sounds like you want the "# 4.4+" to be dropped entirely in the > rfc822 header. It looks like send-email used to do that, but stopped in > b1c8a11c8 (send-email: allow multiple emails using --cc, --to and --bcc, > 2015-06-30). > > So perhaps there are further fixes required, but it's hard to know. The > input isn't a valid rfc822 header, so it's not entirely clear what the > output is supposed to be. I can buy either "drop it completely" or > "stick it in the name field of the cc header" as reasonable. Well, we could always convert it to email address comment, converting for example the following trailer: Cc: John Doe # comment to the following address: John Doe (comment) Just FYI. Though I'm not sure how well this would work... Best, -- Jakub Narębski
[ANNOUNCE] Git User's Survey 2016
Hello all, Git is distributed version control system, created for Linux kernel development by Linus Torvalds. Maintainership of Git was soon passed to Junio C Hamano. Chances are, if you are Linux kernel developer, you are using Git. We would like to ask you a few questions about your use of the Git version control system. This survey is mainly to understand who is using Git, how and why. It would be interesting to hear how Git is used by Linux kernel developers. The results will be published to the Git wiki on the GitSurvey2016 page (https://git.wiki.kernel.org/index.php/GitSurvey2016) and discussed on the git mailing list (g...@vger.kernel.org). The survey would be open from 12 September to 20 October 2016. Please devote a few moments of your time to fill this simple questionnaire, it will help a lot the git community to understand your needs, what you like of Git, and of course what you don't like. The survey can be found here: https://tinyurl.com/GitSurvey2016(easy to remember) https://survs.com/survey/ulcu05whhi There is also alternate version which does not require cookies, or JavaScript, but in turn it doesn't allow one to go back to your response and edit it (different from other channels): https://tinyurl.com/GitSurvey2016-anon https://survs.com/survey/naeec8kwd8 P.S. At request I can open a separate channel in survey, with a separate survey URL, so that responses from particular site or organization could be separated out. A few companies already made use of this opportunity (Ericsson, Booking.com, Autodesk). Please send me a email (to jna...@gmail.com) with name of channel, and I will send you a separate survey URL to use. Note that the name of the channel would be visible to others, unless you request it not to be. P.P.S. Different announcements use different URLs (different channels) to better track where one got information about this survey. Thanks in advance for taking your precious time to answer the survey, -- Jakub Narębski on behalf of Git Development Community g...@vger.kernel.org
[ANNOUNCE] Git User's Survey 2016
Hello all, Git is distributed version control system, created for Linux kernel development by Linus Torvalds. Maintainership of Git was soon passed to Junio C Hamano. Chances are, if you are Linux kernel developer, you are using Git. We would like to ask you a few questions about your use of the Git version control system. This survey is mainly to understand who is using Git, how and why. It would be interesting to hear how Git is used by Linux kernel developers. The results will be published to the Git wiki on the GitSurvey2016 page (https://git.wiki.kernel.org/index.php/GitSurvey2016) and discussed on the git mailing list (g...@vger.kernel.org). The survey would be open from 12 September to 20 October 2016. Please devote a few moments of your time to fill this simple questionnaire, it will help a lot the git community to understand your needs, what you like of Git, and of course what you don't like. The survey can be found here: https://tinyurl.com/GitSurvey2016(easy to remember) https://survs.com/survey/ulcu05whhi There is also alternate version which does not require cookies, or JavaScript, but in turn it doesn't allow one to go back to your response and edit it (different from other channels): https://tinyurl.com/GitSurvey2016-anon https://survs.com/survey/naeec8kwd8 P.S. At request I can open a separate channel in survey, with a separate survey URL, so that responses from particular site or organization could be separated out. A few companies already made use of this opportunity (Ericsson, Booking.com, Autodesk). Please send me a email (to jna...@gmail.com) with name of channel, and I will send you a separate survey URL to use. Note that the name of the channel would be visible to others, unless you request it not to be. P.P.S. Different announcements use different URLs (different channels) to better track where one got information about this survey. Thanks in advance for taking your precious time to answer the survey, -- Jakub Narębski on behalf of Git Development Community g...@vger.kernel.org
Re: [ANNOUNCE] git-series: track changes to a patch series over time
W dniu 11.08.2016 o 00:07, Josh Triplett pisze: > On August 9, 2016 11:37:31 PM HST, Richard Ipsum > <richard.ip...@codethink.co.uk> wrote: >> On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote: [...] >>> If you use a format-patch diff that includes the headers and >>> commit message, you could also support commenting on those in the >>> same way. Does the notedb format support commenting on those? >> >> Comments in notedb are just a git note keyed on the sha of the >> commit being commented on, I'm not certain what advantage a >> format-patch diff provides in this case? > > I meant for opening in an editor to write email-reply-style comments. > The review tool and review storage format should allow commenting on > commit messages, not just diffs. There is also cover letter and interdiff, and one would want to be able to comment also on those. So how notedb solve problem of in-diff comments, in-commit comments, post-commit comments, whole series cover letter and cover-letter comments, interdiff and interdiff message / comments? Nb. GitHub Pull Requests include only some of those, compared to the mailing list / Usenet news interface. >> I've been closely following the 'patch submission process' thread, >> and given the discussion there I'm having doubts over the value of >> comments in git-candidate vs the mailing list. It seems to me that >> git-candidate has many of the disadvantages of Github/Gitlab when >> it comes to comments, for example, there is no threading. > > That's not inherent, though. You could allow commenting on a comment > easily enough. (Of course, at some point you've recreated email-style > in-reply-to headers...) I wonder if we could use 'parent' header of a commit message for this, or equivalent... >> Also the system would be less open than the mailing list, since, as >> it stands currently you would require push access to the >> repository to comment on anything. > > You'd need a federation mechanism. ...which is as easy to set up and use as mailing list, for sending patches, applying patches, and patch review. And/or provide bi-directional interface to the mailing list (I think Debian infrastructure tries to be (inter)operable by email). There are various federated technologies (like pump.io), the problem might be their popularity. >> It may be worth reflecting that one reason some organizations have >> switched away from mailing list reviews to Github/Gitlab is that >> they provide patch tracking, where the mailing list provides none, >> so patches there can be 'lost'. So instead of trying to >> reimplement an entire Gerrit/Github/Gitlab UI on the commandline, I >> wonder whether it would be sufficient to add the minimum >> functionality necessary to provide git with native patch tracking, >> and leave comments for the mailing list. Of course this is exactly >> what git-series seems to do, so in some sense I may be advocating >> dropping my own work in favour of improving git-series. > > I think the two serve different (though related) functions. I'd love > to be able to use a text editor and command-line tool to produce and > submit comments to systems like Gerrit or GitHub. I think there are command-line tools that allow to submit comments to GitHub. -- Jakub Narębski
Re: [ANNOUNCE] git-series: track changes to a patch series over time
W dniu 11.08.2016 o 00:07, Josh Triplett pisze: > On August 9, 2016 11:37:31 PM HST, Richard Ipsum > wrote: >> On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote: [...] >>> If you use a format-patch diff that includes the headers and >>> commit message, you could also support commenting on those in the >>> same way. Does the notedb format support commenting on those? >> >> Comments in notedb are just a git note keyed on the sha of the >> commit being commented on, I'm not certain what advantage a >> format-patch diff provides in this case? > > I meant for opening in an editor to write email-reply-style comments. > The review tool and review storage format should allow commenting on > commit messages, not just diffs. There is also cover letter and interdiff, and one would want to be able to comment also on those. So how notedb solve problem of in-diff comments, in-commit comments, post-commit comments, whole series cover letter and cover-letter comments, interdiff and interdiff message / comments? Nb. GitHub Pull Requests include only some of those, compared to the mailing list / Usenet news interface. >> I've been closely following the 'patch submission process' thread, >> and given the discussion there I'm having doubts over the value of >> comments in git-candidate vs the mailing list. It seems to me that >> git-candidate has many of the disadvantages of Github/Gitlab when >> it comes to comments, for example, there is no threading. > > That's not inherent, though. You could allow commenting on a comment > easily enough. (Of course, at some point you've recreated email-style > in-reply-to headers...) I wonder if we could use 'parent' header of a commit message for this, or equivalent... >> Also the system would be less open than the mailing list, since, as >> it stands currently you would require push access to the >> repository to comment on anything. > > You'd need a federation mechanism. ...which is as easy to set up and use as mailing list, for sending patches, applying patches, and patch review. And/or provide bi-directional interface to the mailing list (I think Debian infrastructure tries to be (inter)operable by email). There are various federated technologies (like pump.io), the problem might be their popularity. >> It may be worth reflecting that one reason some organizations have >> switched away from mailing list reviews to Github/Gitlab is that >> they provide patch tracking, where the mailing list provides none, >> so patches there can be 'lost'. So instead of trying to >> reimplement an entire Gerrit/Github/Gitlab UI on the commandline, I >> wonder whether it would be sufficient to add the minimum >> functionality necessary to provide git with native patch tracking, >> and leave comments for the mailing list. Of course this is exactly >> what git-series seems to do, so in some sense I may be advocating >> dropping my own work in favour of improving git-series. > > I think the two serve different (though related) functions. I'd love > to be able to use a text editor and command-line tool to produce and > submit comments to systems like Gerrit or GitHub. I think there are command-line tools that allow to submit comments to GitHub. -- Jakub Narębski
