Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
Hi Nicolas, On Tue, 19 Sep 2017, Nicolas Morey-Chaisemartin wrote: > Le 19/09/2017 à 17:43, Johannes Schindelin a écrit : > > > > C'mon, don't *try* to misunderstand me. > > > > Of course there need to be updates as to the state of patch series. > > > > It's just that mails only go *so* far when you need to connect and > > aggregate information. You need the connection between the original patch > > series, the latest unaddressed reviews, links to the branches, history of > > the patch series' iterations, and ideally links to the repositories of the > > contributors with *their* branch names. And then, of course, your verdict > > as to the state of the patch series and your expectation what happens > > next. > > > > To relate that, you are using a plain text format that is not well defined > > and not structured, and certainly not machine-readable, for information > > that is crucial for project management. > > > > What you need is a tool to aggregate this information, to help working > > with it, to manage the project, and to be updated automatically. And to > > publish this information continuously, without costing you extra effort. > > > > I understand that you started before GitHub existed, and before GitHub was > > an option, the script-generated What's cooking mail was the best you could > > do. > > Would something like patchwork fix your need ? Maybe. Here is the link, for other interested parties: http://jk.ozlabs.org/projects/patchwork/ and https://github.com/getpatchwork/patchwork > They now seems to have a REST API, which means it could probably be > pluggeg into Junio's scripts and work seemlessly for him (or any other > happy ML user) while other people can browse through the web interface. It seems that patchwork's design calls for the communication still being performed as previously, and just providing a web interface to search a little more efficiently through the mails containing patch submissions. Git's mailing list, of course, poses the problem to patchwork that the status of any patch series is opaque to any automatic system that does not specifically try to connect the What's cooking dot to the patch mail dots. Also, a point that came up in a private discussion with another core Git contributor this week: how many reviewers actually even so much as test-compile, let alone look at the code in context? I am fairly certain that none do, *just* because of the shortcomings of the process. Patchwork would not address this, of course. In my ideal world (in which there would be world peace, too, so it would be pretty boring, therefore you should not put much stock into what I am saying next), the direction would be the other way round: the tool should not scrape the mailing list and make the results accessible via web interface. Instead, the tool would let me sidestep the mailing list altogether, using it just as a lossy communication medium (and keep the lost information accessible in different ways). SubmitGit "threatened" to allow me to do this: I could open a PR at https://github.com/git/git and then hit a button and off it goes. SubmitGit stops there, though; If it would have continued from there (and did not make the initial step difficult by requiring some registration not everybody is comfortable with), it would have fulfilled my wishes. Alas, it is written in Scala, using a framework I am utterly unfamiliar with, so I could not do anything about it. Ciao, Dscho
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
Hi Jonathan, On Tue, 19 Sep 2017, Jonathan Nieder wrote: > Johannes Schindelin wrote: > > > To relate that, you are using a plain text format that is not well > > defined and not structured, and certainly not machine-readable, for > > information that is crucial for project management. > > > > What you need is a tool to aggregate this information, to help working > > with it, to manage the project, and to be updated automatically. And > > to publish this information continuously, without costing you extra > > effort. > > > > I understand that you started before GitHub existed, and before GitHub > > was an option, the script-generated What's cooking mail was the best > > you could do. > > I think you are subtly (but not directly, for some reason?) advocating > moving project management for the Git project to GitHub Issues. No, I don't. I know how cumbersome it would be to move tons of people over from one type of project management to another. However, the current situation is not really tenable, is it? It is tedious for everybody involved. I know Junio defends the status quo, but I cannot imagine that he really likes it, as too much is too manual and labor-intensive. As I mentioned at the GitMerge (which was a bit pointless, because Junio was not there, not even via Skype), I do not advocate one radical change, ever. > For what it's worth: > > 1. I would be happy to see Git adopt a bug tracker. As we've > discussed on the list before, I suspect the only way that this is > going to happen is if some contributors start using a bug tracker > and keep up with bugs there, without requiring everyone to use it. > That is how the Linux Kernel project started using > bugzilla.kernel.org, for example. I agree that a bug tracker goes a long way. Personally, I feel Bugzilla is way too clunky to use, but I am pampered. However, I could imagine that allowing issues to be opened at https://github.com/git/git, and encouraging bug submissions there for people who really need to be able to find out very, very quickly what the current state of their bug report is, would go a long way. Of course, this would require a commitment by Junio and others to allow discussions to move to that bug tracker from the mailing list. Once that willingness is there, this should be a viable alternative to reporting bugs on the mailing list (and have those reports go unanswered because they fell off the radar...). > 2. GitHub Issues is one of my least favorite bug trackers, for what > it's worth. If some sub-project of Git chooses to use it, then > that's great and I won't get in their way. I'm just providing > this single data point that approximately any other tracker > (Bugzilla, JIRA, debbugs, patchwork) is something I'd be more > likely to use. My experience with Git for Windows, where I try to live Postel's Law by accepting bug reports via mailing list and GitHub issues (and earlier Google Code, when that was still alive and kicking), and to a certain extent even via Twitter: next to nobody likes sending bug reports via mail. So to add to your sentiment, I like Bugzilla *less* than GitHub issues, and the worst bug tracker is a mailing list. Or maybe you have written a shell script that can answer the question "which of my reported bugs/submitted patch series are still open?" for the Git mailing list? > 3. This advice might feel hopeless, because if the maintainer is not > involved in the initial pilot, then how does the bug tracker get > notified when a patch has been accepted? But fortunately this is > a problem other people have solved: e.g. most bug trackers have an > API that can be used to automatically notify the bug when a patch > with a certain subject line appears on a certain branch. Yes, I agree. The willingness to see the problem, followed by the willingness to discuss possible solutions, those two need to be the first steps. Ciao, Dscho
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
Le 19/09/2017 à 17:43, Johannes Schindelin a écrit : > > C'mon, don't *try* to misunderstand me. > > Of course there need to be updates as to the state of patch series. > > It's just that mails only go *so* far when you need to connect and > aggregate information. You need the connection between the original patch > series, the latest unaddressed reviews, links to the branches, history of > the patch series' iterations, and ideally links to the repositories of the > contributors with *their* branch names. And then, of course, your verdict > as to the state of the patch series and your expectation what happens > next. > > To relate that, you are using a plain text format that is not well defined > and not structured, and certainly not machine-readable, for information > that is crucial for project management. > > What you need is a tool to aggregate this information, to help working > with it, to manage the project, and to be updated automatically. And to > publish this information continuously, without costing you extra effort. > > I understand that you started before GitHub existed, and before GitHub was > an option, the script-generated What's cooking mail was the best you could > do. > > Ciao, > Dscho Hi, Would something like patchwork fix your need ? They now seems to have a REST API, which means it could probably be pluggeg into Junio's scripts and work seemlessly for him (or any other happy ML user) while other people can browse through the web interface. I used to work with this one: http://patches.opendataplane.org/project/lng-odp/list/ It is not the best example as the patch status are pretty much never updated on this one. But it would solve most of the points you raised, while keeping fully compatible with the way people actually work (including Junio). Nicolas
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
Johannes Schindelin wrote: > What you need is a tool to aggregate this information, to help working > with it, to manage the project, and to be updated automatically. And to > publish this information continuously, without costing you extra effort. > > I understand that you started before GitHub existed, and before GitHub was > an option, the script-generated What's cooking mail was the best you could > do. On second reading, I think you're talking about GitHub's code review ("pull request") feature, not a bug tracker. There's been some active work (some that you've been involved in, I believe) on getting information from a GitHub pull request to the mailing list. One possibility would be to get information to also go in the other direction, so people have information about what happened to their patch in one place. I can also see why you are directing your attention to the maintainer for this one, since if the entire project adopts the GitHub Pull Request workflow, then the complexity and other flaws of such a two-way sync could be avoided. Unfortunately the maintainer is not the only person you'd need to convince. You'd also need to convince patch authors and reviewers to move to the new workflow. There are likely some potential contributors that this would bring in, that would like to get involved in the Git project but had been deterred by e.g. the mailing list's aggressive filtering of any email with an HTML part. Meanwhile it would also be a large adjustment for existing contributors, so it's not risk free. I personally like how Bazel[1] handles this. They have two ways to contribute: A. People used to GitHub can use a pull request like they are accustomed to. B. People preferring a more structured code review can use Gerrit. Having only two ways to contribute means that the code review information is still easy to archive and search, just like our mailing list archive. (Actually, an example I like even more is Akaros[2], which also appears to accept patch contributions by email.) Adding new ways for a contributor to submit a patch would mean that we can experiment with new workflows without getting in the way of people using an existing one. Thoughts? Jonathan [1] https://bazel.build/contributing.html [2] https://groups.google.com/forum/#!forum/akaros
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
Hi, Johannes Schindelin wrote: > To relate that, you are using a plain text format that is not well defined > and not structured, and certainly not machine-readable, for information > that is crucial for project management. > > What you need is a tool to aggregate this information, to help working > with it, to manage the project, and to be updated automatically. And to > publish this information continuously, without costing you extra effort. > > I understand that you started before GitHub existed, and before GitHub was > an option, the script-generated What's cooking mail was the best you could > do. I think you are subtly (but not directly, for some reason?) advocating moving project management for the Git project to GitHub Issues. For what it's worth: 1. I would be happy to see Git adopt a bug tracker. As we've discussed on the list before, I suspect the only way that this is going to happen is if some contributors start using a bug tracker and keep up with bugs there, without requiring everyone to use it. That is how the Linux Kernel project started using bugzilla.kernel.org, for example. 2. GitHub Issues is one of my least favorite bug trackers, for what it's worth. If some sub-project of Git chooses to use it, then that's great and I won't get in their way. I'm just providing this single data point that approximately any other tracker (Bugzilla, JIRA, debbugs, patchwork) is something I'd be more likely to use. 3. This advice might feel hopeless, because if the maintainer is not involved in the initial pilot, then how does the bug tracker get notified when a patch has been accepted? But fortunately this is a problem other people have solved: e.g. most bug trackers have an API that can be used to automatically notify the bug when a patch with a certain subject line appears on a certain branch. Thanks and hope that helps, Jonathan
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
Hi Junio, On Tue, 19 Sep 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> Do you have a concrete suggestion to make these individual entries > >> more helpful for people who may want go back to the original thread > >> in doing so? In-reply-to: or References: fields of the "What's > >> cooking" report would not help. I often have the message IDs that > >> made/helped me make these individual comments in the description; > >> they alone would not react to mouse clicks, though. > > > > Oh gawd, not even more stuff piled onto the mail format. Please stop. > > ... > > It probably tries to serve too many purposes at the same time, and > > thereby none. > > Well, this was started as my attempt to give a public service that shows > a summary of what is happening in the entire integration tree, as there > was nothing like that before (and going to github.com and looking at > 'pu' branch would not give you an easy overview). As many people > contribute many topics to the project, complaining that it talks about > too many topics would not get you anywhere. > > If you find "What's cooking" report not serving your needs, and if no > one finds it not serving his or her needs, then I can stop sending these > out, of course, but I am not getting the impression that we are at that > point, at least not yet. C'mon, don't *try* to misunderstand me. Of course there need to be updates as to the state of patch series. It's just that mails only go *so* far when you need to connect and aggregate information. You need the connection between the original patch series, the latest unaddressed reviews, links to the branches, history of the patch series' iterations, and ideally links to the repositories of the contributors with *their* branch names. And then, of course, your verdict as to the state of the patch series and your expectation what happens next. To relate that, you are using a plain text format that is not well defined and not structured, and certainly not machine-readable, for information that is crucial for project management. What you need is a tool to aggregate this information, to help working with it, to manage the project, and to be updated automatically. And to publish this information continuously, without costing you extra effort. I understand that you started before GitHub existed, and before GitHub was an option, the script-generated What's cooking mail was the best you could do. Ciao, Dscho
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
Johannes Schindelin writes: >> Do you have a concrete suggestion to make these individual entries more >> helpful for people who may want go back to the original thread in doing >> so? In-reply-to: or References: fields of the "What's cooking" report >> would not help. I often have the message IDs that made/helped me make >> these individual comments in the description; they alone would not react >> to mouse clicks, though. > > Oh gawd, not even more stuff piled onto the mail format. Please stop. > ... > It probably tries to serve too many purposes at the same time, and thereby > none. Well, this was started as my attempt to give a public service that shows a summary of what is happening in the entire integration tree, as there was nothing like that before (and going to github.com and looking at 'pu' branch would not give you an easy overview). As many people contribute many topics to the project, complaining that it talks about too many topics would not get you anywhere. If you find "What's cooking" report not serving your needs, and if no one finds it not serving his or her needs, then I can stop sending these out, of course, but I am not getting the impression that we are at that point, at least not yet.
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
Hi Junio, On Sat, 16 Sep 2017, Junio C Hamano wrote: > And as you alluded to, we may need to see if we can help making it > easier to do the latter when needed. That mistakes it for "Someone Else's Problem". > Johannes Schindelin writes: > > > That's what you are buying into by having these "What's cooking" mails > > that are in no usable way connected to the original threads. > > For the above reason, I do not think this is a particularly useful > stance to take. I agree, but this is the process you chose to use. > Do you have a concrete suggestion to make these individual entries more > helpful for people who may want go back to the original thread in doing > so? In-reply-to: or References: fields of the "What's cooking" report > would not help. I often have the message IDs that made/helped me make > these individual comments in the description; they alone would not react > to mouse clicks, though. Oh gawd, not even more stuff piled onto the mail format. Please stop. > Having said that, I'd expect that individual contributors have past > messages pertaining to the smaller numbers of their own topics in flight > in their mailbox than the project wide "What's cooking" report covers, > so perhaps an affort to devise such a mechanism may result in an > over-engineering waste nobody finds useful. I dunno. I frequently find myself putting off that What's cooking mail because it simply takes too long to study. It probably tries to serve too many purposes at the same time, and thereby none. In the same vein as "to a hammer, everything looks like a nail": when it comes to project management, a dedicated tool will always beat a general-purpose mailing list. Ciao, Dscho
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
Johannes Schindelin writes: > On Sat, 16 Sep 2017, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >> > If you want *contributors* to ping the thread themselves, how about >> > *posting your updates there, too*? >> >> I do not understand this comment at all. That is what I and others >> already and always do by responding to the patches, and when trying >> to see if a topic is still alive, with thread-specific responses and >> pings. >> >> If you are demanding that "What's cooking" report to be sent as a >> response to all the topics, that will *NOT* going to happen. It is >> meant to give a summary of the current state to help contributors >> and reviewers be aware of what is happening across the entire tree >> and not limited to a specific topic. > > If that is the case, you will have to be okay with others responding to > your "What's cooking" mails instead of the original threads. Yes and no. When I say "This topic waits for a reroll" and somebody (not necessarily the author of the topic) wants to remind me that a reroll has already been posted (or worse--I queued the updated version but forgot to update the message), I do appreciate that the reply is made to the "What's cooking" report. When there is "This topic waits for a response to a review comment" and the responder wants to respond to the review comment, the reply should be made in response to that review comment. Otherwise, the discussion will lose the continuity. And as you alluded to, we may need to see if we can help making it easier to do the latter when needed. > That's what > you are buying into by having these "What's cooking" mails that are in no > usable way connected to the original threads. For the above reason, I do not think this is a particularly useful stance to take. Do you have a concrete suggestion to make these individual entries more helpful for people who may want go back to the original thread in doing so? In-reply-to: or References: fields of the "What's cooking" report would not help. I often have the message IDs that made/helped me make these individual comments in the description; they alone would not react to mouse clicks, though. Having said that, I'd expect that individual contributors have past messages pertaining to the smaller numbers of their own topics in flight in their mailbox than the project wide "What's cooking" report covers, so perhaps an affort to devise such a mechanism may result in an over-engineering waste nobody finds useful. I dunno.
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
Hi Junio, On Sat, 16 Sep 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > If you want *contributors* to ping the thread themselves, how about > > *posting your updates there, too*? > > I do not understand this comment at all. That is what I and others > already and always do by responding to the patches, and when trying > to see if a topic is still alive, with thread-specific responses and > pings. > > If you are demanding that "What's cooking" report to be sent as a > response to all the topics, that will *NOT* going to happen. It is > meant to give a summary of the current state to help contributors > and reviewers be aware of what is happening across the entire tree > and not limited to a specific topic. If that is the case, you will have to be okay with others responding to your "What's cooking" mails instead of the original threads. That's what you are buying into by having these "What's cooking" mails that are in no usable way connected to the original threads. Ciao, Dscho
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
Johannes Schindelin writes: > If you want *contributors* to ping the thread themselves, how about > *posting your updates there, too*? I do not understand this comment at all. That is what I and others already and always do by responding to the patches, and when trying to see if a topic is still alive, with thread-specific responses and pings. If you are demanding that "What's cooking" report to be sent as a response to all the topics, that will *NOT* going to happen. It is meant to give a summary of the current state to help contributors and reviewers be aware of what is happening across the entire tree and not limited to a specific topic.
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
Hi Junio, On Thu, 24 Aug 2017, Junio C Hamano wrote: > Lars Schneider writes: > > > On 22 Aug 2017, at 21:56, Junio C Hamano wrote: > > > >> Here are the topics that have been cooking. Commits prefixed with > >> '-' are only in 'pu' (proposed updates) while commits prefixed with > >> '+' are in 'next'. The ones marked with '.' do not appear in any of > >> the integration branches, but I am still holding onto them. > >> > >> The second batch of topics are in. This cycle is going a bit slower > >> than the previous one (as of mid-week #3 of this cycle, we have > >> about 200 patches on 'master' since v2.14, compared to about 300 > >> patches in the cycle towards v2.14 at a similar point in the cycle), > >> but hopefully we can catch up eventually. > >> > >> I am planning to be offline most of the next week, by the way. > >> > >> You can find the changes described here in the integration branches > >> of the repositories listed at > >> > >>http://git-blame.blogspot.com/p/git-public-repositories.html > >> > >> -- > >> [Graduated to "master"] > >> > > > > Hi Junio, > > > > just in case this got lost: I posted a patch with an improvement to > > 2841e8f ("convert: add "status=delayed" to filter process protocol", > > 2017-06-30) which was merged to master in the beginning of 2.15. > > > > https://public-inbox.org/git/20170820154720.32259-1-larsxschnei...@gmail.com/ > > Thanks for pinging, but next time ping the thread itself if it is > about something that is not in What's cooking report you are > responding to. If you want *contributors* to ping the thread themselves, how about *posting your updates there, too*? It does make things inconvenient for contributors if they have to monitor those Whats' cooking emails in addition to the mail threads, you know? Ciao, Dscho
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
Lars Schneider writes: > On 22 Aug 2017, at 21:56, Junio C Hamano wrote: > >> Here are the topics that have been cooking. Commits prefixed with >> '-' are only in 'pu' (proposed updates) while commits prefixed with >> '+' are in 'next'. The ones marked with '.' do not appear in any of >> the integration branches, but I am still holding onto them. >> >> The second batch of topics are in. This cycle is going a bit slower >> than the previous one (as of mid-week #3 of this cycle, we have >> about 200 patches on 'master' since v2.14, compared to about 300 >> patches in the cycle towards v2.14 at a similar point in the cycle), >> but hopefully we can catch up eventually. >> >> I am planning to be offline most of the next week, by the way. >> >> You can find the changes described here in the integration branches >> of the repositories listed at >> >>http://git-blame.blogspot.com/p/git-public-repositories.html >> >> -- >> [Graduated to "master"] >> > > Hi Junio, > > just in case this got lost: I posted a patch with an improvement to > 2841e8f ("convert: add "status=delayed" to filter process protocol", > 2017-06-30) which was merged to master in the beginning of 2.15. > > https://public-inbox.org/git/20170820154720.32259-1-larsxschnei...@gmail.com/ Thanks for pinging, but next time ping the thread itself if it is about something that is not in What's cooking report you are responding to.
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
On 22 Aug 2017, at 21:56, Junio C Hamano wrote: > Here are the topics that have been cooking. Commits prefixed with > '-' are only in 'pu' (proposed updates) while commits prefixed with > '+' are in 'next'. The ones marked with '.' do not appear in any of > the integration branches, but I am still holding onto them. > > The second batch of topics are in. This cycle is going a bit slower > than the previous one (as of mid-week #3 of this cycle, we have > about 200 patches on 'master' since v2.14, compared to about 300 > patches in the cycle towards v2.14 at a similar point in the cycle), > but hopefully we can catch up eventually. > > I am planning to be offline most of the next week, by the way. > > You can find the changes described here in the integration branches > of the repositories listed at > >http://git-blame.blogspot.com/p/git-public-repositories.html > > -- > [Graduated to "master"] > Hi Junio, just in case this got lost: I posted a patch with an improvement to 2841e8f ("convert: add "status=delayed" to filter process protocol", 2017-06-30) which was merged to master in the beginning of 2.15. https://public-inbox.org/git/20170820154720.32259-1-larsxschnei...@gmail.com/ Thanks, Lars
Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)
On 08/22, Junio C Hamano wrote: > > * bw/submodule-config-cleanup (2017-08-03) 17 commits > - submodule: remove gitmodules_config > - unpack-trees: improve loading of .gitmodules > - submodule-config: lazy-load a repository's .gitmodules file > - submodule-config: move submodule-config functions to submodule-config.c > - submodule-config: remove support for overlaying repository config > - diff: stop allowing diff to have submodules configured in .git/config > - submodule: remove submodule_config callback routine > - unpack-trees: don't respect submodule.update > - submodule: don't rely on overlayed config when setting diffopts > - fetch: don't overlay config with submodule-config > - submodule--helper: don't overlay config in update-clone > - submodule--helper: don't overlay config in remote_submodule_branch > - add, reset: ensure submodules can be added or reset > - submodule: don't use submodule_from_name > - t7411: check configuration parsing errors > - Merge branch 'bc/object-id' into bw/submodule-config-cleanup > - Merge branch 'bw/grep-recurse-submodules' into bw/submodule-config-cleanup > > Code clean-up to avoid mixing values read from the .gitmodules file > and values read from the .git/config file. > > So, after the recent discussion around submodule..update (and > its resolution "use submodule..active; "reset --hard" must > ignore the .update thing"), this is now good to go, I presume? > Please yell at me that I am clueless if that is not the case ;-) Yep I came to the same conclusion that you did so this should be good to go! -- Brandon Williams