From adinn at redhat.com Fri Nov 1 08:53:28 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 1 Nov 2019 08:53:28 +0000 Subject: =?UTF-8?Q?Re=3a_Microsoft=e2=80=99s_Ready_do_Contribute_to_OpenJDK?= In-Reply-To: <0A4E72D2-5848-4E3B-97C8-321414186551@contoso.com> References: <0A4E72D2-5848-4E3B-97C8-321414186551@contoso.com> Message-ID: <99bb4669-59fb-e7f5-31a4-b4d584d34345@redhat.com> Hi Bruno, It's very gratifying to hear that Microsoft are committed to both Java and OpenJDK. Welcome to the project (or, in Martijn's case, welcome back under 'new denomination'). We will be very pleased to help you contribute. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill On 30/10/2019 21:45, Bruno Borges wrote: > Subject: Microsoft?s Ready do Contribute to OpenJDK > > Hi OpenJDK Community, > > In the past week Microsoft formally signed the Oracle Contributor > Agreement, in which Oracle Inc. promptly acknowledged and welcomed us > to the project. On behalf of the Microsoft Java Engineering Team, I?d > like to say that we are thrilled to officially join the OpenJDK > project and be ready to work with you. > > As many of you may know, Microsoft and its subsidiaries are heavily > dependent on Java in many aspects, and also offers Java runtimes in > its Microsoft Azure cloud to its customers. Microsoft recognizes the > immense value that Oracle?s successful and effective stewardship of > the OpenJDK project has bought Java and the wider software ecosystem > and we look forward to playing our part in contributing back! > > The team will initially be working on smaller bug fixes and backports > so that we can learn how to be good citizens within OpenJDK. For > example, we already understand that discussing changes first before > posting patches is preferred and I'm sure there's more for us to > learn as well. > > The Java engineering team led by Martijn Verburg [1] is already > engaged with other Microsoft groups and its subsidiaries who are > using Java, as well as its partners in the Java ecosystem such as > Azul Systems, Oracle, Pivotal, Red Hat, Intel, SAP and others, and > the overall team will be joining the many OpenJDK mailing lists to > start conversations and participating. > > We look forward to participating in the future of Java. > > [1] > martijn.verburg at microsoft.com > > Best regards Bruno Borges Product Management for Java, Microsoft > Developer Division > From simon at webmink.com Fri Nov 1 09:55:24 2019 From: simon at webmink.com (Simon Phipps) Date: Fri, 1 Nov 2019 09:55:24 +0000 Subject: =?UTF-8?Q?Re=3A_Microsoft=E2=80=99s_Ready_do_Contribute_to_OpenJDK?= In-Reply-To: <0A4E72D2-5848-4E3B-97C8-321414186551@contoso.com> References: <0A4E72D2-5848-4E3B-97C8-321414186551@contoso.com> Message-ID: Welcome back! S. On Wed, Oct 30, 2019 at 9:46 PM Bruno Borges wrote: > Subject: Microsoft?s Ready do Contribute to OpenJDK > > Hi OpenJDK Community, > > In the past week Microsoft formally signed the Oracle Contributor > Agreement, in which Oracle Inc. promptly acknowledged and welcomed us to > the project. On behalf of the Microsoft Java Engineering Team, I?d like to > say that we are thrilled to officially join the OpenJDK project and be > ready to work with you. > > As many of you may know, Microsoft and its subsidiaries are heavily > dependent on Java in many aspects, and also offers Java runtimes in its > Microsoft Azure cloud to its customers. Microsoft recognizes the immense > value that Oracle?s successful and effective stewardship of the OpenJDK > project has bought Java and the wider software ecosystem and we look > forward to playing our part in contributing back! > > The team will initially be working on smaller bug fixes and backports so > that we can learn how to be good citizens within OpenJDK. For example, we > already understand that discussing changes first before posting patches is > preferred and I'm sure there's more for us to learn as well. > > The Java engineering team led by Martijn Verburg [1] is already engaged > with other Microsoft groups and its subsidiaries who are using Java, as > well as its partners in the Java ecosystem such as Azul Systems, Oracle, > Pivotal, Red Hat, Intel, SAP and others, and the overall team will be > joining the many OpenJDK mailing lists to start conversations and > participating. > > We look forward to participating in the future of Java. > > [1] martijn.verburg at microsoft.com > > Best regards > Bruno Borges > Product Management for Java, > Microsoft Developer Division > > -- *Simon Phipps* http://webmink.com *Office:* +1 (415) 683-7660 *or* +44 (238) 098 7027 *Signal/Mobile*: +44 774 776 2816 From wintermute24x7 at icloud.com Sat Nov 2 21:15:11 2019 From: wintermute24x7 at icloud.com (M.R.P. zensky) Date: Sat, 2 Nov 2019 14:15:11 -0700 Subject: Beginning Java Programmer Message-ID: Hello I am Running Kubuntu Linux and am wanting to learn Java Programming. I have numerous beginner issues such as setting up my environment correctly. Is this the best list for beginner questions and issues? From sproket at videotron.ca Sat Nov 2 21:24:53 2019 From: sproket at videotron.ca (Dan Howard) Date: Sat, 2 Nov 2019 17:24:53 -0400 Subject: Beginning Java Programmer In-Reply-To: References: Message-ID: Not really. You'd be better at https://javaranch.com/ or https://www.reddit.com/r/javahelp/ On 11/2/2019 5:15 PM, M.R.P. zensky wrote: > Hello I am Running Kubuntu Linux and am wanting to learn Java Programming. I have numerous beginner issues such as setting up my environment correctly. Is this the best list for beginner questions and issues? > From brian.goetz at oracle.com Sat Nov 2 21:24:56 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 2 Nov 2019 17:24:56 -0400 Subject: Beginning Java Programmer In-Reply-To: References: Message-ID: <1f42a61b-f35b-9a8d-4d4e-6a826eeb2bbc@oracle.com> I would recommend StackOverflow as a way to find answers to these questions, or ask them if they have not already been covered. On 11/2/2019 5:15 PM, M.R.P. zensky wrote: > Hello I am Running Kubuntu Linux and am wanting to learn Java Programming. I have numerous beginner issues such as setting up my environment correctly. Is this the best list for beginner questions and issues? From donald.smith at oracle.com Mon Nov 4 14:08:12 2019 From: donald.smith at oracle.com (Donald Smith) Date: Mon, 4 Nov 2019 09:08:12 -0500 Subject: =?UTF-8?Q?Re=3a_Microsoft=e2=80=99s_Ready_do_Contribute_to_OpenJDK?= In-Reply-To: <0A4E72D2-5848-4E3B-97C8-321414186551@contoso.com> References: <0A4E72D2-5848-4E3B-97C8-321414186551@contoso.com> Message-ID: <974d49fc-4934-466c-0ebf-9304bae8a419@oracle.com> Welcome back! For those who may not have followed history, Microsoft signed an OCA in 2013.? There were a lot of announcements and lots of press coverage around it at the time, but not much materialized from it beyond the marketing splash. I think everyone is very happy to see Microsoft reaffirm interest in OpenJDK by updating their contribution paperwork.? Very happy to see MSFT people engage again, and looking forward to see what the results may be! ?- Don On 2019-10-30 5:45 p.m., Bruno Borges wrote: > Subject: Microsoft?s Ready do Contribute to OpenJDK > > Hi OpenJDK Community, > > In the past week Microsoft formally signed the Oracle Contributor Agreement, in which Oracle Inc. promptly acknowledged and welcomed us to the project. On behalf of the Microsoft Java Engineering Team, I?d like to say that we are thrilled to officially join the OpenJDK project and be ready to work with you. > > As many of you may know, Microsoft and its subsidiaries are heavily dependent on Java in many aspects, and also offers Java runtimes in its Microsoft Azure cloud to its customers. Microsoft recognizes the immense value that Oracle?s successful and effective stewardship of the OpenJDK project has bought Java and the wider software ecosystem and we look forward to playing our part in contributing back! > > The team will initially be working on smaller bug fixes and backports so that we can learn how to be good citizens within OpenJDK. For example, we already understand that discussing changes first before posting patches is preferred and I'm sure there's more for us to learn as well. > > The Java engineering team led by Martijn Verburg [1] is already engaged with other Microsoft groups and its subsidiaries who are using Java, as well as its partners in the Java ecosystem such as Azul Systems, Oracle, Pivotal, Red Hat, Intel, SAP and others, and the overall team will be joining the many OpenJDK mailing lists to start conversations and participating. > > We look forward to participating in the future of Java. > > [1] martijn.verburg at microsoft.com > > Best regards > Bruno Borges > Product Management for Java, > Microsoft Developer Division > From Bruno.Borges at microsoft.com Mon Nov 4 15:27:56 2019 From: Bruno.Borges at microsoft.com (Bruno Borges) Date: Mon, 4 Nov 2019 15:27:56 +0000 Subject: =?Windows-1252?Q?Re:_Microsoft=92s_Ready_do_Contribute_to_OpenJDK?= In-Reply-To: <974d49fc-4934-466c-0ebf-9304bae8a419@oracle.com> References: <0A4E72D2-5848-4E3B-97C8-321414186551@contoso.com>, <974d49fc-4934-466c-0ebf-9304bae8a419@oracle.com> Message-ID: (pulling out of openjdk-discuss) Hi Donald, It's worth noting that we had to sign this OCA on behalf of Microsoft Corp. because the one from 2013 was signed by Microsoft Open Technologies Inc., a subsidiary that no longer exists [1]. Without the OCA on behalf of Microsoft Corp, the Java engineering team wouldn't be able to send contributions. I've mentioned this to you before [2], but happy to discuss if you have further questions on this topic. Thanks for welcoming us, we also look forward to be working with you. [1] https://www.zdnet.com/article/microsoft-shutters-its-standalone-open-tech-open-source-subsidiary/ [2] https://twitter.com/brunoborges/status/1189770213388099584?s=19 bb. Sent from mobile. ________________________________ From: discuss on behalf of Donald Smith Sent: Monday, November 4, 2019 9:08:12 AM To: discuss at openjdk.java.net Subject: Re: Microsoft?s Ready do Contribute to OpenJDK Welcome back! For those who may not have followed history, Microsoft signed an OCA in 2013. There were a lot of announcements and lots of press coverage around it at the time, but not much materialized from it beyond the marketing splash. I think everyone is very happy to see Microsoft reaffirm interest in OpenJDK by updating their contribution paperwork. Very happy to see MSFT people engage again, and looking forward to see what the results may be! - Don On 2019-10-30 5:45 p.m., Bruno Borges wrote: > Subject: Microsoft?s Ready do Contribute to OpenJDK > > Hi OpenJDK Community, > > In the past week Microsoft formally signed the Oracle Contributor Agreement, in which Oracle Inc. promptly acknowledged and welcomed us to the project. On behalf of the Microsoft Java Engineering Team, I?d like to say that we are thrilled to officially join the OpenJDK project and be ready to work with you. > > As many of you may know, Microsoft and its subsidiaries are heavily dependent on Java in many aspects, and also offers Java runtimes in its Microsoft Azure cloud to its customers. Microsoft recognizes the immense value that Oracle?s successful and effective stewardship of the OpenJDK project has bought Java and the wider software ecosystem and we look forward to playing our part in contributing back! > > The team will initially be working on smaller bug fixes and backports so that we can learn how to be good citizens within OpenJDK. For example, we already understand that discussing changes first before posting patches is preferred and I'm sure there's more for us to learn as well. > > The Java engineering team led by Martijn Verburg [1] is already engaged with other Microsoft groups and its subsidiaries who are using Java, as well as its partners in the Java ecosystem such as Azul Systems, Oracle, Pivotal, Red Hat, Intel, SAP and others, and the overall team will be joining the many OpenJDK mailing lists to start conversations and participating. > > We look forward to participating in the future of Java. > > [1] martijn.verburg at microsoft.com > > Best regards > Bruno Borges > Product Management for Java, > Microsoft Developer Division > From simon at webmink.com Mon Nov 4 16:15:20 2019 From: simon at webmink.com (Simon Phipps) Date: Mon, 4 Nov 2019 16:15:20 +0000 Subject: =?UTF-8?Q?Re=3A_Microsoft=E2=80=99s_Ready_do_Contribute_to_OpenJDK?= In-Reply-To: References: <0A4E72D2-5848-4E3B-97C8-321414186551@contoso.com> <974d49fc-4934-466c-0ebf-9304bae8a419@oracle.com> Message-ID: Hi Bruno! Some of remember when Microsoft committed to Java the first time, hence the "welcome back" :-) https://news.microsoft.com/1996/03/12/microsoft-and-sun-microsystems-conclude-agreement-to-license-technology-for-java/ S. On Mon, Nov 4, 2019 at 3:40 PM Bruno Borges wrote: > (pulling out of openjdk-discuss) > > Hi Donald, > > It's worth noting that we had to sign this OCA on behalf of Microsoft > Corp. because the one from 2013 was signed by Microsoft Open Technologies > Inc., a subsidiary that no longer exists [1]. Without the OCA on behalf of > Microsoft Corp, the Java engineering team wouldn't be able to send > contributions. > > I've mentioned this to you before [2], but happy to discuss if you have > further questions on this topic. > > Thanks for welcoming us, we also look forward to be working with you. > > [1] > https://www.zdnet.com/article/microsoft-shutters-its-standalone-open-tech-open-source-subsidiary/ > [2] > https://twitter.com/brunoborges/status/1189770213388099584?s=19 > > bb. > > > Sent from mobile. > ________________________________ > From: discuss on behalf of Donald > Smith > Sent: Monday, November 4, 2019 9:08:12 AM > To: discuss at openjdk.java.net > Subject: Re: Microsoft?s Ready do Contribute to OpenJDK > > Welcome back! > > For those who may not have followed history, Microsoft signed an OCA in > 2013. There were a lot of announcements and lots of press coverage > around it at the time, but not much materialized from it beyond the > marketing splash. > > I think everyone is very happy to see Microsoft reaffirm interest in > OpenJDK by updating their contribution paperwork. Very happy to see > MSFT people engage again, and looking forward to see what the results > may be! > > - Don > > On 2019-10-30 5:45 p.m., Bruno Borges wrote: > > Subject: Microsoft?s Ready do Contribute to OpenJDK > > > > Hi OpenJDK Community, > > > > In the past week Microsoft formally signed the Oracle Contributor > Agreement, in which Oracle Inc. promptly acknowledged and welcomed us to > the project. On behalf of the Microsoft Java Engineering Team, I?d like to > say that we are thrilled to officially join the OpenJDK project and be > ready to work with you. > > > > As many of you may know, Microsoft and its subsidiaries are heavily > dependent on Java in many aspects, and also offers Java runtimes in its > Microsoft Azure cloud to its customers. Microsoft recognizes the immense > value that Oracle?s successful and effective stewardship of the OpenJDK > project has bought Java and the wider software ecosystem and we look > forward to playing our part in contributing back! > > > > The team will initially be working on smaller bug fixes and backports so > that we can learn how to be good citizens within OpenJDK. For example, we > already understand that discussing changes first before posting patches is > preferred and I'm sure there's more for us to learn as well. > > > > The Java engineering team led by Martijn Verburg [1] is already engaged > with other Microsoft groups and its subsidiaries who are using Java, as > well as its partners in the Java ecosystem such as Azul Systems, Oracle, > Pivotal, Red Hat, Intel, SAP and others, and the overall team will be > joining the many OpenJDK mailing lists to start conversations and > participating. > > > > We look forward to participating in the future of Java. > > > > [1] martijn.verburg at microsoft.com > > > > Best regards > > Bruno Borges > > Product Management for Java, > > Microsoft Developer Division > > > > -- *Simon Phipps* http://webmink.com *Office:* +1 (415) 683-7660 *or* +44 (238) 098 7027 *Signal/Mobile*: +44 774 776 2816 From neugens at redhat.com Mon Nov 4 16:20:03 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 4 Nov 2019 17:20:03 +0100 Subject: =?UTF-8?Q?Re=3A_Microsoft=E2=80=99s_Ready_do_Contribute_to_OpenJDK?= In-Reply-To: <0A4E72D2-5848-4E3B-97C8-321414186551@contoso.com> References: <0A4E72D2-5848-4E3B-97C8-321414186551@contoso.com> Message-ID: Welcome to the family Microsoft! Cheers, Mario On Wed, Oct 30, 2019 at 10:45 PM Bruno Borges wrote: > > Subject: Microsoft?s Ready do Contribute to OpenJDK > > Hi OpenJDK Community, > > In the past week Microsoft formally signed the Oracle Contributor Agreement, in which Oracle Inc. promptly acknowledged and welcomed us to the project. On behalf of the Microsoft Java Engineering Team, I?d like to say that we are thrilled to officially join the OpenJDK project and be ready to work with you. > > As many of you may know, Microsoft and its subsidiaries are heavily dependent on Java in many aspects, and also offers Java runtimes in its Microsoft Azure cloud to its customers. Microsoft recognizes the immense value that Oracle?s successful and effective stewardship of the OpenJDK project has bought Java and the wider software ecosystem and we look forward to playing our part in contributing back! > > The team will initially be working on smaller bug fixes and backports so that we can learn how to be good citizens within OpenJDK. For example, we already understand that discussing changes first before posting patches is preferred and I'm sure there's more for us to learn as well. > > The Java engineering team led by Martijn Verburg [1] is already engaged with other Microsoft groups and its subsidiaries who are using Java, as well as its partners in the Java ecosystem such as Azul Systems, Oracle, Pivotal, Red Hat, Intel, SAP and others, and the overall team will be joining the many OpenJDK mailing lists to start conversations and participating. > > We look forward to participating in the future of Java. > > [1] martijn.verburg at microsoft.com > > Best regards > Bruno Borges > Product Management for Java, > Microsoft Developer Division > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From mark.reinhold at oracle.com Tue Nov 12 16:00:00 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 12 Nov 2019 16:00:00 +0000 (GMT) Subject: New candidate JEP: 369: Migrate to GitHub Message-ID: <20191112160000.9698430DBF0@eggemoggin.niobe.net> https://openjdk.java.net/jeps/369 - Mark From adinn at redhat.com Wed Nov 13 10:36:42 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 13 Nov 2019 10:36:42 +0000 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <20191112160000.9698430DBF0@eggemoggin.niobe.net> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> Message-ID: <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> On 12/11/2019 16:00, mark.reinhold at oracle.com wrote: > https://openjdk.java.net/jeps/369 Firstly, thanks to Joe and Erik for producing a very comprehensive JEP that addresses so many important questions. There are many aspects of this proposed move that are very appealing. However, I am afraid I am still going to start by expressing my severe reservations about one proposed change: replacing email review with GitHub PRs (sorry guys :-/). The JEP has this laudable goal: "Ensure that workflows structurally similar to the existing e-mail and webrev based workflows are supported." and further qualifies that with: "Today, OpenJDK contributors collaborate via mailing lists, they push changes to Mercurial repositories, they test changes via the jdk/submit service, and they file bug reports via the JDK Bug System (JBS). Contributors can also make use of several command-line interface (CLI) tools, primarily jcheck, webrev, and defpath. This is a workflow that many experienced contributors enjoy and find productive. It's therefore critical to preserve as much of this workflow as possible if we move to an external provider." which one cannot really disagree with. The JEP then explains that: "Reviewers can now discuss the changes in the PR, using multiple workflows: By replying to the RFR email sent to the mailing list(s), in which case the contents of replies are copied into the PR on GitHub (no GitHub account is required); . . . Any comment made in any of the workflows is reflected in all of the workflows. One reviewer can add a comment via the mailing list, another via the web browser, and a third via the command-line and they will all see each others' comments." My experience of GitHub use in the Graal project suggest that this is not entirely the full picture. My view derived from that experience is that the GitHub PR is very much an inferior medium for review discussion. In particular, it definitely fails to be "structurally similar to the existing e-mail and webrev based workflows". Firstly, I'll note that email discussions consist of a tree of dependent commentary. That commentary often contains quoted material which, especially when carefully edited (as it normally is), tracks relevant context. The structuring that results from this use of the reply hierarchy and quoting permits a given discussion to split into a group of related subordinate discussions where required while still retaining a continued thread of relevance to a specific review. Crucially, most email readers allow such branching discussions to be followed and extended in /parallel/. By contrast discussions in GitHub PRs are essentially linearized (modulo a single level of nesting of commentary on top level comments). Worse, the presentation forces all commentary to be flattened into a single browser pane view. This linear mode of presentation results in a severe hindrance to separation of, and attention to, separate concerns. It also fails to preserve and display source relationships that clarify the provenance and relevance of quoted text i.e. it not only fails to record but actually obfuscates important context. Of course, discussions that remain in email may continue to profit from the multi-focus aspect of the current workflow. However, I believe that contributions to the discussion via a GitHub PR will inevitably bypass and, therefore, invalidate any such structuring contributed via the email workflow. Not only do I currently see that effect with Graal PRs but I also see the damage it imposes on flow and quality of discussion. Secondly, email reviews are conventionally directed to readers with different domains of interest and expertise. That sometimes requires re-routing a discussion to a different list from the one on which it was first initiated. It also sometimes requires posting comments to multiple lists, either when discussion is initiated or in mid-stream as the scope of discussion develops. Managing distribution when using emails lists is both easily achieved and well understood (n.b. that's not to imply that deciding which list to send to is easy). The JEP suggests that discussions raised via PRs will be routed to lists 1) derived from the affected files and/or 2) specified by whoever raises the PR. It doesn't explain how (whether) target lists are to be (may be) updated as review progresses. It also doesn't state clearly whether whoever raises the PR or comments on it will have the ability to override those default choices (I fully expect that option will be necessary in some cases). I need to stress that these concerns should not be considered as minor details of how the project operates. Easy management of the flow and direction of discussion is critical to being able to consume and respond to commentary at the rate needed to keep up with a project as large and rapidly changing as OpenJDK currently is. Given the central importance of our review process to ensuring the health of the project and its products I think it is right to be very concerned about the potential for problems caused by this switch of medium. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From erik.helin at oracle.com Wed Nov 13 11:42:21 2019 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 13 Nov 2019 12:42:21 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: On 11/13/19 11:36 AM, Andrew Dinn wrote: > On 12/11/2019 16:00, mark.reinhold at oracle.com wrote: >> https://openjdk.java.net/jeps/369 > Firstly, thanks to Joe and Erik for producing a very comprehensive JEP > that addresses so many important questions. There are many aspects of > this proposed move that are very appealing. Thanks Andrew for reading through it all and providing feedback! Please see my replies inline. > However, I am afraid I am > still going to start by expressing my severe reservations about one > proposed change: replacing email review with GitHub PRs (sorry guys :-/). > > The JEP has this laudable goal: > > "Ensure that workflows structurally similar to the existing e-mail and > webrev based workflows are supported." > > and further qualifies that with: > > "Today, OpenJDK contributors collaborate via mailing lists, they push > changes to Mercurial repositories, they test changes via the jdk/submit > service, and they file bug reports via the JDK Bug System (JBS). > Contributors can also make use of several command-line interface (CLI) > tools, primarily jcheck, webrev, and defpath. This is a workflow that > many experienced contributors enjoy and find productive. It's therefore > critical to preserve as much of this workflow as possible if we move to > an external provider." > > which one cannot really disagree with. > > The JEP then explains that: > > "Reviewers can now discuss the changes in the PR, using multiple workflows: > > By replying to the RFR email sent to the mailing list(s), in which > case the contents of replies are copied into the PR on GitHub (no GitHub > account is required); > . . . > Any comment made in any of the workflows is reflected in all of the > workflows. One reviewer can add a comment via the mailing list, another > via the web browser, and a third via the command-line and they will all > see each others' comments." > > My experience of GitHub use in the Graal project suggest that this is > not entirely the full picture. My view derived from that experience is > that the GitHub PR is very much an inferior medium for review > discussion. In particular, it definitely fails to be "structurally > similar to the existing e-mail and webrev based workflows". I think the key sentence here is "My experience of GitHub use in the Graal project...". Having worked with project on GitHub using Skara tooling and projects on GitHub _not_ using Skara tooling, my view is that the experiences differs quite a bit. > Firstly, I'll note that email discussions consist of a tree of dependent > commentary. That commentary often contains quoted material which, > especially when carefully edited (as it normally is), tracks relevant > context. The structuring that results from this use of the reply > hierarchy and quoting permits a given discussion to split into a group > of related subordinate discussions where required while still retaining > a continued thread of relevance to a specific review. Crucially, most > email readers allow such branching discussions to be followed and > extended in /parallel/. > > By contrast discussions in GitHub PRs are essentially linearized (modulo > a single level of nesting of commentary on top level comments). Worse, > the presentation forces all commentary to be flattened into a single > browser pane view. This linear mode of presentation results in a severe > hindrance to separation of, and attention to, separate concerns. It also > fails to preserve and display source relationships that clarify the > provenance and relevance of quoted text i.e. it not only fails to record > but actually obfuscates important context. This does not paint the whole picture. You are probably thinking of the "Conversation" tab in a GitHub pull request which is meant for *general* discussion of the patch that is not attached to any particular change in the patch. GitHub's own help documentation [0] states that the "Conversation" tab is meant to be used for: You can comment on a pull request's Conversation tab to leave general comments, questions, or props. You are right that comments in the "Conversation" tab are linearized and does not support a "tree style" view of comments. The good news are that the _other_ form of comments available on a GitHub pull request, a so-called "review comment" or "file comment" [1], does support replies in the form of a tree. These comments are filed under the "Files changed" tab in a pull request. Personally I think of the comments in the "Conversation" tab as replies to the "00" email in a classic patch series email and the "review comments" in the "Files changed" tab as replies to the "0X" emails actually containing patches. Do you follow? Now the interesting question is of course how the Skara tooling translates these kinds of comments back-and-forth between mailing lists and GitHub. Here I'm happy to report that the Skara tooling does proper replying, which will cause the "review comments" created under the "Files changed" tab on a pull request to result in a tree-view (in email clients that support such views). You can see of some of this work on the openjfx-dev mailing list [2]. Now keep in mind if you are looking at Pipermail rendering of a mailing list, which lacks some features that most email clients supports (such as folding quoted text and nested replies beyond three levels). A mailing list version of a pull request will in general have the following structure: - RFR: Fix a bug <-- Email describing patch - Re: RFR: Fix a bug <-- This is a general comment - Re: RFR: Fix a bug <-- This is a reply to the general comment - Re: [Rev 01]: RFR: Fix a bug <-- The author updated the patch - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer A on 01 - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from A on 01 - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer B on 01 - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from B on 01 - Re: [Rev 02]: RFR: Fix a bug <-- The author updated again - Re: [Approved] RFR: Fix a bug <-- Reviewer A approved the patch - Re: [Approved] RFR: Fix a bug <-- Reviewer B approved the patch - Re: [Integrated] RFR: Fix a bug <-- Author integrated the patch We are tweaking this structure as we get more and more experience with it, but at the moment I'm fairly satisfied with threading and the tree layout. If you have any feedback on this structure/layout, then we are happy to hear it. Going in the other direction, mailing list -> GitHub, we also try to preserve the mailing list structure as much as possible. This is actually a harder challenge, since an email is less structured compared to a comment on GitHub. An example of this direction can be found in pull request 231 for the Skara repository [3] where you can see the thread (which is a tree) from skara-dev at openjdk.java.net [4] being "flattened" and uses quotation to try to preserve the flow. > Of course, discussions that remain in email may continue to profit from > the multi-focus aspect of the current workflow. However, I believe that > contributions to the discussion via a GitHub PR will inevitably bypass > and, therefore, invalidate any such structuring contributed via the > email workflow. Not only do I currently see that effect with Graal PRs > but I also see the damage it imposes on flow and quality of discussion. > > Secondly, email reviews are conventionally directed to readers with > different domains of interest and expertise. That sometimes requires > re-routing a discussion to a different list from the one on which it was > first initiated. It also sometimes requires posting comments to multiple > lists, either when discussion is initiated or in mid-stream as the scope > of discussion develops. Managing distribution when using emails lists is > both easily achieved and well understood (n.b. that's not to imply that > deciding which list to send to is easy). Here we are currently working on the /cc command that can be used in a comment on pull request, for example: /cc build-dev hotspot-dev > The JEP suggests that discussions raised via PRs will be routed to lists > 1) derived from the affected files and/or 2) specified by whoever raises > the PR. It doesn't explain how (whether) target lists are to be (may be) > updated as review progresses. It also doesn't state clearly whether > whoever raises the PR or comments on it will have the ability to > override those default choices (I fully expect that option will be > necessary in some cases). Agree, see the command above that we are working on :) > I need to stress that these concerns should not be considered as minor > details of how the project operates. Easy management of the flow and > direction of discussion is critical to being able to consume and respond > to commentary at the rate needed to keep up with a project as large and > rapidly changing as OpenJDK currently is. Given the central importance > of our review process to ensuring the health of the project and its > products I think it is right to be very concerned about the potential > for problems caused by this switch of medium. I hope that is does not come across that we are taking mailing list interopability as a minor detail? I think it is fair to say that this is the Skara feature we have spent the most time working on and are constantly improving in order to provide a good experience. Thanks, Erik [0]: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request [1]: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request [2]: https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-November/thread.html [3]: https://git.openjdk.java.net/skara/pull/231 [4]: https://mail.openjdk.java.net/pipermail/skara-dev/2019-October/000998.html > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From neugens.limasoftware at gmail.com Wed Nov 13 13:20:08 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 13 Nov 2019 14:20:08 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: I agree with Andrew here which has quite brilliantly explained all of my biggest concerns so I won't repeat them here, but I also still have a fair share of issues with the GitHub specific enforcement of the forking+pull request workflow. And yes, I know we've discussed some of those issues already extensively but I'm still not satisfied because the reality is that most of the answers provide a theoretical implementation that in reality will force a lot of re-learning and personal adjustments. We (sort of) accepted to experiment with GitHub in Mission Control and the project is aiming to move there soon, I suggest we first gain some first hand experience before moving the largest and arguably most important project to this completely new workflow. Btw, the "Expanded community" section, in my humble view, isn't really a point to consider. Realistically, it won't happen that the occasional developer with no experience lurking on GitHub will find OpenJDK and send random pull requests, so the mere fact that the project exist on GitHub won't make it more visible or lower the entrance barrier, it just won't make any difference whatsoever. Cheers, Mario Il giorno mer 13 nov 2019 alle ore 11:36 Andrew Dinn ha scritto: > > On 12/11/2019 16:00, mark.reinhold at oracle.com wrote: > > https://openjdk.java.net/jeps/369 > Firstly, thanks to Joe and Erik for producing a very comprehensive JEP > that addresses so many important questions. There are many aspects of > this proposed move that are very appealing. However, I am afraid I am > still going to start by expressing my severe reservations about one > proposed change: replacing email review with GitHub PRs (sorry guys :-/). > > The JEP has this laudable goal: > > "Ensure that workflows structurally similar to the existing e-mail and > webrev based workflows are supported." > > and further qualifies that with: > > "Today, OpenJDK contributors collaborate via mailing lists, they push > changes to Mercurial repositories, they test changes via the jdk/submit > service, and they file bug reports via the JDK Bug System (JBS). > Contributors can also make use of several command-line interface (CLI) > tools, primarily jcheck, webrev, and defpath. This is a workflow that > many experienced contributors enjoy and find productive. It's therefore > critical to preserve as much of this workflow as possible if we move to > an external provider." > > which one cannot really disagree with. > > The JEP then explains that: > > "Reviewers can now discuss the changes in the PR, using multiple workflows: > > By replying to the RFR email sent to the mailing list(s), in which > case the contents of replies are copied into the PR on GitHub (no GitHub > account is required); > . . . > Any comment made in any of the workflows is reflected in all of the > workflows. One reviewer can add a comment via the mailing list, another > via the web browser, and a third via the command-line and they will all > see each others' comments." > > My experience of GitHub use in the Graal project suggest that this is > not entirely the full picture. My view derived from that experience is > that the GitHub PR is very much an inferior medium for review > discussion. In particular, it definitely fails to be "structurally > similar to the existing e-mail and webrev based workflows". > > Firstly, I'll note that email discussions consist of a tree of dependent > commentary. That commentary often contains quoted material which, > especially when carefully edited (as it normally is), tracks relevant > context. The structuring that results from this use of the reply > hierarchy and quoting permits a given discussion to split into a group > of related subordinate discussions where required while still retaining > a continued thread of relevance to a specific review. Crucially, most > email readers allow such branching discussions to be followed and > extended in /parallel/. > > By contrast discussions in GitHub PRs are essentially linearized (modulo > a single level of nesting of commentary on top level comments). Worse, > the presentation forces all commentary to be flattened into a single > browser pane view. This linear mode of presentation results in a severe > hindrance to separation of, and attention to, separate concerns. It also > fails to preserve and display source relationships that clarify the > provenance and relevance of quoted text i.e. it not only fails to record > but actually obfuscates important context. > > Of course, discussions that remain in email may continue to profit from > the multi-focus aspect of the current workflow. However, I believe that > contributions to the discussion via a GitHub PR will inevitably bypass > and, therefore, invalidate any such structuring contributed via the > email workflow. Not only do I currently see that effect with Graal PRs > but I also see the damage it imposes on flow and quality of discussion. > > Secondly, email reviews are conventionally directed to readers with > different domains of interest and expertise. That sometimes requires > re-routing a discussion to a different list from the one on which it was > first initiated. It also sometimes requires posting comments to multiple > lists, either when discussion is initiated or in mid-stream as the scope > of discussion develops. Managing distribution when using emails lists is > both easily achieved and well understood (n.b. that's not to imply that > deciding which list to send to is easy). > > The JEP suggests that discussions raised via PRs will be routed to lists > 1) derived from the affected files and/or 2) specified by whoever raises > the PR. It doesn't explain how (whether) target lists are to be (may be) > updated as review progresses. It also doesn't state clearly whether > whoever raises the PR or comments on it will have the ability to > override those default choices (I fully expect that option will be > necessary in some cases). > > I need to stress that these concerns should not be considered as minor > details of how the project operates. Easy management of the flow and > direction of discussion is critical to being able to consume and respond > to commentary at the rate needed to keep up with a project as large and > rapidly changing as OpenJDK currently is. Given the central importance > of our review process to ensuring the health of the project and its > products I think it is right to be very concerned about the potential > for problems caused by this switch of medium. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From neugens.limasoftware at gmail.com Wed Nov 13 13:24:15 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 13 Nov 2019 14:24:15 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: Il giorno mer 13 nov 2019 alle ore 12:42 Erik Helin ha scritto: > This does not paint the whole picture. You are probably thinking of the > "Conversation" tab in a GitHub pull request which is meant for *general* > discussion of the patch that is not attached to any particular change in > the patch. GitHub's own help documentation [0] states that the > "Conversation" tab is meant to be used for: > > You can comment on a pull request's Conversation tab to leave > general comments, questions, or props. > > You are right that comments in the "Conversation" tab are linearized and > does not support a "tree style" view of comments. > > The good news are that the _other_ form of comments available on a > GitHub pull request, a so-called "review comment" or "file comment" [1], > does support replies in the form of a tree. These comments are filed > under the "Files changed" tab in a pull request. > > Personally I think of the comments in the "Conversation" tab as replies > to the "00" email in a classic patch series email and the "review > comments" in the "Files changed" tab as replies to the "0X" emails > actually containing patches. Do you follow? Hi Erik, Your reply to me highlight the most important issue of all, we will have to re-learn all the workflow, adjust to new tools (which are not inherently integrated in Git but will have to be somehow configured and used) and get used to GitHub before we can be good citizens again. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From thomas.stuefe at gmail.com Wed Nov 13 14:15:21 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 13 Nov 2019 15:15:21 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: Hi Erik, First off thanks a lot to you and Joe for all your hard work. After we last talked about this in February I think this project is in good and unbiased hands. However, I share some of Andrews concerns. He voiced them more elaborately than I could, so just some additional thoughts: When we introduce a new channel of discussion, we risk splitting the community and damaging communication between us. We also risk off-putting existing developers and lose productivity. The assumption with this JEP is therefore that we gain more developers than we lose. These points should be clearly reflected under "Risk and Assumptions". In my mind these are bigger points even than the risk of locking in metadata with a proprietary provider. One smaller negative effect: mailing lists may receive less developer attention. You lose those developers which moves away to GitHub. This may lead to people not getting answers as promptly as before on non-RFR matters. The notion to keep both ways (mailing list + GitHub PRs) functional and "first class citizens" is great. But I'm afraid that it may turn out too brittle to keep up, and that the old side would rot away over time. Which would cause a sliding effect - frustrated developers switching away from mailing lists to GitHub, which would in turn leave less developers on the mailing lists, which makes for even less incentive to keep it working. Please do not understand this as me questioning your work - I am sure as long as the tools have your attention they will work. But I would feel better with a process which is less involved. One can say what one wants about mailing lists, but they are low tech and resilient. So, this is also an assumption - that the tool chain keeps working and that the effort spent maintaining it is less than the effort spent today on maintaining the old infrastructure (which to be fair is done by Oracle alone). One other risk to mention would be that even if you are happy with the way GitHub does represent PR discussions now, GitHub may change the interface any time they like. With mailing lists, one is independent of these interruptions. ----------- Smaller technical nits: Changing the subject line of mails depending on the review iterations does not play well with most email clients and with mailing list archives, which thread mails by subject line. It tears discussions apart. -- "Do not change the OpenJDK Bylaws. Do not change the OpenJDK Census." Should be listed under Non-Goals? Thank you, Thomas On Wed, Nov 13, 2019 at 12:42 PM Erik Helin wrote: > On 11/13/19 11:36 AM, Andrew Dinn wrote: > > On 12/11/2019 16:00, mark.reinhold at oracle.com wrote: > >> https://openjdk.java.net/jeps/369 > > Firstly, thanks to Joe and Erik for producing a very comprehensive JEP > > that addresses so many important questions. There are many aspects of > > this proposed move that are very appealing. > > Thanks Andrew for reading through it all and providing feedback! Please > see my replies inline. > > > However, I am afraid I am > > still going to start by expressing my severe reservations about one > > proposed change: replacing email review with GitHub PRs (sorry guys :-/). > > > > The JEP has this laudable goal: > > > > "Ensure that workflows structurally similar to the existing e-mail and > > webrev based workflows are supported." > > > > and further qualifies that with: > > > > "Today, OpenJDK contributors collaborate via mailing lists, they push > > changes to Mercurial repositories, they test changes via the jdk/submit > > service, and they file bug reports via the JDK Bug System (JBS). > > Contributors can also make use of several command-line interface (CLI) > > tools, primarily jcheck, webrev, and defpath. This is a workflow that > > many experienced contributors enjoy and find productive. It's therefore > > critical to preserve as much of this workflow as possible if we move to > > an external provider." > > > > which one cannot really disagree with. > > > > The JEP then explains that: > > > > "Reviewers can now discuss the changes in the PR, using multiple > workflows: > > > > By replying to the RFR email sent to the mailing list(s), in which > > case the contents of replies are copied into the PR on GitHub (no GitHub > > account is required); > > . . . > > Any comment made in any of the workflows is reflected in all of the > > workflows. One reviewer can add a comment via the mailing list, another > > via the web browser, and a third via the command-line and they will all > > see each others' comments." > > > > My experience of GitHub use in the Graal project suggest that this is > > not entirely the full picture. My view derived from that experience is > > that the GitHub PR is very much an inferior medium for review > > discussion. In particular, it definitely fails to be "structurally > > similar to the existing e-mail and webrev based workflows". > > I think the key sentence here is "My experience of GitHub use in the > Graal project...". Having worked with project on GitHub using Skara > tooling and projects on GitHub _not_ using Skara tooling, my view is > that the experiences differs quite a bit. > > > Firstly, I'll note that email discussions consist of a tree of dependent > > commentary. That commentary often contains quoted material which, > > especially when carefully edited (as it normally is), tracks relevant > > context. The structuring that results from this use of the reply > > hierarchy and quoting permits a given discussion to split into a group > > of related subordinate discussions where required while still retaining > > a continued thread of relevance to a specific review. Crucially, most > > email readers allow such branching discussions to be followed and > > extended in /parallel/. > > > > By contrast discussions in GitHub PRs are essentially linearized (modulo > > a single level of nesting of commentary on top level comments). Worse, > > the presentation forces all commentary to be flattened into a single > > browser pane view. This linear mode of presentation results in a severe > > hindrance to separation of, and attention to, separate concerns. It also > > fails to preserve and display source relationships that clarify the > > provenance and relevance of quoted text i.e. it not only fails to record > > but actually obfuscates important context. > > This does not paint the whole picture. You are probably thinking of the > "Conversation" tab in a GitHub pull request which is meant for *general* > discussion of the patch that is not attached to any particular change in > the patch. GitHub's own help documentation [0] states that the > "Conversation" tab is meant to be used for: > > You can comment on a pull request's Conversation tab to leave > general comments, questions, or props. > > You are right that comments in the "Conversation" tab are linearized and > does not support a "tree style" view of comments. > > The good news are that the _other_ form of comments available on a > GitHub pull request, a so-called "review comment" or "file comment" [1], > does support replies in the form of a tree. These comments are filed > under the "Files changed" tab in a pull request. > > Personally I think of the comments in the "Conversation" tab as replies > to the "00" email in a classic patch series email and the "review > comments" in the "Files changed" tab as replies to the "0X" emails > actually containing patches. Do you follow? > > Now the interesting question is of course how the Skara tooling > translates these kinds of comments back-and-forth between mailing lists > and GitHub. Here I'm happy to report that the Skara tooling does proper > replying, which will cause the "review comments" created under the > "Files changed" tab on a pull request to result in a tree-view (in email > clients that support such views). > > You can see of some of this work on the openjfx-dev mailing list [2]. > Now keep in mind if you are looking at Pipermail rendering of a mailing > list, which lacks some features that most email clients supports (such > as folding quoted text and nested replies beyond three levels). A > mailing list version of a pull request will in general have the > following structure: > > - RFR: Fix a bug <-- Email describing patch > - Re: RFR: Fix a bug <-- This is a general comment > - Re: RFR: Fix a bug <-- This is a reply to the general comment > - Re: [Rev 01]: RFR: Fix a bug <-- The author updated the patch > - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer A on 01 > - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from A on 01 > - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer B on 01 > - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from B on 01 > - Re: [Rev 02]: RFR: Fix a bug <-- The author updated again > - Re: [Approved] RFR: Fix a bug <-- Reviewer A approved the patch > - Re: [Approved] RFR: Fix a bug <-- Reviewer B approved the patch > - Re: [Integrated] RFR: Fix a bug <-- Author integrated the patch > > We are tweaking this structure as we get more and more experience with > it, but at the moment I'm fairly satisfied with threading and the tree > layout. If you have any feedback on this structure/layout, then we are > happy to hear it. > > Going in the other direction, mailing list -> GitHub, we also try to > preserve the mailing list structure as much as possible. This is > actually a harder challenge, since an email is less structured compared > to a comment on GitHub. An example of this direction can be found in > pull request 231 for the Skara repository [3] where you can see the > thread (which is a tree) from skara-dev at openjdk.java.net [4] being > "flattened" and uses quotation to try to preserve the flow. > > > Of course, discussions that remain in email may continue to profit from > > the multi-focus aspect of the current workflow. However, I believe that > > contributions to the discussion via a GitHub PR will inevitably bypass > > and, therefore, invalidate any such structuring contributed via the > > email workflow. Not only do I currently see that effect with Graal PRs > > but I also see the damage it imposes on flow and quality of discussion. > > > > Secondly, email reviews are conventionally directed to readers with > > different domains of interest and expertise. That sometimes requires > > re-routing a discussion to a different list from the one on which it was > > first initiated. It also sometimes requires posting comments to multiple > > lists, either when discussion is initiated or in mid-stream as the scope > > of discussion develops. Managing distribution when using emails lists is > > both easily achieved and well understood (n.b. that's not to imply that > > deciding which list to send to is easy). > > Here we are currently working on the /cc command that can be used in a > comment on pull request, for example: > > /cc build-dev hotspot-dev > > > The JEP suggests that discussions raised via PRs will be routed to lists > > 1) derived from the affected files and/or 2) specified by whoever raises > > the PR. It doesn't explain how (whether) target lists are to be (may be) > > updated as review progresses. It also doesn't state clearly whether > > whoever raises the PR or comments on it will have the ability to > > override those default choices (I fully expect that option will be > > necessary in some cases). > > Agree, see the command above that we are working on :) > > > I need to stress that these concerns should not be considered as minor > > details of how the project operates. Easy management of the flow and > > direction of discussion is critical to being able to consume and respond > > to commentary at the rate needed to keep up with a project as large and > > rapidly changing as OpenJDK currently is. Given the central importance > > of our review process to ensuring the health of the project and its > > products I think it is right to be very concerned about the potential > > for problems caused by this switch of medium. > > I hope that is does not come across that we are taking mailing list > interopability as a minor detail? I think it is fair to say that this is > the Skara feature we have spent the most time working on and are > constantly improving in order to provide a good experience. > > Thanks, > Erik > > [0]: > > https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request > [1]: > > https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request > [2]: > > https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-November/thread.html > [3]: https://git.openjdk.java.net/skara/pull/231 > [4]: > https://mail.openjdk.java.net/pipermail/skara-dev/2019-October/000998.html > > > regards, > > > > > > Andrew Dinn > > ----------- > > Senior Principal Software Engineer > > Red Hat UK Ltd > > Registered in England and Wales under Company Registration No. 03798903 > > Directors: Michael Cunningham, Michael ("Mike") O'Neill > > > > From erik.helin at oracle.com Wed Nov 13 15:00:08 2019 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 13 Nov 2019 16:00:08 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: On 11/13/19 3:15 PM, Thomas St?fe wrote: > Hi Erik, Hi Thomas, hope you are doing well! > First off thanks a lot to you and Joe for all your hard work. There are many more than me and Joe that have contributed to Skara :) In no particular order, a big thanks to: - Robin Westberg - Mark Reinhold - Erik Joelsson - Tony Squier - Kevin Rushforth - Jorn Vernee - Stanislav Smirnov - Christian Tornqvist - Dalibor Topic - Jeff Dinkins - Tim Bell - Marcus Hirt > After we > last talked about this in February I think this project is in good and > unbiased hands. > > However, I?share some of Andrews concerns. He voiced them more > elaborately than I could, so just some additional thoughts: > > When we introduce a new channel of discussion, we risk splitting the > community and damaging communication between us. We also risk > off-putting existing developers and lose productivity. The assumption > with this JEP is therefore that we gain more developers than we lose. No, the assumption is definitely *not* that we would lose developers. We will hopefully gain some contributors, but I don't intend to lose any. > These points should be clearly reflected under "Risk and Assumptions". > In my mind these are bigger points even than the risk of locking in > metadata with a proprietary provider. > > One smaller negative effect: mailing lists may receive less developer > attention. You lose those developers which moves away to GitHub. This > may lead to people not getting answers as promptly as before on non-RFR > matters. A contributor to OpenJDK will still be expected to follow and be active on the OpenJDK mailing lists, that does not change with Skara nor with a move to GitHub. For the Skara project iself, this is something we actively communicate on GitHub, see for example the Skara README [0] and Skara's contribution guidelines [1] (shown the first time a GitHub user submits a pull request targeting Skara). If needed we will communicate this even further by for example using pull request templates [2] (show every time a pull request is submitted). These communication techniques can of course also be utilized for other projects, e.g. the JDK project, if wanted. > The notion to keep both ways (mailing list + GitHub PRs) functional and > "first class citizens" is great. But I'm afraid that it may turn out too > brittle to keep up, and that the old side would rot away over time. > Which would cause a sliding effect - frustrated developers switching > away from mailing lists to GitHub, which would in turn leave less > developers on the mailing lists, which makes for even less incentive to > keep it working. There is no such thing as "switching away from mailing lists to GitHub". All activity on GitHub is mirrored on the OpenJDK mailing lists. And as I stated above, an active OpenJDK contributor is absolutely expected to follow and be active on the mailing lists. There is much more activity on the mailing lists besides "RFR" emails: - design discussion - call for votes - announcements - JEP discussion (such as this one) - occasional bug reports - etc. > Please do not understand this as me questioning your work - I am sure as > long as the tools have your attention they will work. But I would feel > better with a process which is less involved. One can say what one wants > about mailing lists, but they are low tech and resilient. > > So, this is also an assumption - that the tool chain keeps working and > that the effort spent maintaining it is less than the effort spent today > on maintaining the old infrastructure (which to be fair is done by > Oracle alone). Yes, the Skara tools need to keep on working, that is correct. That is, as you also state, of course true for all the infrastructure supporting OpenJDK. The Skara tooling has been written with ease of maintenance in mind. The tools are written in Java, the only dependencies are Gradle for building and JUnit for testing. We have plenty of unit tests and integration tests and the bots themselves are written in a polling and mostly stateless architecture. The Skara tooling is also open source [3] and we have already gotten some very nice community contributions (thanks!). > One other risk to mention would be that even if you are happy with the > way GitHub does represent PR discussions now, GitHub may change the > interface any time they like. With mailing lists, one is independent of > these interruptions. Again, you will not loose the mailing lists :) If you don't like the GitHub UI, then use one of the several third-party clients and/or interact via the mailing lists. We will likely discover some kinks with the bi-directional mailing list synchronization that we will have to work out, but so far things have been working very well (otherwise we wouldn't be submitting this JEP). Thanks, Erik [0]: https://git.openjdk.java.net/skara#discuss [1]: https://git.openjdk.java.net/skara/blob/master/CONTRIBUTING.md [2]: https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates [3]: https://git.openjdk.java.net/skara > ----------- > > Smaller technical nits: > > Changing the subject line of mails depending on the review iterations > does not play well with most email clients and with mailing list > archives, which thread mails by subject line. It tears discussions apart. > > -- > > "Do not change the OpenJDK Bylaws. > ?Do not change the OpenJDK Census." > > Should be listed under Non-Goals? > > Thank you, > > Thomas > > > On Wed, Nov 13, 2019 at 12:42 PM Erik Helin > wrote: > > On 11/13/19 11:36 AM, Andrew Dinn wrote: > > On 12/11/2019 16:00, mark.reinhold at oracle.com > wrote: > >> https://openjdk.java.net/jeps/369 > > Firstly, thanks to Joe and Erik for producing a very > comprehensive JEP > > that addresses so many important questions. There are many aspects of > > this proposed move that are very appealing. > > Thanks Andrew for reading through it all and providing feedback! Please > see my replies inline. > > > However, I am afraid I am > > still going to start by expressing my severe reservations about one > > proposed change: replacing email review with GitHub PRs (sorry > guys :-/). > > > > The JEP has this laudable goal: > > > > "Ensure that workflows structurally similar to the existing > e-mail and > > webrev based workflows are supported." > > > > and further qualifies that with: > > > > "Today, OpenJDK contributors collaborate via mailing lists, they push > > changes to Mercurial repositories, they test changes via the > jdk/submit > > service, and they file bug reports via the JDK Bug System (JBS). > > Contributors can also make use of several command-line interface > (CLI) > > tools, primarily jcheck, webrev, and defpath. This is a workflow that > > many experienced contributors enjoy and find productive. It's > therefore > > critical to preserve as much of this workflow as possible if we > move to > > an external provider." > > > > which one cannot really disagree with. > > > > The JEP then explains that: > > > > "Reviewers can now discuss the changes in the PR, using multiple > workflows: > > > >? ? ? By replying to the RFR email sent to the mailing list(s), in > which > > case the contents of replies are copied into the PR on GitHub (no > GitHub > > account is required); > >? ? ?. . . > > Any comment made in any of the workflows is reflected in all of the > > workflows. One reviewer can add a comment via the mailing list, > another > > via the web browser, and a third via the command-line and they > will all > > see each others' comments." > > > > My experience of GitHub use in the Graal project suggest that this is > > not entirely the full picture. My view derived from that > experience is > > that the GitHub PR is very much an inferior medium for review > > discussion. In particular, it definitely fails to be "structurally > > similar to the existing e-mail and webrev based workflows". > > I think the key sentence here is "My experience of GitHub use in the > Graal project...". Having worked with project on GitHub using Skara > tooling and projects on GitHub _not_ using Skara tooling, my view is > that the experiences differs quite a bit. > > > Firstly, I'll note that email discussions consist of a tree of > dependent > > commentary. That commentary often contains quoted material which, > > especially when carefully edited (as it normally is), tracks relevant > > context. The structuring that results from this use of the reply > > hierarchy and quoting permits a given discussion to split into a > group > > of related subordinate discussions where required while still > retaining > > a continued thread of relevance to a specific review. Crucially, most > > email readers allow such branching discussions to be followed and > > extended in /parallel/. > > > > By contrast discussions in GitHub PRs are essentially linearized > (modulo > > a single level of nesting of commentary on top level comments). > Worse, > > the presentation forces all commentary to be flattened into a single > > browser pane view. This linear mode of presentation results in a > severe > > hindrance to separation of, and attention to, separate concerns. > It also > > fails to preserve and display source relationships that clarify the > > provenance and relevance of quoted text i.e. it not only fails to > record > > but actually obfuscates important context. > > This does not paint the whole picture. You are probably thinking of the > "Conversation" tab in a GitHub pull request which is meant for > *general* > discussion of the patch that is not attached to any particular > change in > the patch. GitHub's own help documentation [0] states that the > "Conversation" tab is meant to be used for: > > ? ? ?You can comment on a pull request's Conversation tab to leave > ? ? ?general comments, questions, or props. > > You are right that comments in the "Conversation" tab are linearized > and > does not support a "tree style" view of comments. > > The good news are that the _other_ form of comments available on a > GitHub pull request, a so-called "review comment" or "file comment" > [1], > does support replies in the form of a tree. These comments are filed > under the "Files changed" tab in a pull request. > > Personally I think of the comments in the "Conversation" tab as replies > to the "00" email in a classic patch series email and the "review > comments" in the "Files changed" tab as replies to the "0X" emails > actually containing patches. Do you follow? > > Now the interesting question is of course how the Skara tooling > translates these kinds of comments back-and-forth between mailing lists > and GitHub. Here I'm happy to report that the Skara tooling does proper > replying, which will cause the "review comments" created under the > "Files changed" tab on a pull request to result in a tree-view (in > email > clients that support such views). > > You can see of some of this work on the openjfx-dev mailing list [2]. > Now keep in mind if you are looking at Pipermail rendering of a mailing > list, which lacks some features that most email clients supports (such > as folding quoted text and nested replies beyond three levels). A > mailing list version of a pull request will in general have the > following structure: > > - RFR: Fix a bug <-- Email describing patch > ? ?- Re: RFR: Fix a bug <-- This is a general comment > ? ? ?- Re: RFR: Fix a bug <-- This is a reply to the general comment > ? ?- Re: [Rev 01]: RFR: Fix a bug <-- The author updated the patch > ? ? ?- Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer A on 01 > ? ? ? ?- Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from A on 01 > ? ? ?- Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer B on 01 > ? ? ? ?- Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from B on 01 > ? ?- Re: [Rev 02]: RFR: Fix a bug <-- The author updated again > ? ?- Re: [Approved] RFR: Fix a bug <-- Reviewer A approved the patch > ? ?- Re: [Approved] RFR: Fix a bug <-- Reviewer B approved the patch > ? ?- Re: [Integrated] RFR: Fix a bug <-- Author integrated the patch > > We are tweaking this structure as we get more and more experience with > it, but at the moment I'm fairly satisfied with threading and the tree > layout. If you have any feedback on this structure/layout, then we are > happy to hear it. > > Going in the other direction, mailing list -> GitHub, we also try to > preserve the mailing list structure as much as possible. This is > actually a harder challenge, since an email is less structured compared > to a comment on GitHub. An example of this direction can be found in > pull request 231 for the Skara repository [3] where you can see the > thread (which is a tree) from skara-dev at openjdk.java.net > [4] being > "flattened" and uses quotation to try to preserve the flow. > > > Of course, discussions that remain in email may continue to > profit from > > the multi-focus aspect of the current workflow. However, I > believe that > > contributions to the discussion via a GitHub PR will inevitably > bypass > > and, therefore, invalidate any such structuring contributed via the > > email workflow. Not only do I currently see that effect with > Graal PRs > > but I also see the damage it imposes on flow and quality of > discussion. > > > > Secondly, email reviews are conventionally directed to readers with > > different domains of interest and expertise. That sometimes requires > > re-routing a discussion to a different list from the one on which > it was > > first initiated. It also sometimes requires posting comments to > multiple > > lists, either when discussion is initiated or in mid-stream as > the scope > > of discussion develops. Managing distribution when using emails > lists is > > both easily achieved and well understood (n.b. that's not to > imply that > > deciding which list to send to is easy). > > Here we are currently working on the /cc command that can be used in a > comment on pull request, for example: > > ? ? ?/cc build-dev hotspot-dev > > > The JEP suggests that discussions raised via PRs will be routed > to lists > > 1) derived from the affected files and/or 2) specified by whoever > raises > > the PR. It doesn't explain how (whether) target lists are to be > (may be) > > updated as review progresses. It also doesn't state clearly whether > > whoever raises the PR or comments on it will have the ability to > > override those default choices (I fully expect that option will be > > necessary in some cases). > > Agree, see the command above that we are working on :) > > > I need to stress that these concerns should not be considered as > minor > > details of how the project operates. Easy management of the flow and > > direction of discussion is critical to being able to consume and > respond > > to commentary at the rate needed to keep up with a project as > large and > > rapidly changing as OpenJDK currently is. Given the central > importance > > of our review process to ensuring the health of the project and its > > products I think it is right to be very concerned about the potential > > for problems caused by this switch of medium. > > I hope that is does not come across that we are taking mailing list > interopability as a minor detail? I think it is fair to say that > this is > the Skara feature we have spent the most time working on and are > constantly improving in order to provide a good experience. > > Thanks, > Erik > > [0]: > https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request > [1]: > https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request > [2]: > https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-November/thread.html > [3]: https://git.openjdk.java.net/skara/pull/231 > [4]: > https://mail.openjdk.java.net/pipermail/skara-dev/2019-October/000998.html > > > regards, > > > > > > Andrew Dinn > > ----------- > > Senior Principal Software Engineer > > Red Hat UK Ltd > > Registered in England and Wales under Company Registration No. > 03798903 > > Directors: Michael Cunningham, Michael ("Mike") O'Neill > > > From kevin.rushforth at oracle.com Wed Nov 13 16:21:41 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 13 Nov 2019 08:21:41 -0800 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> I would like to add my experience with Skara. I lead the OpenJFX project [1] along with Johan Vos. We are one of the early adopters of Skara, having recently moved our official repo to GitHub as an early access test of the Skara tooling and the transition to Git / GitHub. We've been using it exclusively for over a month now, with positive results. Our experience with doing reviews on GitHub goes back even farther. About a year prior to moving our official repo from hg.openjdk.java.net to GitHub, we setup a mirror repo on GitHub that could be used as an alternative to webrev for code reviews. What we found during the past year is that most (but not all) contributors started using the GitHub sandbox as their preferred mode for doing code reviews. We were able to attract several new contributors who might not otherwise have felt they were able to participate. The one downside we had during that year is that we still had to export the commit from Git after the review was finished and import it into a Mercurial changeset. With the official repo being on GitHub, and the Skara tooling enabled, that extra step is gone and we have a smooth workflow. I have found it easier, not harder, to exchange feedback on proposed changes using GitHub -- I think it's much easier to comment on a block of code inline rather than copying and pasting it from the webrev into an email message. One of the nice things about the Skara tooling, though, is that reviewers have their choice. Since review comments are cross-forwarded between the mailing list and the PR, both modes are supported. There are some wrinkles in the tooling, but the Skara team has been very responsive in addressing them. To be sure, there is a bit of a learning curve moving to Git and moving to a pull request model where each developer has a fork of the actual repo, but I think that the benefits outweigh the drawbacks. -- Kevin [1] https://github.com/openjdk/jfx On 11/13/2019 7:00 AM, Erik Helin wrote: > On 11/13/19 3:15 PM, Thomas St?fe wrote: >> Hi Erik, > > Hi Thomas, hope you are doing well! > >> First off thanks a lot to you and Joe for all your hard work. > > There are many more than me and Joe that have contributed to Skara :) > In no particular order, a big thanks to: > - Robin Westberg > - Mark Reinhold > - Erik Joelsson > - Tony Squier > - Kevin Rushforth > - Jorn Vernee > - Stanislav Smirnov > - Christian Tornqvist > - Dalibor Topic > - Jeff Dinkins > - Tim Bell > - Marcus Hirt > >> After we last talked about this in February I think this project is >> in good and unbiased hands. >> >> However, I?share some of Andrews concerns. He voiced them more >> elaborately than I could, so just some additional thoughts: >> >> When we introduce a new channel of discussion, we risk splitting the >> community and damaging communication between us. We also risk >> off-putting existing developers and lose productivity. The assumption >> with this JEP is therefore that we gain more developers than we lose. > > No, the assumption is definitely *not* that we would lose developers. > We will hopefully gain some contributors, but I don't intend to lose any. > >> These points should be clearly reflected under "Risk and >> Assumptions". In my mind these are bigger points even than the risk >> of locking in metadata with a proprietary provider. >> >> One smaller negative effect: mailing lists may receive less developer >> attention. You lose those developers which moves away to GitHub. This >> may lead to people not getting answers as promptly as before on >> non-RFR matters. > > A contributor to OpenJDK will still be expected to follow and be > active on the OpenJDK mailing lists, that does not change with Skara > nor with a move to GitHub. For the Skara project iself, this is > something we actively communicate on GitHub, see for example the Skara > README [0] and Skara's contribution guidelines [1] (shown the first > time a GitHub user submits a pull request targeting Skara). If needed > we will communicate this even further by for example using pull > request templates [2] (show every time a pull request is submitted). > > These communication techniques can of course also be utilized for > other projects, e.g. the JDK project, if wanted. > >> The notion to keep both ways (mailing list + GitHub PRs) functional >> and "first class citizens" is great. But I'm afraid that it may turn >> out too brittle to keep up, and that the old side would rot away over >> time. Which would cause a sliding effect - frustrated developers >> switching away from mailing lists to GitHub, which would in turn >> leave less developers on the mailing lists, which makes for even less >> incentive to keep it working. > > There is no such thing as "switching away from mailing lists to > GitHub". All activity on GitHub is mirrored on the OpenJDK mailing > lists. And as I stated above, an active OpenJDK contributor is > absolutely expected to follow and be active on the mailing lists. > There is much more activity on the mailing lists besides "RFR" emails: > - design discussion > - call for votes > - announcements > - JEP discussion (such as this one) > - occasional bug reports > - etc. > >> Please do not understand this as me questioning your work - I am sure >> as long as the tools have your attention they will work. But I would >> feel better with a process which is less involved. One can say what >> one wants about mailing lists, but they are low tech and resilient. >> >> So, this is also an assumption - that the tool chain keeps working >> and that the effort spent maintaining it is less than the effort >> spent today on maintaining the old infrastructure (which to be fair >> is done by Oracle alone). > > Yes, the Skara tools need to keep on working, that is correct. That > is, as you also state, of course true for all the infrastructure > supporting OpenJDK. > > The Skara tooling has been written with ease of maintenance in mind. > The tools are written in Java, the only dependencies are Gradle for > building and JUnit for testing. We have plenty of unit tests and > integration tests and the bots themselves are written in a polling and > mostly stateless architecture. > > The Skara tooling is also open source [3] and we have already gotten > some very nice community contributions (thanks!). > >> One other risk to mention would be that even if you are happy with >> the way GitHub does represent PR discussions now, GitHub may change >> the interface any time they like. With mailing lists, one is >> independent of these interruptions. > > Again, you will not loose the mailing lists :) If you don't like the > GitHub UI, then use one of the several third-party clients and/or > interact via the mailing lists. We will likely discover some kinks > with the bi-directional mailing list synchronization that we will have > to work out, but so far things have been working very well (otherwise > we wouldn't be submitting this JEP). > > Thanks, > Erik > > [0]: https://git.openjdk.java.net/skara#discuss > [1]: https://git.openjdk.java.net/skara/blob/master/CONTRIBUTING.md > [2]: > https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates > [3]: https://git.openjdk.java.net/skara > >> ----------- >> >> Smaller technical nits: >> >> Changing the subject line of mails depending on the review iterations >> does not play well with most email clients and with mailing list >> archives, which thread mails by subject line. It tears discussions >> apart. >> >> -- >> >> "Do not change the OpenJDK Bylaws. >> ??Do not change the OpenJDK Census." >> >> Should be listed under Non-Goals? >> >> Thank you, >> >> Thomas >> >> >> On Wed, Nov 13, 2019 at 12:42 PM Erik Helin > > wrote: >> >> ??? On 11/13/19 11:36 AM, Andrew Dinn wrote: >> ???? > On 12/11/2019 16:00, mark.reinhold at oracle.com >> ??? wrote: >> ???? >> https://openjdk.java.net/jeps/369 >> ???? > Firstly, thanks to Joe and Erik for producing a very >> ??? comprehensive JEP >> ???? > that addresses so many important questions. There are many >> aspects of >> ???? > this proposed move that are very appealing. >> >> ??? Thanks Andrew for reading through it all and providing feedback! >> Please >> ??? see my replies inline. >> >> ???? > However, I am afraid I am >> ???? > still going to start by expressing my severe reservations >> about one >> ???? > proposed change: replacing email review with GitHub PRs (sorry >> ??? guys :-/). >> ???? > >> ???? > The JEP has this laudable goal: >> ???? > >> ???? > "Ensure that workflows structurally similar to the existing >> ??? e-mail and >> ???? > webrev based workflows are supported." >> ???? > >> ???? > and further qualifies that with: >> ???? > >> ???? > "Today, OpenJDK contributors collaborate via mailing lists, >> they push >> ???? > changes to Mercurial repositories, they test changes via the >> ??? jdk/submit >> ???? > service, and they file bug reports via the JDK Bug System (JBS). >> ???? > Contributors can also make use of several command-line interface >> ??? (CLI) >> ???? > tools, primarily jcheck, webrev, and defpath. This is a >> workflow that >> ???? > many experienced contributors enjoy and find productive. It's >> ??? therefore >> ???? > critical to preserve as much of this workflow as possible if we >> ??? move to >> ???? > an external provider." >> ???? > >> ???? > which one cannot really disagree with. >> ???? > >> ???? > The JEP then explains that: >> ???? > >> ???? > "Reviewers can now discuss the changes in the PR, using multiple >> ??? workflows: >> ???? > >> ???? >? ? ? By replying to the RFR email sent to the mailing list(s), in >> ??? which >> ???? > case the contents of replies are copied into the PR on GitHub (no >> ??? GitHub >> ???? > account is required); >> ???? >? ? ?. . . >> ???? > Any comment made in any of the workflows is reflected in all >> of the >> ???? > workflows. One reviewer can add a comment via the mailing list, >> ??? another >> ???? > via the web browser, and a third via the command-line and they >> ??? will all >> ???? > see each others' comments." >> ???? > >> ???? > My experience of GitHub use in the Graal project suggest that >> this is >> ???? > not entirely the full picture. My view derived from that >> ??? experience is >> ???? > that the GitHub PR is very much an inferior medium for review >> ???? > discussion. In particular, it definitely fails to be >> "structurally >> ???? > similar to the existing e-mail and webrev based workflows". >> >> ??? I think the key sentence here is "My experience of GitHub use in the >> ??? Graal project...". Having worked with project on GitHub using Skara >> ??? tooling and projects on GitHub _not_ using Skara tooling, my view is >> ??? that the experiences differs quite a bit. >> >> ???? > Firstly, I'll note that email discussions consist of a tree of >> ??? dependent >> ???? > commentary. That commentary often contains quoted material which, >> ???? > especially when carefully edited (as it normally is), tracks >> relevant >> ???? > context. The structuring that results from this use of the reply >> ???? > hierarchy and quoting permits a given discussion to split into a >> ??? group >> ???? > of related subordinate discussions where required while still >> ??? retaining >> ???? > a continued thread of relevance to a specific review. >> Crucially, most >> ???? > email readers allow such branching discussions to be followed and >> ???? > extended in /parallel/. >> ???? > >> ???? > By contrast discussions in GitHub PRs are essentially linearized >> ??? (modulo >> ???? > a single level of nesting of commentary on top level comments). >> ??? Worse, >> ???? > the presentation forces all commentary to be flattened into a >> single >> ???? > browser pane view. This linear mode of presentation results in a >> ??? severe >> ???? > hindrance to separation of, and attention to, separate concerns. >> ??? It also >> ???? > fails to preserve and display source relationships that >> clarify the >> ???? > provenance and relevance of quoted text i.e. it not only fails to >> ??? record >> ???? > but actually obfuscates important context. >> >> ??? This does not paint the whole picture. You are probably thinking >> of the >> ??? "Conversation" tab in a GitHub pull request which is meant for >> ??? *general* >> ??? discussion of the patch that is not attached to any particular >> ??? change in >> ??? the patch. GitHub's own help documentation [0] states that the >> ??? "Conversation" tab is meant to be used for: >> >> ???? ? ? ?You can comment on a pull request's Conversation tab to leave >> ???? ? ? ?general comments, questions, or props. >> >> ??? You are right that comments in the "Conversation" tab are linearized >> ??? and >> ??? does not support a "tree style" view of comments. >> >> ??? The good news are that the _other_ form of comments available on a >> ??? GitHub pull request, a so-called "review comment" or "file comment" >> ??? [1], >> ??? does support replies in the form of a tree. These comments are filed >> ??? under the "Files changed" tab in a pull request. >> >> ??? Personally I think of the comments in the "Conversation" tab as >> replies >> ??? to the "00" email in a classic patch series email and the "review >> ??? comments" in the "Files changed" tab as replies to the "0X" emails >> ??? actually containing patches. Do you follow? >> >> ??? Now the interesting question is of course how the Skara tooling >> ??? translates these kinds of comments back-and-forth between mailing >> lists >> ??? and GitHub. Here I'm happy to report that the Skara tooling does >> proper >> ??? replying, which will cause the "review comments" created under the >> ??? "Files changed" tab on a pull request to result in a tree-view (in >> ??? email >> ??? clients that support such views). >> >> ??? You can see of some of this work on the openjfx-dev mailing list >> [2]. >> ??? Now keep in mind if you are looking at Pipermail rendering of a >> mailing >> ??? list, which lacks some features that most email clients supports >> (such >> ??? as folding quoted text and nested replies beyond three levels). A >> ??? mailing list version of a pull request will in general have the >> ??? following structure: >> >> ??? - RFR: Fix a bug <-- Email describing patch >> ???? ? ?- Re: RFR: Fix a bug <-- This is a general comment >> ???? ? ? ?- Re: RFR: Fix a bug <-- This is a reply to the general >> comment >> ???? ? ?- Re: [Rev 01]: RFR: Fix a bug <-- The author updated the patch >> ???? ? ? ?- Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer A >> on 01 >> ???? ? ? ? ?- Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from >> A on 01 >> ???? ? ? ?- Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer B >> on 01 >> ???? ? ? ? ?- Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from >> B on 01 >> ???? ? ?- Re: [Rev 02]: RFR: Fix a bug <-- The author updated again >> ???? ? ?- Re: [Approved] RFR: Fix a bug <-- Reviewer A approved the >> patch >> ???? ? ?- Re: [Approved] RFR: Fix a bug <-- Reviewer B approved the >> patch >> ???? ? ?- Re: [Integrated] RFR: Fix a bug <-- Author integrated the >> patch >> >> ??? We are tweaking this structure as we get more and more experience >> with >> ??? it, but at the moment I'm fairly satisfied with threading and the >> tree >> ??? layout. If you have any feedback on this structure/layout, then >> we are >> ??? happy to hear it. >> >> ??? Going in the other direction, mailing list -> GitHub, we also try to >> ??? preserve the mailing list structure as much as possible. This is >> ??? actually a harder challenge, since an email is less structured >> compared >> ??? to a comment on GitHub. An example of this direction can be found in >> ??? pull request 231 for the Skara repository [3] where you can see the >> ??? thread (which is a tree) from skara-dev at openjdk.java.net >> ??? [4] being >> ??? "flattened" and uses quotation to try to preserve the flow. >> >> ???? > Of course, discussions that remain in email may continue to >> ??? profit from >> ???? > the multi-focus aspect of the current workflow. However, I >> ??? believe that >> ???? > contributions to the discussion via a GitHub PR will inevitably >> ??? bypass >> ???? > and, therefore, invalidate any such structuring contributed >> via the >> ???? > email workflow. Not only do I currently see that effect with >> ??? Graal PRs >> ???? > but I also see the damage it imposes on flow and quality of >> ??? discussion. >> ???? > >> ???? > Secondly, email reviews are conventionally directed to readers >> with >> ???? > different domains of interest and expertise. That sometimes >> requires >> ???? > re-routing a discussion to a different list from the one on which >> ??? it was >> ???? > first initiated. It also sometimes requires posting comments to >> ??? multiple >> ???? > lists, either when discussion is initiated or in mid-stream as >> ??? the scope >> ???? > of discussion develops. Managing distribution when using emails >> ??? lists is >> ???? > both easily achieved and well understood (n.b. that's not to >> ??? imply that >> ???? > deciding which list to send to is easy). >> >> ??? Here we are currently working on the /cc command that can be used >> in a >> ??? comment on pull request, for example: >> >> ???? ? ? ?/cc build-dev hotspot-dev >> >> ???? > The JEP suggests that discussions raised via PRs will be routed >> ??? to lists >> ???? > 1) derived from the affected files and/or 2) specified by whoever >> ??? raises >> ???? > the PR. It doesn't explain how (whether) target lists are to be >> ??? (may be) >> ???? > updated as review progresses. It also doesn't state clearly >> whether >> ???? > whoever raises the PR or comments on it will have the ability to >> ???? > override those default choices (I fully expect that option >> will be >> ???? > necessary in some cases). >> >> ??? Agree, see the command above that we are working on :) >> >> ???? > I need to stress that these concerns should not be considered as >> ??? minor >> ???? > details of how the project operates. Easy management of the >> flow and >> ???? > direction of discussion is critical to being able to consume and >> ??? respond >> ???? > to commentary at the rate needed to keep up with a project as >> ??? large and >> ???? > rapidly changing as OpenJDK currently is. Given the central >> ??? importance >> ???? > of our review process to ensuring the health of the project >> and its >> ???? > products I think it is right to be very concerned about the >> potential >> ???? > for problems caused by this switch of medium. >> >> ??? I hope that is does not come across that we are taking mailing list >> ??? interopability as a minor detail? I think it is fair to say that >> ??? this is >> ??? the Skara feature we have spent the most time working on and are >> ??? constantly improving in order to provide a good experience. >> >> ??? Thanks, >> ??? Erik >> >> ??? [0]: >> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request >> ??? [1]: >> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request >> ??? [2]: >> https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-November/thread.html >> ??? [3]: https://git.openjdk.java.net/skara/pull/231 >> ??? [4]: >> https://mail.openjdk.java.net/pipermail/skara-dev/2019-October/000998.html >> >> ???? > regards, >> ???? > >> ???? > >> ???? > Andrew Dinn >> ???? > ----------- >> ???? > Senior Principal Software Engineer >> ???? > Red Hat UK Ltd >> ???? > Registered in England and Wales under Company Registration No. >> ??? 03798903 >> ???? > Directors: Michael Cunningham, Michael ("Mike") O'Neill >> ???? > >> > From adinn at redhat.com Wed Nov 13 17:39:49 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 13 Nov 2019 17:39:49 +0000 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: <6243b540-60fc-8a3b-7c69-1ff4b18742be@redhat.com> On 13/11/2019 11:42, Erik Helin wrote: > Thanks Andrew for reading through it all and providing feedback! Please > see my replies inline. You are very welcome. It definitely merits a considered and fair review. >> My experience of GitHub use in the Graal project suggest that this is >> not entirely the full picture. My view derived from that experience is >> that the GitHub PR is very much an inferior medium for review >> discussion. In particular, it definitely fails to be "structurally >> similar to the existing e-mail and webrev based workflows". > > I think the key sentence here is "My experience of GitHub use in the > Graal project...". Having worked with project on GitHub using Skara > tooling and projects on GitHub _not_ using Skara tooling, my view is > that the experiences differs quite a bit. I am happy to hear that you will be supplementing the standard GitHub experience with extra tooling. I also must apologize for not looking at Skara before writing a critique that perhaps does not do it justice. I will take a look and post my thoughts. > This does not paint the whole picture. You are probably thinking of the > "Conversation" tab in a GitHub pull request which is meant for *general* > discussion of the patch that is not attached to any particular change in > the patch. GitHub's own help documentation [0] states that the > "Conversation" tab is meant to be used for: > > ??? You can comment on a pull request's Conversation tab to leave > ??? general comments, questions, or props. > > You are right that comments in the "Conversation" tab are linearized and > does not support a "tree style" view of comments. > > The good news are that the _other_ form of comments available on a > GitHub pull request, a so-called "review comment" or "file comment" [1], > does support replies in the form of a tree. These comments are filed > under the "Files changed" tab in a pull request. I'm afraid that makes it sound worse not better. This bifurcates the review process into 'general comments' vs 'critique on the code per se', with the former forced into a linear frame while the latter can benefit from divide and conquer distinctions. I fear that's an artificial division of concerns that will make it harder still to reconcile general points with the evidence base for deriving them. > Personally I think of the comments in the "Conversation" tab as replies > to the "00" email in a classic patch series email and the "review > comments" in the "Files changed" tab as replies to the "0X" emails > actually containing patches. Do you follow? Well, I agree that sometimes that will work ok. However, I may be wrong here but I believe that the code comments are tied to a specific point in the file/change set. That's ok when a comment only relates to one change. When you wish comment on the combined effect of two or more changes at different points in the file the requirement to attach a comment to one specific change doesn't really work. Punting such comments to the 00 thread doesn't do it either. Quoting the relevant lines in a follow-up note does bring the relevant changes into the scope of preceding and subsequent replies. The root point here is that the GitHub PR presentation model is going to impose constraints on the way we structure and link our review comments because it needs them to conform to it's information structure that is essentially driven by it's web page layout. email is inherently much more flexible because it is just a hierarchically linked set of texts. Of course, GitHub provides aids to simplify the task of creating and linking information in its format. Whereas with email one has to explicitly structure the information by editing it and placing it in a reply sequence. I can see GitHub making some things a lot easier. However, my concern is that it may well make some important things that we do difficult or maybe even impossible (at the least impractical). > Now the interesting question is of course how the Skara tooling > translates these kinds of comments back-and-forth between mailing lists > and GitHub. Here I'm happy to report that the Skara tooling does proper > replying, which will cause the "review comments" created under the > "Files changed" tab on a pull request to result in a tree-view (in email > clients that support such views). > > You can see of some of this work on the openjfx-dev mailing list [2]. > Now keep in mind if you are looking at Pipermail rendering of a mailing > list, which lacks some features that most email clients supports (such > as folding quoted text and nested replies beyond three levels). A > mailing list version of a pull request will in general have the > following structure: > > - RFR: Fix a bug <-- Email describing patch > ? - Re: RFR: Fix a bug <-- This is a general comment > ??? - Re: RFR: Fix a bug <-- This is a reply to the general comment > ? - Re: [Rev 01]: RFR: Fix a bug <-- The author updated the patch > ??? - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer A on 01 > ????? - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from A on 01 > ??? - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer B on 01 > ????? - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from B on 01 > ? - Re: [Rev 02]: RFR: Fix a bug <-- The author updated again > ? - Re: [Approved] RFR: Fix a bug <-- Reviewer A approved the patch > ? - Re: [Approved] RFR: Fix a bug <-- Reviewer B approved the patch > ? - Re: [Integrated] RFR: Fix a bug <-- Author integrated the patch > > We are tweaking this structure as we get more and more experience with > it, but at the moment I'm fairly satisfied with threading and the tree > layout. If you have any feedback on this structure/layout, then we are > happy to hear it. Well, I will of course look into this further. Thanks you for pointing me at the relevant matter to consider. > Going in the other direction, mailing list -> GitHub, we also try to > preserve the mailing list structure as much as possible. This is > actually a harder challenge, since an email is less structured compared > to a comment on GitHub. An example of this direction can be found in > pull request 231 for the Skara repository [3] where you can see the > thread (which is a tree) from skara-dev at openjdk.java.net [4] being > "flattened" and uses quotation to try to preserve the flow. Yes, of course. However, rather than express that as 'email is less structured' one might equally state it as 'email is much more flexible' or 'GitHub is much more rigid' ;-) > Here we are currently working on the /cc command that can be used in a > comment on pull request, for example: > > ??? /cc build-dev hotspot-dev Thanks for clarifying > I hope that is does not come across that we are taking mailing list > interopability as a minor detail? I think it is fair to say that this is > the Skara feature we have spent the most time working on and are > constantly improving in order to provide a good experience. No, I was not addressing that at you -- apologies if ti came across like that as I very much appreciate that you do take this seriously -- rather at all other OpenJDK project members to try to raise awareness of the importance of getting a change like this right. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From neugens.limasoftware at gmail.com Wed Nov 13 18:21:00 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 13 Nov 2019 19:21:00 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> Message-ID: Hi Kevin, First of all I want to apologise if what I'm about to say may sound harsh because it's definitely not my intention to undermine the validity of the project in itself, however I fear that this sort of experience may apply well for "smaller" projects with one or two maintainers doing the most of the merging work. The OpenJFX project has currently 39 contributors listed on GitHub and is quite healthy, but in the last month, according to GitHub (and if I read the stats correctly!), you had "only" 7 authors with 13 commits to master and an average of 5 to 7 reviews exchanges. This is a lot of work already, but is nowhere close to the volume and complexity of OpenJDK and of the update projects. Cheers, Mario Il giorno mer 13 nov 2019 alle ore 17:22 Kevin Rushforth ha scritto: > > I would like to add my experience with Skara. I lead the OpenJFX project > [1] along with Johan Vos. We are one of the early adopters of Skara, > having recently moved our official repo to GitHub as an early access > test of the Skara tooling and the transition to Git / GitHub. We've been > using it exclusively for over a month now, with positive results. > > Our experience with doing reviews on GitHub goes back even farther. > About a year prior to moving our official repo from hg.openjdk.java.net > to GitHub, we setup a mirror repo on GitHub that could be used as an > alternative to webrev for code reviews. What we found during the past > year is that most (but not all) contributors started using the GitHub > sandbox as their preferred mode for doing code reviews. We were able to > attract several new contributors who might not otherwise have felt they > were able to participate. The one downside we had during that year is > that we still had to export the commit from Git after the review was > finished and import it into a Mercurial changeset. With the official > repo being on GitHub, and the Skara tooling enabled, that extra step is > gone and we have a smooth workflow. > > I have found it easier, not harder, to exchange feedback on proposed > changes using GitHub -- I think it's much easier to comment on a block > of code inline rather than copying and pasting it from the webrev into > an email message. One of the nice things about the Skara tooling, > though, is that reviewers have their choice. Since review comments are > cross-forwarded between the mailing list and the PR, both modes are > supported. There are some wrinkles in the tooling, but the Skara team > has been very responsive in addressing them. > > To be sure, there is a bit of a learning curve moving to Git and moving > to a pull request model where each developer has a fork of the actual > repo, but I think that the benefits outweigh the drawbacks. > > -- Kevin > > [1] https://github.com/openjdk/jfx > > > On 11/13/2019 7:00 AM, Erik Helin wrote: > > On 11/13/19 3:15 PM, Thomas St?fe wrote: > >> Hi Erik, > > > > Hi Thomas, hope you are doing well! > > > >> First off thanks a lot to you and Joe for all your hard work. > > > > There are many more than me and Joe that have contributed to Skara :) > > In no particular order, a big thanks to: > > - Robin Westberg > > - Mark Reinhold > > - Erik Joelsson > > - Tony Squier > > - Kevin Rushforth > > - Jorn Vernee > > - Stanislav Smirnov > > - Christian Tornqvist > > - Dalibor Topic > > - Jeff Dinkins > > - Tim Bell > > - Marcus Hirt > > > >> After we last talked about this in February I think this project is > >> in good and unbiased hands. > >> > >> However, I share some of Andrews concerns. He voiced them more > >> elaborately than I could, so just some additional thoughts: > >> > >> When we introduce a new channel of discussion, we risk splitting the > >> community and damaging communication between us. We also risk > >> off-putting existing developers and lose productivity. The assumption > >> with this JEP is therefore that we gain more developers than we lose. > > > > No, the assumption is definitely *not* that we would lose developers. > > We will hopefully gain some contributors, but I don't intend to lose any. > > > >> These points should be clearly reflected under "Risk and > >> Assumptions". In my mind these are bigger points even than the risk > >> of locking in metadata with a proprietary provider. > >> > >> One smaller negative effect: mailing lists may receive less developer > >> attention. You lose those developers which moves away to GitHub. This > >> may lead to people not getting answers as promptly as before on > >> non-RFR matters. > > > > A contributor to OpenJDK will still be expected to follow and be > > active on the OpenJDK mailing lists, that does not change with Skara > > nor with a move to GitHub. For the Skara project iself, this is > > something we actively communicate on GitHub, see for example the Skara > > README [0] and Skara's contribution guidelines [1] (shown the first > > time a GitHub user submits a pull request targeting Skara). If needed > > we will communicate this even further by for example using pull > > request templates [2] (show every time a pull request is submitted). > > > > These communication techniques can of course also be utilized for > > other projects, e.g. the JDK project, if wanted. > > > >> The notion to keep both ways (mailing list + GitHub PRs) functional > >> and "first class citizens" is great. But I'm afraid that it may turn > >> out too brittle to keep up, and that the old side would rot away over > >> time. Which would cause a sliding effect - frustrated developers > >> switching away from mailing lists to GitHub, which would in turn > >> leave less developers on the mailing lists, which makes for even less > >> incentive to keep it working. > > > > There is no such thing as "switching away from mailing lists to > > GitHub". All activity on GitHub is mirrored on the OpenJDK mailing > > lists. And as I stated above, an active OpenJDK contributor is > > absolutely expected to follow and be active on the mailing lists. > > There is much more activity on the mailing lists besides "RFR" emails: > > - design discussion > > - call for votes > > - announcements > > - JEP discussion (such as this one) > > - occasional bug reports > > - etc. > > > >> Please do not understand this as me questioning your work - I am sure > >> as long as the tools have your attention they will work. But I would > >> feel better with a process which is less involved. One can say what > >> one wants about mailing lists, but they are low tech and resilient. > >> > >> So, this is also an assumption - that the tool chain keeps working > >> and that the effort spent maintaining it is less than the effort > >> spent today on maintaining the old infrastructure (which to be fair > >> is done by Oracle alone). > > > > Yes, the Skara tools need to keep on working, that is correct. That > > is, as you also state, of course true for all the infrastructure > > supporting OpenJDK. > > > > The Skara tooling has been written with ease of maintenance in mind. > > The tools are written in Java, the only dependencies are Gradle for > > building and JUnit for testing. We have plenty of unit tests and > > integration tests and the bots themselves are written in a polling and > > mostly stateless architecture. > > > > The Skara tooling is also open source [3] and we have already gotten > > some very nice community contributions (thanks!). > > > >> One other risk to mention would be that even if you are happy with > >> the way GitHub does represent PR discussions now, GitHub may change > >> the interface any time they like. With mailing lists, one is > >> independent of these interruptions. > > > > Again, you will not loose the mailing lists :) If you don't like the > > GitHub UI, then use one of the several third-party clients and/or > > interact via the mailing lists. We will likely discover some kinks > > with the bi-directional mailing list synchronization that we will have > > to work out, but so far things have been working very well (otherwise > > we wouldn't be submitting this JEP). > > > > Thanks, > > Erik > > > > [0]: https://git.openjdk.java.net/skara#discuss > > [1]: https://git.openjdk.java.net/skara/blob/master/CONTRIBUTING.md > > [2]: > > https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates > > [3]: https://git.openjdk.java.net/skara > > > >> ----------- > >> > >> Smaller technical nits: > >> > >> Changing the subject line of mails depending on the review iterations > >> does not play well with most email clients and with mailing list > >> archives, which thread mails by subject line. It tears discussions > >> apart. > >> > >> -- > >> > >> "Do not change the OpenJDK Bylaws. > >> Do not change the OpenJDK Census." > >> > >> Should be listed under Non-Goals? > >> > >> Thank you, > >> > >> Thomas > >> > >> > >> On Wed, Nov 13, 2019 at 12:42 PM Erik Helin >> > wrote: > >> > >> On 11/13/19 11:36 AM, Andrew Dinn wrote: > >> > On 12/11/2019 16:00, mark.reinhold at oracle.com > >> wrote: > >> >> https://openjdk.java.net/jeps/369 > >> > Firstly, thanks to Joe and Erik for producing a very > >> comprehensive JEP > >> > that addresses so many important questions. There are many > >> aspects of > >> > this proposed move that are very appealing. > >> > >> Thanks Andrew for reading through it all and providing feedback! > >> Please > >> see my replies inline. > >> > >> > However, I am afraid I am > >> > still going to start by expressing my severe reservations > >> about one > >> > proposed change: replacing email review with GitHub PRs (sorry > >> guys :-/). > >> > > >> > The JEP has this laudable goal: > >> > > >> > "Ensure that workflows structurally similar to the existing > >> e-mail and > >> > webrev based workflows are supported." > >> > > >> > and further qualifies that with: > >> > > >> > "Today, OpenJDK contributors collaborate via mailing lists, > >> they push > >> > changes to Mercurial repositories, they test changes via the > >> jdk/submit > >> > service, and they file bug reports via the JDK Bug System (JBS). > >> > Contributors can also make use of several command-line interface > >> (CLI) > >> > tools, primarily jcheck, webrev, and defpath. This is a > >> workflow that > >> > many experienced contributors enjoy and find productive. It's > >> therefore > >> > critical to preserve as much of this workflow as possible if we > >> move to > >> > an external provider." > >> > > >> > which one cannot really disagree with. > >> > > >> > The JEP then explains that: > >> > > >> > "Reviewers can now discuss the changes in the PR, using multiple > >> workflows: > >> > > >> > By replying to the RFR email sent to the mailing list(s), in > >> which > >> > case the contents of replies are copied into the PR on GitHub (no > >> GitHub > >> > account is required); > >> > . . . > >> > Any comment made in any of the workflows is reflected in all > >> of the > >> > workflows. One reviewer can add a comment via the mailing list, > >> another > >> > via the web browser, and a third via the command-line and they > >> will all > >> > see each others' comments." > >> > > >> > My experience of GitHub use in the Graal project suggest that > >> this is > >> > not entirely the full picture. My view derived from that > >> experience is > >> > that the GitHub PR is very much an inferior medium for review > >> > discussion. In particular, it definitely fails to be > >> "structurally > >> > similar to the existing e-mail and webrev based workflows". > >> > >> I think the key sentence here is "My experience of GitHub use in the > >> Graal project...". Having worked with project on GitHub using Skara > >> tooling and projects on GitHub _not_ using Skara tooling, my view is > >> that the experiences differs quite a bit. > >> > >> > Firstly, I'll note that email discussions consist of a tree of > >> dependent > >> > commentary. That commentary often contains quoted material which, > >> > especially when carefully edited (as it normally is), tracks > >> relevant > >> > context. The structuring that results from this use of the reply > >> > hierarchy and quoting permits a given discussion to split into a > >> group > >> > of related subordinate discussions where required while still > >> retaining > >> > a continued thread of relevance to a specific review. > >> Crucially, most > >> > email readers allow such branching discussions to be followed and > >> > extended in /parallel/. > >> > > >> > By contrast discussions in GitHub PRs are essentially linearized > >> (modulo > >> > a single level of nesting of commentary on top level comments). > >> Worse, > >> > the presentation forces all commentary to be flattened into a > >> single > >> > browser pane view. This linear mode of presentation results in a > >> severe > >> > hindrance to separation of, and attention to, separate concerns. > >> It also > >> > fails to preserve and display source relationships that > >> clarify the > >> > provenance and relevance of quoted text i.e. it not only fails to > >> record > >> > but actually obfuscates important context. > >> > >> This does not paint the whole picture. You are probably thinking > >> of the > >> "Conversation" tab in a GitHub pull request which is meant for > >> *general* > >> discussion of the patch that is not attached to any particular > >> change in > >> the patch. GitHub's own help documentation [0] states that the > >> "Conversation" tab is meant to be used for: > >> > >> You can comment on a pull request's Conversation tab to leave > >> general comments, questions, or props. > >> > >> You are right that comments in the "Conversation" tab are linearized > >> and > >> does not support a "tree style" view of comments. > >> > >> The good news are that the _other_ form of comments available on a > >> GitHub pull request, a so-called "review comment" or "file comment" > >> [1], > >> does support replies in the form of a tree. These comments are filed > >> under the "Files changed" tab in a pull request. > >> > >> Personally I think of the comments in the "Conversation" tab as > >> replies > >> to the "00" email in a classic patch series email and the "review > >> comments" in the "Files changed" tab as replies to the "0X" emails > >> actually containing patches. Do you follow? > >> > >> Now the interesting question is of course how the Skara tooling > >> translates these kinds of comments back-and-forth between mailing > >> lists > >> and GitHub. Here I'm happy to report that the Skara tooling does > >> proper > >> replying, which will cause the "review comments" created under the > >> "Files changed" tab on a pull request to result in a tree-view (in > >> email > >> clients that support such views). > >> > >> You can see of some of this work on the openjfx-dev mailing list > >> [2]. > >> Now keep in mind if you are looking at Pipermail rendering of a > >> mailing > >> list, which lacks some features that most email clients supports > >> (such > >> as folding quoted text and nested replies beyond three levels). A > >> mailing list version of a pull request will in general have the > >> following structure: > >> > >> - RFR: Fix a bug <-- Email describing patch > >> - Re: RFR: Fix a bug <-- This is a general comment > >> - Re: RFR: Fix a bug <-- This is a reply to the general > >> comment > >> - Re: [Rev 01]: RFR: Fix a bug <-- The author updated the patch > >> - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer A > >> on 01 > >> - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from > >> A on 01 > >> - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer B > >> on 01 > >> - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from > >> B on 01 > >> - Re: [Rev 02]: RFR: Fix a bug <-- The author updated again > >> - Re: [Approved] RFR: Fix a bug <-- Reviewer A approved the > >> patch > >> - Re: [Approved] RFR: Fix a bug <-- Reviewer B approved the > >> patch > >> - Re: [Integrated] RFR: Fix a bug <-- Author integrated the > >> patch > >> > >> We are tweaking this structure as we get more and more experience > >> with > >> it, but at the moment I'm fairly satisfied with threading and the > >> tree > >> layout. If you have any feedback on this structure/layout, then > >> we are > >> happy to hear it. > >> > >> Going in the other direction, mailing list -> GitHub, we also try to > >> preserve the mailing list structure as much as possible. This is > >> actually a harder challenge, since an email is less structured > >> compared > >> to a comment on GitHub. An example of this direction can be found in > >> pull request 231 for the Skara repository [3] where you can see the > >> thread (which is a tree) from skara-dev at openjdk.java.net > >> [4] being > >> "flattened" and uses quotation to try to preserve the flow. > >> > >> > Of course, discussions that remain in email may continue to > >> profit from > >> > the multi-focus aspect of the current workflow. However, I > >> believe that > >> > contributions to the discussion via a GitHub PR will inevitably > >> bypass > >> > and, therefore, invalidate any such structuring contributed > >> via the > >> > email workflow. Not only do I currently see that effect with > >> Graal PRs > >> > but I also see the damage it imposes on flow and quality of > >> discussion. > >> > > >> > Secondly, email reviews are conventionally directed to readers > >> with > >> > different domains of interest and expertise. That sometimes > >> requires > >> > re-routing a discussion to a different list from the one on which > >> it was > >> > first initiated. It also sometimes requires posting comments to > >> multiple > >> > lists, either when discussion is initiated or in mid-stream as > >> the scope > >> > of discussion develops. Managing distribution when using emails > >> lists is > >> > both easily achieved and well understood (n.b. that's not to > >> imply that > >> > deciding which list to send to is easy). > >> > >> Here we are currently working on the /cc command that can be used > >> in a > >> comment on pull request, for example: > >> > >> /cc build-dev hotspot-dev > >> > >> > The JEP suggests that discussions raised via PRs will be routed > >> to lists > >> > 1) derived from the affected files and/or 2) specified by whoever > >> raises > >> > the PR. It doesn't explain how (whether) target lists are to be > >> (may be) > >> > updated as review progresses. It also doesn't state clearly > >> whether > >> > whoever raises the PR or comments on it will have the ability to > >> > override those default choices (I fully expect that option > >> will be > >> > necessary in some cases). > >> > >> Agree, see the command above that we are working on :) > >> > >> > I need to stress that these concerns should not be considered as > >> minor > >> > details of how the project operates. Easy management of the > >> flow and > >> > direction of discussion is critical to being able to consume and > >> respond > >> > to commentary at the rate needed to keep up with a project as > >> large and > >> > rapidly changing as OpenJDK currently is. Given the central > >> importance > >> > of our review process to ensuring the health of the project > >> and its > >> > products I think it is right to be very concerned about the > >> potential > >> > for problems caused by this switch of medium. > >> > >> I hope that is does not come across that we are taking mailing list > >> interopability as a minor detail? I think it is fair to say that > >> this is > >> the Skara feature we have spent the most time working on and are > >> constantly improving in order to provide a good experience. > >> > >> Thanks, > >> Erik > >> > >> [0]: > >> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request > >> [1]: > >> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request > >> [2]: > >> https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-November/thread.html > >> [3]: https://git.openjdk.java.net/skara/pull/231 > >> [4]: > >> https://mail.openjdk.java.net/pipermail/skara-dev/2019-October/000998.html > >> > >> > regards, > >> > > >> > > >> > Andrew Dinn > >> > ----------- > >> > Senior Principal Software Engineer > >> > Red Hat UK Ltd > >> > Registered in England and Wales under Company Registration No. > >> 03798903 > >> > Directors: Michael Cunningham, Michael ("Mike") O'Neill > >> > > >> > > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From gnu.andrew at redhat.com Wed Nov 13 18:31:10 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 13 Nov 2019 18:31:10 +0000 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> Message-ID: On 13/11/2019 16:21, Kevin Rushforth wrote: snip... > > To be sure, there is a bit of a learning curve moving to Git and moving > to a pull request model where each developer has a fork of the actual > repo, but I think that the benefits outweigh the drawbacks. > > -- Kevin > Each developer has a fork of the actual repo as it stands now; this is the very nature of using a distributed version control system (DVCS). What differs with the pull request model is that fork is made public rather than patches being generated from it and posted. The advantage of that is that other developers can check out the published repository rather than attempting to recreate it by applying the patch to their own fork. The title of this JEP is misleading. It is not primarily about migrating to GitHub, but about moving OpenJDK to the push request model. While the GitHub tooling makes this *possible*, it does not make it *mandatory*. Skimming the discussion of JEP 357, "Migrate from Mercurial to Git", suggests that this would implicitly involve migration to GitHub as no other hosting provision is being suggested for the git repositories created by that JEP. Hence, I would suggest that this JEP be retitled and the transfer of repositories to GitHub be rehoused under JEP 357. Both changes - to using Git and to using a pull request model - necessitate significant alterations to an OpenJDK developer's working patterns. I would strongly suggest that the two are kept separate and time given to adapt to the first before trying to implement the latter. It is perfectly possible for someone to push their changes to a Git repository rather than a Mercurial repository without having to change the format of commit messages or the review process. JEP-369 mentions that there is a wide range of preferred work patterns for OpenJDK developers. I would also add that there is a wide range of experience as well. What I see from the discussion on this thread so far is relative contentment from those already using the push request model on smaller projects, and concerns from those with limited or no experience of it. The former have had the advantage of having time to experiment with this model before it becomes intrinsic to the entire project. I would suggest we try to do more of this rather than shift all JDK 11 and up projects in one go. Many of us are not involved in the projects that have experimented with this so far. A helpful next step would be to use this model for the next update project, 14u. There is then the opportunity for those on the JDK project to use it without being obligated to switch to it for everything immediately. I can see the clear desire to implement JEP-357 sooner rather than later. JEP-296 has created a situation where the current repositories are struggling, due to their size. This is true even in local transactions, without factoring in network isuses, and personally I'm relieved when my work involves 7u & 8u rather than than slower 11u+ repositories. I seem to recall that the issue of the individual jdk and hotspot repositories already showing strain was raised at the time of JEP-296, so we've seen this coming from some time. It worries me a little that an entire DVCS swap is being proposed without, apparently, any attempts to speed up Mercurial operations having being tried, but I guess switching to git is more of a known result, and there's also a general industry consensus around git that wasn't present when Mercurial was selected in 2007. I can't see the impetus for the push request model in the same way, and it seems the switch to GitHub is being used to cloud the necessity of such a move. As I said above, it would be much preferable to implement git on GitHub using the existing processes and then consider such a switch once everyone is settled, rather than attempting to combine the two migrations. TL;DR: switch to Git & GitHub now, but reserve this JEP for consideration of a push request model once that switch is fully complete. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From kevin.rushforth at oracle.com Wed Nov 13 18:34:50 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 13 Nov 2019 10:34:50 -0800 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> Message-ID: Hi Mario. You raise a very valid point in wondering how the Skara tooling and GitHub workflow will scale from a smaller project like OpenJFX (or Skara) to a larger project like the JDK or JDK Updates project. There are two aspects of the scaling that will need to be considered. First the higher volume may lead to some additional challenges in its own right. Second, the jdk is made up of many sub-projects each with their own mailing list, so the tooling will need to manage different reviews which are targeted for different mailing lists (plural in some cases where a single PR affects more than one sub-project). I think the Skara team has a good plan for addressing them. I would point out that many of the concerns raised have been around the migration to Git and the GitHub review process itself, where I do think the experiences of smaller projects like OpenJFK or Skara itself is relevant. -- Kevin On 11/13/2019 10:21 AM, Mario Torre wrote: > Hi Kevin, > > First of all I want to apologise if what I'm about to say may sound > harsh because it's definitely not my intention to undermine the > validity of the project in itself, however I fear that this sort of > experience may apply well for "smaller" projects with one or two > maintainers doing the most of the merging work. > > The OpenJFX project has currently 39 contributors listed on GitHub and > is quite healthy, but in the last month, according to GitHub (and if I > read the stats correctly!), you had "only" 7 authors with 13 commits > to master and an average of 5 to 7 reviews exchanges. This is a lot of > work already, but is nowhere close to the volume and complexity of > OpenJDK and of the update projects. > > Cheers, > Mario > > Il giorno mer 13 nov 2019 alle ore 17:22 Kevin Rushforth > ha scritto: >> I would like to add my experience with Skara. I lead the OpenJFX project >> [1] along with Johan Vos. We are one of the early adopters of Skara, >> having recently moved our official repo to GitHub as an early access >> test of the Skara tooling and the transition to Git / GitHub. We've been >> using it exclusively for over a month now, with positive results. >> >> Our experience with doing reviews on GitHub goes back even farther. >> About a year prior to moving our official repo from hg.openjdk.java.net >> to GitHub, we setup a mirror repo on GitHub that could be used as an >> alternative to webrev for code reviews. What we found during the past >> year is that most (but not all) contributors started using the GitHub >> sandbox as their preferred mode for doing code reviews. We were able to >> attract several new contributors who might not otherwise have felt they >> were able to participate. The one downside we had during that year is >> that we still had to export the commit from Git after the review was >> finished and import it into a Mercurial changeset. With the official >> repo being on GitHub, and the Skara tooling enabled, that extra step is >> gone and we have a smooth workflow. >> >> I have found it easier, not harder, to exchange feedback on proposed >> changes using GitHub -- I think it's much easier to comment on a block >> of code inline rather than copying and pasting it from the webrev into >> an email message. One of the nice things about the Skara tooling, >> though, is that reviewers have their choice. Since review comments are >> cross-forwarded between the mailing list and the PR, both modes are >> supported. There are some wrinkles in the tooling, but the Skara team >> has been very responsive in addressing them. >> >> To be sure, there is a bit of a learning curve moving to Git and moving >> to a pull request model where each developer has a fork of the actual >> repo, but I think that the benefits outweigh the drawbacks. >> >> -- Kevin >> >> [1] https://github.com/openjdk/jfx >> >> >> On 11/13/2019 7:00 AM, Erik Helin wrote: >>> On 11/13/19 3:15 PM, Thomas St?fe wrote: >>>> Hi Erik, >>> Hi Thomas, hope you are doing well! >>> >>>> First off thanks a lot to you and Joe for all your hard work. >>> There are many more than me and Joe that have contributed to Skara :) >>> In no particular order, a big thanks to: >>> - Robin Westberg >>> - Mark Reinhold >>> - Erik Joelsson >>> - Tony Squier >>> - Kevin Rushforth >>> - Jorn Vernee >>> - Stanislav Smirnov >>> - Christian Tornqvist >>> - Dalibor Topic >>> - Jeff Dinkins >>> - Tim Bell >>> - Marcus Hirt >>> >>>> After we last talked about this in February I think this project is >>>> in good and unbiased hands. >>>> >>>> However, I share some of Andrews concerns. He voiced them more >>>> elaborately than I could, so just some additional thoughts: >>>> >>>> When we introduce a new channel of discussion, we risk splitting the >>>> community and damaging communication between us. We also risk >>>> off-putting existing developers and lose productivity. The assumption >>>> with this JEP is therefore that we gain more developers than we lose. >>> No, the assumption is definitely *not* that we would lose developers. >>> We will hopefully gain some contributors, but I don't intend to lose any. >>> >>>> These points should be clearly reflected under "Risk and >>>> Assumptions". In my mind these are bigger points even than the risk >>>> of locking in metadata with a proprietary provider. >>>> >>>> One smaller negative effect: mailing lists may receive less developer >>>> attention. You lose those developers which moves away to GitHub. This >>>> may lead to people not getting answers as promptly as before on >>>> non-RFR matters. >>> A contributor to OpenJDK will still be expected to follow and be >>> active on the OpenJDK mailing lists, that does not change with Skara >>> nor with a move to GitHub. For the Skara project iself, this is >>> something we actively communicate on GitHub, see for example the Skara >>> README [0] and Skara's contribution guidelines [1] (shown the first >>> time a GitHub user submits a pull request targeting Skara). If needed >>> we will communicate this even further by for example using pull >>> request templates [2] (show every time a pull request is submitted). >>> >>> These communication techniques can of course also be utilized for >>> other projects, e.g. the JDK project, if wanted. >>> >>>> The notion to keep both ways (mailing list + GitHub PRs) functional >>>> and "first class citizens" is great. But I'm afraid that it may turn >>>> out too brittle to keep up, and that the old side would rot away over >>>> time. Which would cause a sliding effect - frustrated developers >>>> switching away from mailing lists to GitHub, which would in turn >>>> leave less developers on the mailing lists, which makes for even less >>>> incentive to keep it working. >>> There is no such thing as "switching away from mailing lists to >>> GitHub". All activity on GitHub is mirrored on the OpenJDK mailing >>> lists. And as I stated above, an active OpenJDK contributor is >>> absolutely expected to follow and be active on the mailing lists. >>> There is much more activity on the mailing lists besides "RFR" emails: >>> - design discussion >>> - call for votes >>> - announcements >>> - JEP discussion (such as this one) >>> - occasional bug reports >>> - etc. >>> >>>> Please do not understand this as me questioning your work - I am sure >>>> as long as the tools have your attention they will work. But I would >>>> feel better with a process which is less involved. One can say what >>>> one wants about mailing lists, but they are low tech and resilient. >>>> >>>> So, this is also an assumption - that the tool chain keeps working >>>> and that the effort spent maintaining it is less than the effort >>>> spent today on maintaining the old infrastructure (which to be fair >>>> is done by Oracle alone). >>> Yes, the Skara tools need to keep on working, that is correct. That >>> is, as you also state, of course true for all the infrastructure >>> supporting OpenJDK. >>> >>> The Skara tooling has been written with ease of maintenance in mind. >>> The tools are written in Java, the only dependencies are Gradle for >>> building and JUnit for testing. We have plenty of unit tests and >>> integration tests and the bots themselves are written in a polling and >>> mostly stateless architecture. >>> >>> The Skara tooling is also open source [3] and we have already gotten >>> some very nice community contributions (thanks!). >>> >>>> One other risk to mention would be that even if you are happy with >>>> the way GitHub does represent PR discussions now, GitHub may change >>>> the interface any time they like. With mailing lists, one is >>>> independent of these interruptions. >>> Again, you will not loose the mailing lists :) If you don't like the >>> GitHub UI, then use one of the several third-party clients and/or >>> interact via the mailing lists. We will likely discover some kinks >>> with the bi-directional mailing list synchronization that we will have >>> to work out, but so far things have been working very well (otherwise >>> we wouldn't be submitting this JEP). >>> >>> Thanks, >>> Erik >>> >>> [0]: https://git.openjdk.java.net/skara#discuss >>> [1]: https://git.openjdk.java.net/skara/blob/master/CONTRIBUTING.md >>> [2]: >>> https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates >>> [3]: https://git.openjdk.java.net/skara >>> >>>> ----------- >>>> >>>> Smaller technical nits: >>>> >>>> Changing the subject line of mails depending on the review iterations >>>> does not play well with most email clients and with mailing list >>>> archives, which thread mails by subject line. It tears discussions >>>> apart. >>>> >>>> -- >>>> >>>> "Do not change the OpenJDK Bylaws. >>>> Do not change the OpenJDK Census." >>>> >>>> Should be listed under Non-Goals? >>>> >>>> Thank you, >>>> >>>> Thomas >>>> >>>> >>>> On Wed, Nov 13, 2019 at 12:42 PM Erik Helin >>> > wrote: >>>> >>>> On 11/13/19 11:36 AM, Andrew Dinn wrote: >>>> > On 12/11/2019 16:00, mark.reinhold at oracle.com >>>> wrote: >>>> >> https://openjdk.java.net/jeps/369 >>>> > Firstly, thanks to Joe and Erik for producing a very >>>> comprehensive JEP >>>> > that addresses so many important questions. There are many >>>> aspects of >>>> > this proposed move that are very appealing. >>>> >>>> Thanks Andrew for reading through it all and providing feedback! >>>> Please >>>> see my replies inline. >>>> >>>> > However, I am afraid I am >>>> > still going to start by expressing my severe reservations >>>> about one >>>> > proposed change: replacing email review with GitHub PRs (sorry >>>> guys :-/). >>>> > >>>> > The JEP has this laudable goal: >>>> > >>>> > "Ensure that workflows structurally similar to the existing >>>> e-mail and >>>> > webrev based workflows are supported." >>>> > >>>> > and further qualifies that with: >>>> > >>>> > "Today, OpenJDK contributors collaborate via mailing lists, >>>> they push >>>> > changes to Mercurial repositories, they test changes via the >>>> jdk/submit >>>> > service, and they file bug reports via the JDK Bug System (JBS). >>>> > Contributors can also make use of several command-line interface >>>> (CLI) >>>> > tools, primarily jcheck, webrev, and defpath. This is a >>>> workflow that >>>> > many experienced contributors enjoy and find productive. It's >>>> therefore >>>> > critical to preserve as much of this workflow as possible if we >>>> move to >>>> > an external provider." >>>> > >>>> > which one cannot really disagree with. >>>> > >>>> > The JEP then explains that: >>>> > >>>> > "Reviewers can now discuss the changes in the PR, using multiple >>>> workflows: >>>> > >>>> > By replying to the RFR email sent to the mailing list(s), in >>>> which >>>> > case the contents of replies are copied into the PR on GitHub (no >>>> GitHub >>>> > account is required); >>>> > . . . >>>> > Any comment made in any of the workflows is reflected in all >>>> of the >>>> > workflows. One reviewer can add a comment via the mailing list, >>>> another >>>> > via the web browser, and a third via the command-line and they >>>> will all >>>> > see each others' comments." >>>> > >>>> > My experience of GitHub use in the Graal project suggest that >>>> this is >>>> > not entirely the full picture. My view derived from that >>>> experience is >>>> > that the GitHub PR is very much an inferior medium for review >>>> > discussion. In particular, it definitely fails to be >>>> "structurally >>>> > similar to the existing e-mail and webrev based workflows". >>>> >>>> I think the key sentence here is "My experience of GitHub use in the >>>> Graal project...". Having worked with project on GitHub using Skara >>>> tooling and projects on GitHub _not_ using Skara tooling, my view is >>>> that the experiences differs quite a bit. >>>> >>>> > Firstly, I'll note that email discussions consist of a tree of >>>> dependent >>>> > commentary. That commentary often contains quoted material which, >>>> > especially when carefully edited (as it normally is), tracks >>>> relevant >>>> > context. The structuring that results from this use of the reply >>>> > hierarchy and quoting permits a given discussion to split into a >>>> group >>>> > of related subordinate discussions where required while still >>>> retaining >>>> > a continued thread of relevance to a specific review. >>>> Crucially, most >>>> > email readers allow such branching discussions to be followed and >>>> > extended in /parallel/. >>>> > >>>> > By contrast discussions in GitHub PRs are essentially linearized >>>> (modulo >>>> > a single level of nesting of commentary on top level comments). >>>> Worse, >>>> > the presentation forces all commentary to be flattened into a >>>> single >>>> > browser pane view. This linear mode of presentation results in a >>>> severe >>>> > hindrance to separation of, and attention to, separate concerns. >>>> It also >>>> > fails to preserve and display source relationships that >>>> clarify the >>>> > provenance and relevance of quoted text i.e. it not only fails to >>>> record >>>> > but actually obfuscates important context. >>>> >>>> This does not paint the whole picture. You are probably thinking >>>> of the >>>> "Conversation" tab in a GitHub pull request which is meant for >>>> *general* >>>> discussion of the patch that is not attached to any particular >>>> change in >>>> the patch. GitHub's own help documentation [0] states that the >>>> "Conversation" tab is meant to be used for: >>>> >>>> You can comment on a pull request's Conversation tab to leave >>>> general comments, questions, or props. >>>> >>>> You are right that comments in the "Conversation" tab are linearized >>>> and >>>> does not support a "tree style" view of comments. >>>> >>>> The good news are that the _other_ form of comments available on a >>>> GitHub pull request, a so-called "review comment" or "file comment" >>>> [1], >>>> does support replies in the form of a tree. These comments are filed >>>> under the "Files changed" tab in a pull request. >>>> >>>> Personally I think of the comments in the "Conversation" tab as >>>> replies >>>> to the "00" email in a classic patch series email and the "review >>>> comments" in the "Files changed" tab as replies to the "0X" emails >>>> actually containing patches. Do you follow? >>>> >>>> Now the interesting question is of course how the Skara tooling >>>> translates these kinds of comments back-and-forth between mailing >>>> lists >>>> and GitHub. Here I'm happy to report that the Skara tooling does >>>> proper >>>> replying, which will cause the "review comments" created under the >>>> "Files changed" tab on a pull request to result in a tree-view (in >>>> email >>>> clients that support such views). >>>> >>>> You can see of some of this work on the openjfx-dev mailing list >>>> [2]. >>>> Now keep in mind if you are looking at Pipermail rendering of a >>>> mailing >>>> list, which lacks some features that most email clients supports >>>> (such >>>> as folding quoted text and nested replies beyond three levels). A >>>> mailing list version of a pull request will in general have the >>>> following structure: >>>> >>>> - RFR: Fix a bug <-- Email describing patch >>>> - Re: RFR: Fix a bug <-- This is a general comment >>>> - Re: RFR: Fix a bug <-- This is a reply to the general >>>> comment >>>> - Re: [Rev 01]: RFR: Fix a bug <-- The author updated the patch >>>> - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer A >>>> on 01 >>>> - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from >>>> A on 01 >>>> - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer B >>>> on 01 >>>> - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from >>>> B on 01 >>>> - Re: [Rev 02]: RFR: Fix a bug <-- The author updated again >>>> - Re: [Approved] RFR: Fix a bug <-- Reviewer A approved the >>>> patch >>>> - Re: [Approved] RFR: Fix a bug <-- Reviewer B approved the >>>> patch >>>> - Re: [Integrated] RFR: Fix a bug <-- Author integrated the >>>> patch >>>> >>>> We are tweaking this structure as we get more and more experience >>>> with >>>> it, but at the moment I'm fairly satisfied with threading and the >>>> tree >>>> layout. If you have any feedback on this structure/layout, then >>>> we are >>>> happy to hear it. >>>> >>>> Going in the other direction, mailing list -> GitHub, we also try to >>>> preserve the mailing list structure as much as possible. This is >>>> actually a harder challenge, since an email is less structured >>>> compared >>>> to a comment on GitHub. An example of this direction can be found in >>>> pull request 231 for the Skara repository [3] where you can see the >>>> thread (which is a tree) from skara-dev at openjdk.java.net >>>> [4] being >>>> "flattened" and uses quotation to try to preserve the flow. >>>> >>>> > Of course, discussions that remain in email may continue to >>>> profit from >>>> > the multi-focus aspect of the current workflow. However, I >>>> believe that >>>> > contributions to the discussion via a GitHub PR will inevitably >>>> bypass >>>> > and, therefore, invalidate any such structuring contributed >>>> via the >>>> > email workflow. Not only do I currently see that effect with >>>> Graal PRs >>>> > but I also see the damage it imposes on flow and quality of >>>> discussion. >>>> > >>>> > Secondly, email reviews are conventionally directed to readers >>>> with >>>> > different domains of interest and expertise. That sometimes >>>> requires >>>> > re-routing a discussion to a different list from the one on which >>>> it was >>>> > first initiated. It also sometimes requires posting comments to >>>> multiple >>>> > lists, either when discussion is initiated or in mid-stream as >>>> the scope >>>> > of discussion develops. Managing distribution when using emails >>>> lists is >>>> > both easily achieved and well understood (n.b. that's not to >>>> imply that >>>> > deciding which list to send to is easy). >>>> >>>> Here we are currently working on the /cc command that can be used >>>> in a >>>> comment on pull request, for example: >>>> >>>> /cc build-dev hotspot-dev >>>> >>>> > The JEP suggests that discussions raised via PRs will be routed >>>> to lists >>>> > 1) derived from the affected files and/or 2) specified by whoever >>>> raises >>>> > the PR. It doesn't explain how (whether) target lists are to be >>>> (may be) >>>> > updated as review progresses. It also doesn't state clearly >>>> whether >>>> > whoever raises the PR or comments on it will have the ability to >>>> > override those default choices (I fully expect that option >>>> will be >>>> > necessary in some cases). >>>> >>>> Agree, see the command above that we are working on :) >>>> >>>> > I need to stress that these concerns should not be considered as >>>> minor >>>> > details of how the project operates. Easy management of the >>>> flow and >>>> > direction of discussion is critical to being able to consume and >>>> respond >>>> > to commentary at the rate needed to keep up with a project as >>>> large and >>>> > rapidly changing as OpenJDK currently is. Given the central >>>> importance >>>> > of our review process to ensuring the health of the project >>>> and its >>>> > products I think it is right to be very concerned about the >>>> potential >>>> > for problems caused by this switch of medium. >>>> >>>> I hope that is does not come across that we are taking mailing list >>>> interopability as a minor detail? I think it is fair to say that >>>> this is >>>> the Skara feature we have spent the most time working on and are >>>> constantly improving in order to provide a good experience. >>>> >>>> Thanks, >>>> Erik >>>> >>>> [0]: >>>> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request >>>> [1]: >>>> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request >>>> [2]: >>>> https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-November/thread.html >>>> [3]: https://git.openjdk.java.net/skara/pull/231 >>>> [4]: >>>> https://mail.openjdk.java.net/pipermail/skara-dev/2019-October/000998.html >>>> >>>> > regards, >>>> > >>>> > >>>> > Andrew Dinn >>>> > ----------- >>>> > Senior Principal Software Engineer >>>> > Red Hat UK Ltd >>>> > Registered in England and Wales under Company Registration No. >>>> 03798903 >>>> > Directors: Michael Cunningham, Michael ("Mike") O'Neill >>>> > >>>> > From joe.darcy at oracle.com Thu Nov 14 07:20:47 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 13 Nov 2019 23:20:47 -0800 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: <091222d1-ccf1-217c-0ede-01aad5218d28@oracle.com> Hello, Thanks all for the thoughtful responses thus far. On 11/13/2019 5:24 AM, Mario Torre wrote: > Il giorno mer 13 nov 2019 alle ore 12:42 Erik Helin > ha scritto: > >> This does not paint the whole picture. You are probably thinking of the >> "Conversation" tab in a GitHub pull request which is meant for *general* >> discussion of the patch that is not attached to any particular change in >> the patch. GitHub's own help documentation [0] states that the >> "Conversation" tab is meant to be used for: >> >> You can comment on a pull request's Conversation tab to leave >> general comments, questions, or props. >> >> You are right that comments in the "Conversation" tab are linearized and >> does not support a "tree style" view of comments. >> >> The good news are that the _other_ form of comments available on a >> GitHub pull request, a so-called "review comment" or "file comment" [1], >> does support replies in the form of a tree. These comments are filed >> under the "Files changed" tab in a pull request. >> >> Personally I think of the comments in the "Conversation" tab as replies >> to the "00" email in a classic patch series email and the "review >> comments" in the "Files changed" tab as replies to the "0X" emails >> actually containing patches. Do you follow? > Hi Erik, > > Your reply to me highlight the most important issue of all, we will > have to re-learn all the workflow, adjust to new tools (which are not > inherently integrated in Git but will have to be somehow configured > and used) and get used to GitHub before we can be good citizens again. It is certainly true that changing the JDK's SCM from Mercurial to Git would be at least a transitory hassle. Despite its technical merits and ease of use, Mercurial's usage is plummeting, as further evidenced by losing support from BitBucket in the near future [1]. I don't think using an increasing niche technology for a cornerstone of OpenJDK infrastructure is a prudent long-term choice in terms of keeping Java vibrant. The Skara project has used a diligent and careful approach to revisiting the JDK's SCM usage. Live mirrors of active Mercurial repos have been available for many months, not just jdk/jdk and the update releases but also amber, loom, shenandoah, tsan, etc. [2] Interested parties can today clone those repos and start becoming familiar with Git tooling; see the Skara wiki for details on getting started. [3] The Skara project has also verified various boundary systems can work using the Git mirrors; inside Oracle for over a year we've run a CI job against the Git mirrors alongside the CI jobs run against the Mercurial masters. JBS integration is in progress. These intermediate states purposefully allow exploration of using Git as an SCM and avoid concentrating all potential migration activities into only a narrow time window. As previously stated at OCW, the Skara team is willing to host a "Git for JDK Developers" talk to help ease a transition to the different SCM. The OpenJFX project's workflows are broadly similar to those of the JDK. As Kevin Rushforth has shared elsewhere on this thread, OpenJFX has successfully moved to having their master repo on GitHub using Skara tooling. There is no project larger than OpenJFX with a history of similar workflows that can be migrated to Skara other than the JDK mainline or update releases. While the JDK workflows are familiar and comfortable to many of us, IMO some of the details of those workflows stem from the particular tooling available for use by OpenJDK circa 2006 and 2007. For example, mailing lists were available while an externally usable bug tracker was not (for some time), so many discussions that might otherwise be centered on the bug tracker have historically occurred on OpenJDK mailing lists instead. In contrast, the CSR (Compatibility & Specification Review) group [4] was created after JBS was available and CSR reviews primarily occur within the facilities of the bug system rather than primarily on a dedicated mailing list. It would be possible to conduct CSR review on a mailing list, but I don't think it would be beneficial to do so. A rephrasing and expansion of the listed goal ??? "Ensure that workflows structurally similar to the existing e-mail and webrev based workflows are supported." is ??? "Provide conceptual continuity between existing workflows and new ones on different tooling." I would expected continued usage of mailing lists and webrevs to occur alongside native usage of new capabilities of a hosted Git provider. As one small example, there are certain kinds of review actions "Make *this* edit right *here*" that are considerably streamlined with GitHub tooling compared to the current mailing list centered interactions. The possibility for improvements should be considered together with the possibilities of regressions. I fully expect the Skara tooling to continue evolving and improving as well as its user base grows. Cheers, -Joe [1] https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket [2] http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-2019-08-skara.pdf [3] https://wiki.openjdk.java.net/display/SKARA [4] https://wiki.openjdk.java.net/display/csr/Main From erik.helin at oracle.com Thu Nov 14 11:34:48 2019 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 14 Nov 2019 12:34:48 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <6243b540-60fc-8a3b-7c69-1ff4b18742be@redhat.com> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <6243b540-60fc-8a3b-7c69-1ff4b18742be@redhat.com> Message-ID: On 11/13/19 6:39 PM, Andrew Dinn wrote: > On 13/11/2019 11:42, Erik Helin wrote: >> Thanks Andrew for reading through it all and providing feedback! Please >> see my replies inline. > > You are very welcome. It definitely merits a considered and fair review. > >>> My experience of GitHub use in the Graal project suggest that this is >>> not entirely the full picture. My view derived from that experience is >>> that the GitHub PR is very much an inferior medium for review >>> discussion. In particular, it definitely fails to be "structurally >>> similar to the existing e-mail and webrev based workflows". >> >> I think the key sentence here is "My experience of GitHub use in the >> Graal project...". Having worked with project on GitHub using Skara >> tooling and projects on GitHub _not_ using Skara tooling, my view is >> that the experiences differs quite a bit. > > I am happy to hear that you will be supplementing the standard GitHub > experience with extra tooling. I also must apologize for not looking at > Skara before writing a critique that perhaps does not do it justice. I > will take a look and post my thoughts. > >> This does not paint the whole picture. You are probably thinking of the >> "Conversation" tab in a GitHub pull request which is meant for *general* >> discussion of the patch that is not attached to any particular change in >> the patch. GitHub's own help documentation [0] states that the >> "Conversation" tab is meant to be used for: >> >> ??? You can comment on a pull request's Conversation tab to leave >> ??? general comments, questions, or props. >> >> You are right that comments in the "Conversation" tab are linearized and >> does not support a "tree style" view of comments. >> >> The good news are that the _other_ form of comments available on a >> GitHub pull request, a so-called "review comment" or "file comment" [1], >> does support replies in the form of a tree. These comments are filed >> under the "Files changed" tab in a pull request. > > I'm afraid that makes it sound worse not better. This bifurcates the > review process into 'general comments' vs 'critique on the code per se', > with the former forced into a linear frame while the latter can benefit > from divide and conquer distinctions. I fear that's an artificial > division of concerns that will make it harder still to reconcile general > points with the evidence base for deriving them. > >> Personally I think of the comments in the "Conversation" tab as replies >> to the "00" email in a classic patch series email and the "review >> comments" in the "Files changed" tab as replies to the "0X" emails >> actually containing patches. Do you follow? > > Well, I agree that sometimes that will work ok. However, I may be wrong > here but I believe that the code comments are tied to a specific point > in the file/change set. That's ok when a comment only relates to one > change. When you wish comment on the combined effect of two or more > changes at different points in the file the requirement to attach a > comment to one specific change doesn't really work. Punting such > comments to the 00 thread doesn't do it either. Quoting the relevant > lines in a follow-up note does bring the relevant changes into the scope > of preceding and subsequent replies. > > The root point here is that the GitHub PR presentation model is going to > impose constraints on the way we structure and link our review comments > because it needs them to conform to it's information structure that is > essentially driven by it's web page layout. email is inherently much > more flexible because it is just a hierarchically linked set of texts. > Of course, GitHub provides aids to simplify the task of creating and > linking information in its format. Whereas with email one has to > explicitly structure the information by editing it and placing it in a > reply sequence. I can see GitHub making some things a lot easier. > However, my concern is that it may well make some important things that > we do difficult or maybe even impossible (at the least impractical). Yes, email is more free form (and thus more flexible) than essentially any other medium. The interesting question to ponder here is if this flexibility helps or hurts the majority of reviews being conducted in OpenJDK on a daily basis? I think we all have experienced where the flexibility of mailing lists and free-form emails have resulted in less than stellar experiences as well: - a thread gets forked to two different mailing lists because one participant forgets to press "Reply all" and instead presses "Reply List" - a reviewer joins a "RFR" thread after the patch has been pushed since there is no way see on a mailing list whether the patch has been pushed or not - a contributor forgets to mentions one more important facts in a RFR email such as links to JBS issue(s), which commit the patch should be applied upon or does not supply an incremental webrev Looking at the jdk/jdk repository [0] we see that over 95% of all commits have 3 or less reviewers [1]. Manually skimming the last weeks of emails on core-libs-dev and hotspot-dev seems (to me) to confirm this: the majority of the conversations have 1 - 4 participants (one author and up to three reviewers). Looking at the conversations it also seems (again, to me) that a majority of them take place on a singe list and do not move/transfer to other mailing lists. With the above in mind I do believe that flexibility and expressiveness of pull requests combined with Skara's mailing list interoperability is powerful enough. The experience from OpenJFX transitioning to GitHub + Skara seem to confirm this, but this of course my interpretation based on their feedback. Now, as I have pointed in some other replies, we do *not* lose the mailing lists just because we migrate to GitHub + Skara. If you have a really large patch where you are expecting 5+ reviewers spanning 3+ mailing lists, then it is more than fine to send an RFC email with a webrev, just like we do today. The patch will eventually have to become one more pull requests and subject to the review process, but there is nothing stopping you from using the mailing lists for the initial feedback. >> Now the interesting question is of course how the Skara tooling >> translates these kinds of comments back-and-forth between mailing lists >> and GitHub. Here I'm happy to report that the Skara tooling does proper >> replying, which will cause the "review comments" created under the >> "Files changed" tab on a pull request to result in a tree-view (in email >> clients that support such views). >> >> You can see of some of this work on the openjfx-dev mailing list [2]. >> Now keep in mind if you are looking at Pipermail rendering of a mailing >> list, which lacks some features that most email clients supports (such >> as folding quoted text and nested replies beyond three levels). A >> mailing list version of a pull request will in general have the >> following structure: >> >> - RFR: Fix a bug <-- Email describing patch >> ? - Re: RFR: Fix a bug <-- This is a general comment >> ??? - Re: RFR: Fix a bug <-- This is a reply to the general comment >> ? - Re: [Rev 01]: RFR: Fix a bug <-- The author updated the patch >> ??? - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer A on 01 >> ????? - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from A on 01 >> ??? - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer B on 01 >> ????? - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from B on 01 >> ? - Re: [Rev 02]: RFR: Fix a bug <-- The author updated again >> ? - Re: [Approved] RFR: Fix a bug <-- Reviewer A approved the patch >> ? - Re: [Approved] RFR: Fix a bug <-- Reviewer B approved the patch >> ? - Re: [Integrated] RFR: Fix a bug <-- Author integrated the patch >> >> We are tweaking this structure as we get more and more experience with >> it, but at the moment I'm fairly satisfied with threading and the tree >> layout. If you have any feedback on this structure/layout, then we are >> happy to hear it. > > Well, I will of course look into this further. Thanks you for pointing > me at the relevant matter to consider. Thanks for digging into this, we are longing for feedback :) >> Going in the other direction, mailing list -> GitHub, we also try to >> preserve the mailing list structure as much as possible. This is >> actually a harder challenge, since an email is less structured compared >> to a comment on GitHub. An example of this direction can be found in >> pull request 231 for the Skara repository [3] where you can see the >> thread (which is a tree) from skara-dev at openjdk.java.net [4] being >> "flattened" and uses quotation to try to preserve the flow. > > Yes, of course. However, rather than express that as 'email is less > structured' one might equally state it as 'email is much more flexible' > or 'GitHub is much more rigid' ;-) :) Please see my reply above for my thoughts on this matter. >> Here we are currently working on the /cc command that can be used in a >> comment on pull request, for example: >> >> ??? /cc build-dev hotspot-dev > > Thanks for clarifying No problem at all. >> I hope that is does not come across that we are taking mailing list >> interopability as a minor detail? I think it is fair to say that this is >> the Skara feature we have spent the most time working on and are >> constantly improving in order to provide a good experience. > > No, I was not addressing that at you -- apologies if ti came across like > that as I very much appreciate that you do take this seriously -- rather > at all other OpenJDK project members to try to raise awareness of the > importance of getting a change like this right. No feelings hurt, I just wanted to stress how deeply we care about this matter. And for the record, yes, I'm well aware of the importance of getting this change right. I have worked in this community for more than 7 years now and have a deep respect for it and its members. Thanks, Erik [0]: https://git.openjdk.java.net/jdk [1]: https://gist.github.com/edvbld/a03dec6c84bad054d7529461a38efdf5 > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From erik.helin at oracle.com Thu Nov 14 14:42:12 2019 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 14 Nov 2019 15:42:12 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> Message-ID: On 11/13/19 7:31 PM, Andrew John Hughes wrote: > > > On 13/11/2019 16:21, Kevin Rushforth wrote: > > snip... > >> >> To be sure, there is a bit of a learning curve moving to Git and moving >> to a pull request model where each developer has a fork of the actual >> repo, but I think that the benefits outweigh the drawbacks. >> >> -- Kevin >> > > Each developer has a fork of the actual repo as it stands now; this is > the very nature of using a distributed version control system (DVCS). > What differs with the pull request model is that fork is made public > rather than patches being generated from it and posted. The advantage of > that is that other developers can check out the published repository > rather than attempting to recreate it by applying the patch to their own > fork. > > The title of this JEP is misleading. It is not primarily about migrating > to GitHub, but about moving OpenJDK to the push request model.While the > GitHub tooling makes this *possible*, it does not make it *mandatory*. > Skimming the discussion of JEP 357, "Migrate from Mercurial to Git", > suggests that this would implicitly involve migration to GitHub as no > other hosting provision is being suggested for the git repositories > created by that JEP. Hence, I would suggest that this JEP be retitled > and the transfer of repositories to GitHub be rehoused under JEP 357. > > Both changes - to using Git and to using a pull request model - > necessitate significant alterations to an OpenJDK developer's working > patterns. I would strongly suggest that the two are kept separate and > time given to adapt to the first before trying to implement the latter. > It is perfectly possible for someone to push their changes to a Git > repository rather than a Mercurial repository without having to change > the format of commit messages or the review process. You are missing one very important aspect here: no external source code hosting sites that I know of (and that would be applicable for OpenJDK) allows users to execute "pre-receive" hooks (also known as "pre-push" hooks). Most of the things happening on our current Mercurial servers are *post* push actions such as sending an email to a mailing list and/or forwarding a commit to another repository. These are events that occur _after_ the pushed change has been committed to the repository on the server. There is however one very important piece of code that runs _before_ the change is committed to the repository on the server: jcheck. Running a piece of code before a change is committed on a remote repository is known as executing a "pre-receive" or "pre-push" hook. There is no way to allow direct pushes to a github.com (nor gitlab.com, bitbucket.com) repository and ensure that every commit being pushed passes jcheck. The good news are that using pull requests (which are similar to "RFR" emails, as you have also noted) allows us on in a very natural way to run jcheck on the commits in the pull request. I think the fact that we can translate a pull request to an "RFR" email thread shows the resemblance quite nicely. Pull requests provides not only a logical entity that jcheck can operate upon, but also additional tools such as the tester bot (available through the `/test` command in a pull request comment). I would also like to point that Skara enhances the "classical" pull request model in that the authors are the ones integrating the changes (compared to the maintainers integrating the changes in the "classical" pull request model). This is implemented through the `/integrate` command which is written in pull request comment, see pull request #249 towards Skara [0] for an example. > JEP-369 mentions that there is a wide range of preferred work patterns > for OpenJDK developers. I would also add that there is a wide range of > experience as well. What I see from the discussion on this thread so far > is relative contentment from those already using the push request model > on smaller projects, and concerns from those with limited or no > experience of it. The former have had the advantage of having time to > experiment with this model before it becomes intrinsic to the entire > project. I would suggest we try to do more of this rather than shift all > JDK 11 and up projects in one go. Many of us are not involved in the > projects that have experimented with this so far. A helpful next step > would be to use this model for the next update project, 14u. There is > then the opportunity for those on the JDK project to use it without > being obligated to switch to it for everything immediately. We have been transitioning a few OpenJDK projetcs to GitHub on a trial basis. To date these include: - Mobile - Loom - OpenJFX - JMC - Skara It has always been the intent to transition a few projects at a time and learn from their experiences _before_ the main JDK repository would be transitioned. Ideally the jdk/jdk repository would be the very last repository to transition. Thanks, Erik [0]: https://git.openjdk.java.net/skara/pull/249#issuecomment-552506961 > I can see the clear desire to implement JEP-357 sooner rather than > later. JEP-296 has created a situation where the current repositories > are struggling, due to their size. This is true even in local > transactions, without factoring in network isuses, and personally I'm > relieved when my work involves 7u & 8u rather than than slower 11u+ > repositories. I seem to recall that the issue of the individual jdk and > hotspot repositories already showing strain was raised at the time of > JEP-296, so we've seen this coming from some time. It worries me a > little that an entire DVCS swap is being proposed without, apparently, > any attempts to speed up Mercurial operations having being tried, but I > guess switching to git is more of a known result, and there's also a > general industry consensus around git that wasn't present when Mercurial > was selected in 2007. > I can't see the impetus for the push request model in the same way, and > it seems the switch to GitHub is being used to cloud the necessity of > such a move. As I said above, it would be much preferable to implement > git on GitHub using the existing processes and then consider such a > switch once everyone is settled, rather than attempting to combine the > two migrations. > > TL;DR: switch to Git & GitHub now, but reserve this JEP for > consideration of a push request model once that switch is fully complete. > > Thanks, > From neugens.limasoftware at gmail.com Thu Nov 14 14:55:13 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 14 Nov 2019 15:55:13 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> Message-ID: Il giorno gio 14 nov 2019 alle ore 15:42 Erik Helin ha scritto: > We have been transitioning a few OpenJDK projetcs to GitHub on a trial > basis. To date these include: > - Mobile > - Loom > - OpenJFX > - JMC > - Skara > > It has always been the intent to transition a few projects at a time and > learn from their experiences _before_ the main JDK repository would be > transitioned. Ideally the jdk/jdk repository would be the very last > repository to transition. Right, however none of those projects so far have real world, directly comparable, experiences to share. JMC for one is still running on mercurial and will only transition to GitHub for the 8.0 release train, which isn't yet even open. I think we really need to get back to this proposal in an year or two when we understand more of the implications. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From fw at deneb.enyo.de Thu Nov 14 19:01:13 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 14 Nov 2019 20:01:13 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> (Andrew Dinn's message of "Wed, 13 Nov 2019 10:36:42 +0000") References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: <87k182wadi.fsf@mid.deneb.enyo.de> * Andrew Dinn: > My experience of GitHub use in the Graal project suggest that this is > not entirely the full picture. My view derived from that experience is > that the GitHub PR is very much an inferior medium for review > discussion. In particular, it definitely fails to be "structurally > similar to the existing e-mail and webrev based workflows". I'm currently evaluating Gerrit for use with glibc, so this discussion struck a nerve with me. I haven't used Github or Gitlab in a significant way, though. What surprised me about Gerrit is that it's not a clear improvement over a mail workflow with a legacy mail client that has proper threading. (I assume the non-legacy clients also have ways to tag messages for later action, but I suspect that few people use them.) If people optimize for the threaded mail reader when they reply (trimming irrelevant context, replying to the right message etc.), it is surprisingly convenient for readers. Curiously, most non-legacy mail clients still get the threading metadata right even though they themselves do not use it. But that's not an option if the user enters their new comment in a box that applies to all previous comments equally. Given that, I wonder if the alternative should be to train more users on those older threading email clients. > By contrast discussions in GitHub PRs are essentially linearized (modulo > a single level of nesting of commentary on top level comments). Worse, > the presentation forces all commentary to be flattened into a single > browser pane view. This linear mode of presentation results in a severe > hindrance to separation of, and attention to, separate concerns. It also > fails to preserve and display source relationships that clarify the > provenance and relevance of quoted text i.e. it not only fails to record > but actually obfuscates important context. What happens to previous commentary when the PR is updated based on feedback? That's one of the things that's quite confusing in Gerrit. If you make a change and the diff hunk to which previous comments have been applied is gone, does that mean the comments' concerns have been addressed? It is impossible to know automatically. Gerrit does not automatically remove or close the comments, but hides them from the default view (i.e., there is no visual cue that there are unresolved comments on a previous version), which neatly reflects the inherent ambiguity of the situation, but is also not very helpful. The same problem exists with review email, of course, and I would argue that the separate webrev (as opposed to inline patches) makes that problem a little bit worse. But if the new webrev link is posted on the old thread (which is usually the case), I can view the old thread structure and poke around if there have been any unaddressed comments (which does not happen that often for me on OpenJDK lists, admittedly; I'm extrapolating from libc-alpha here). One more thing: I've been browsing the OpenJDK lists for a while, trying to help out if a discussion touches something where I feel I could make a useful contribution. I used to do this for more projects, but I couldn't quite get this working for me when those projects switched to Github. But the custom tooling I see on skara-dev looks actually pretty decent, although the threads there are pretty short and perhaps not representative of some of the longer review threads. We'll see. From fw at deneb.enyo.de Thu Nov 14 19:06:56 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 14 Nov 2019 20:06:56 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: (Erik Helin's message of "Wed, 13 Nov 2019 16:00:08 +0100") References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: <87ftiqwa3z.fsf@mid.deneb.enyo.de> * Erik Helin: > There is no such thing as "switching away from mailing lists to GitHub". > All activity on GitHub is mirrored on the OpenJDK mailing lists. Do you plan to use comments as a way to interact with various bots? Will those be mirrored as well? It's hard to pin down what I find so off-putting in the automated Github mail output. I suspect that one of the issues is that you often have a thread which contains solely of directive to bots and terse one-line statements. Sure, the data is all there, but it's either not very relevant to me as a reader (why would I care that someone has scheduled a trybot run?) or not very pleasant to read. With email, people make more of an effort to produce something useful to their (email) audience. Practices which have become appropriate for web tools (like treating comments as some sort of command line) do not translate to an email audience, unfortunately. From fw at deneb.enyo.de Thu Nov 14 19:20:45 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 14 Nov 2019 20:20:45 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: (Andrew John Hughes's message of "Wed, 13 Nov 2019 18:31:10 +0000") References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> Message-ID: <87bltew9gy.fsf@mid.deneb.enyo.de> * Andrew John Hughes: > Each developer has a fork of the actual repo as it stands now; this is > the very nature of using a distributed version control system (DVCS). > What differs with the pull request model is that fork is made public > rather than patches being generated from it and posted. The advantage of > that is that other developers can check out the published repository > rather than attempting to recreate it by applying the patch to their own > fork. *That* is a helpful property of these review tools because it removes ambiguity of what is being proposed. Even webrev normalizes submitted patches, so that it is less of a problem for OpenJDK, but just the other day, I managed to produce an empty webrev, and I've struggled with the tool before. So I'd gladly welcome an upgrade here. > Both changes - to using Git and to using a pull request model - > necessitate significant alterations to an OpenJDK developer's working > patterns. I would strongly suggest that the two are kept separate and > time given to adapt to the first before trying to implement the latter. > It is perfectly possible for someone to push their changes to a Git > repository rather than a Mercurial repository without having to change > the format of commit messages or the review process. That is true in general. However, with a migration to Github specifically, you do not have a choice: you cannot disable pull requests. You need to do *something* with them. If you do not support a pull request workflow, you have to close them and tell the would-be contributor to try again using the appropriate process. I can tell you from personal experience that this can be rather annoying. Especially with the OCA situation, I would suggest something that guides the submitter early on, instead of telling them that they did it incorrectly, with a delay. From omajid at redhat.com Thu Nov 14 19:47:03 2019 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Nov 2019 14:47:03 -0500 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <87k182wadi.fsf@mid.deneb.enyo.de> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <87k182wadi.fsf@mid.deneb.enyo.de> Message-ID: <87h836p7ew.fsf@redhat.com> Hi, Florian Weimer writes: > What happens to previous commentary when the PR is updated based on > feedback? That's one of the things that's quite confusing in Gerrit. > > If you make a change and the diff hunk to which previous comments have > been applied is gone, does that mean the comments' concerns have been > addressed? It is impossible to know automatically. Gerrit does not > automatically remove or close the comments, but hides them from the > default view (i.e., there is no visual cue that there are unresolved > comments on a previous version), which neatly reflects the inherent > ambiguity of the situation, but is also not very helpful. I can speak to this particular issue in github. When you comment on a line in the github web UI, and then rebase + force-push the commit so the line (or file!) isn't even there, github still keeps that comment and sticks an "outdated" label in that comment. Here is an example. I created a new file in a PR, left a comment to help reviewers, and then renamed the file. The comment still stays, but has an "Outdated" label until I (or someone else) hits the "Resolve conversation" button in the PR. https://github.com/dotnet/source-build/pull/1300#pullrequestreview-315785658 If you try and follow the comment to the (now gone) change in code, though, github will say it can't find the change that the comment refers to. Hopefully there's enough context in next to the comment to figure things out. Does that help address your concern? Thanks, Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0 From fw at deneb.enyo.de Thu Nov 14 19:56:52 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 14 Nov 2019 20:56:52 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <87h836p7ew.fsf@redhat.com> (Omair Majid's message of "Thu, 14 Nov 2019 14:47:03 -0500") References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <87k182wadi.fsf@mid.deneb.enyo.de> <87h836p7ew.fsf@redhat.com> Message-ID: <87pnhuut8b.fsf@mid.deneb.enyo.de> * Omair Majid: > Hi, > > Florian Weimer writes: > >> What happens to previous commentary when the PR is updated based on >> feedback? That's one of the things that's quite confusing in Gerrit. >> >> If you make a change and the diff hunk to which previous comments have >> been applied is gone, does that mean the comments' concerns have been >> addressed? It is impossible to know automatically. Gerrit does not >> automatically remove or close the comments, but hides them from the >> default view (i.e., there is no visual cue that there are unresolved >> comments on a previous version), which neatly reflects the inherent >> ambiguity of the situation, but is also not very helpful. > > I can speak to this particular issue in github. > > When you comment on a line in the github web UI, and then rebase + > force-push the commit so the line (or file!) isn't even there, github > still keeps that comment and sticks an "outdated" label in that comment. > > Here is an example. I created a new file in a PR, left a comment to help > reviewers, and then renamed the file. The comment still stays, but has > an "Outdated" label until I (or someone else) hits the "Resolve > conversation" button in the PR. > > https://github.com/dotnet/source-build/pull/1300#pullrequestreview-315785658 > > If you try and follow the comment to the (now gone) change in code, > though, github will say it can't find the change that the comment refers > to. Hopefully there's enough context in next to the comment to figure > things out. So this then only appears in the linearized pull request history, but not in the commit view. So at least it's not completely gone, which isn't too bad. It seems on par with any email-based solution. > Does that help address your concern? But now I have another one: Your email client replaced with , which I find ? odd. From omajid at redhat.com Thu Nov 14 20:03:02 2019 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Nov 2019 15:03:02 -0500 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <87pnhuut8b.fsf@mid.deneb.enyo.de> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <87k182wadi.fsf@mid.deneb.enyo.de> <87h836p7ew.fsf@redhat.com> <87pnhuut8b.fsf@mid.deneb.enyo.de> Message-ID: <87ftiqp6o9.fsf@redhat.com> Florian Weimer writes: > But now I have another one: Your email client replaced > with , which I find ? odd. That's partially an mu4e bug (or mis-configuration on my part) :( When responding to mailing lists, mu4e ignores the sender's original email address and puts the list in 'To' field. I added you back to 'To' by hand and I guess I picked the other email address. Regards, Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0 From per at bothner.com Thu Nov 14 21:04:11 2019 From: per at bothner.com (Per Bothner) Date: Thu, 14 Nov 2019 13:04:11 -0800 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> Message-ID: <5404f186-9e92-8d31-05ec-51e5972477f2@bothner.com> On 11/13/19 10:31 AM, Andrew John Hughes wrote: > Each developer has a fork of the actual repo as it stands now; this is > the very nature of using a distributed version control system (DVCS). > What differs with the pull request model is that fork is made public > rather than patches being generated from it and posted. The advantage of > that is that other developers can check out the published repository > rather than attempting to recreate it by applying the patch to their own > fork. The straight-forward way to "check out the published repository" unfortunately requires a lot of duplicated (wasted) bandwidth and disk space, for every time you want to test a patch. Probably there is tooling that can mitigate that. A related annoyance with the pull-request model is that every contributor needs to have public fork on GitHub, and create a fresh branch for each change. That seems a bit of a hassle compared to older ways of working. "The JEP proposes to support multiple workflows" - but do they all require a contributor to explicitly create a branch in a personal fork on GitHub? If not, how do they avoid that? One idea: a separate repository openjdk-prs that would be a clone of and automatically track the main openjdk. In addition, automated tools that process a patch would create an automatic branch with the change, and the automatically-generated pull request uses that branch. They branch can be automatically deleted when the PR is closed. (Anyway - just a crazy idea. I'm no longer an OpenJDK contributor, though who knows what might happen in the future.) -- --Per Bothner per at bothner.com http://per.bothner.com/ From erik.helin at oracle.com Fri Nov 15 10:06:05 2019 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 15 Nov 2019 11:06:05 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <87ftiqwa3z.fsf@mid.deneb.enyo.de> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <87ftiqwa3z.fsf@mid.deneb.enyo.de> Message-ID: <78adf3e1-3b14-ce38-c2a1-e73bb8590be3@oracle.com> Hey Florian, thanks for chiming in! On 11/14/19 8:06 PM, Florian Weimer wrote: > * Erik Helin: > >> There is no such thing as "switching away from mailing lists to GitHub". >> All activity on GitHub is mirrored on the OpenJDK mailing lists. > > Do you plan to use comments as a way to interact with various bots? Yes. > Will those be mirrored as well? No. > It's hard to pin down what I find so off-putting in the automated > Github mail output. I suspect that one of the issues is that you > often have a thread which contains solely of directive to bots and > terse one-line statements. Sure, the data is all there, but it's > either not very relevant to me as a reader (why would I care that > someone has scheduled a trybot run?) or not very pleasant to read. No, I agree that would not be very pleasant to read, which is why even the initial version of the mailing list bridge did not mirror comments consisting of commands :) Personally I'm using the skara-dev mailing list as the primary way to keep up with project Skara activity so its very important to me that we have a good mailing list experience. The mailing list bridge is *not* just a simple "send all comments created as a separate email". For the initial "RFR" email we decorate the email with useful information for reviewers, see for example [0]. Everything below the "----------------" lines is added by Skara. We _automatically_ provide reviewers with: - commits in the PR and their subjects - link to (automatically generated) webrev - link to JBS issue - direct link to the patch - direct link to the "Files Changed" tab in the PR - statistics for the patch - git fetch command - link to the pull request All the above is added to ensure that reviewers always have access to the information they need. We are of course more than happy if anyone has feedback on any additional information they would like to see here. For comments and replies we really strive to construct emails suitable for a mailing list. For example if you review on GitHub and add three review comments, then we don't send three separate emails (a mailing list user would never have done that). Instead we coalesce the three comments into a single email and also quote the relevant source code lines being commented upon. If the user provides a general review comment (in the "Review changes" dropdown) then that will be included prior to line-based comments. See [1] for an example. (Please note that there are still a few bugs to work out with replies and the mailing list bridge, Robin is currently working on that). I have been active on the OpenJDK mailing lists for 7+ years and have participated on other mailing lists long before then. I hope that I can bring some of this experience into Skara's mailing list bridge have a feeling for what the result should look like :) > With email, people make more of an effort to produce something useful > to their (email) audience. Practices which have become appropriate > for web tools (like treating comments as some sort of command line) do > not translate to an email audience, unfortunately. To be fair I think we see all kinds of emails on the OpenJDK mailing list with sometimes very different formatting/content conventions. There are those that top-post, those that aggressively trim quotations, those that always start with a greeting, those that always end with a "Thanks", "Cheers" or similar, those that use signatures, those that use localized quote headers, those that do not even use quote headers, etc. Will this change for better or worse with comments on GitHub? I think it comes down to the precedent we as a community set. I've seen very terse emails on OpenJDK mailing lists and I've read very enjoyable comments on GitHub (and vice-versa of course). Thanks, Erik [0]: https://mail.openjdk.java.net/pipermail/skara-dev/2019-November/001015.html [1]: https://mail.openjdk.java.net/pipermail/skara-dev/2019-November/001056.html From scolebourne at joda.org Fri Nov 15 10:16:55 2019 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 15 Nov 2019 10:16:55 +0000 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <20191112160000.9698430DBF0@eggemoggin.niobe.net> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> Message-ID: Just to note that I remain hugely supportive of this. GitHub's community interaction facilities have been very positive to use from my perspective, and I've never regretted moving to git or GitHub. With automated testing of patches, it will represent a step change in the ability to interact with the project. Stephen On Tue, 12 Nov 2019 at 16:01, wrote: > > https://openjdk.java.net/jeps/369 > > - Mark From neugens.limasoftware at gmail.com Fri Nov 15 10:37:15 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 15 Nov 2019 11:37:15 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> Message-ID: Il giorno ven 15 nov 2019 alle ore 11:17 Stephen Colebourne ha scritto: > > Just to note that I remain hugely supportive of this. GitHub's > community interaction facilities have been very positive to use from > my perspective, and I've never regretted moving to git or GitHub. With > automated testing of patches, it will represent a step change in the > ability to interact with the project. You don't need GitHub and its workflow to have have automated testing of patches, for instance it's nevertheless a good idea to extend the hotspot submit repo to cover any patch. In all those discussions we've always seen some form of "this will improve because X and Y" but overall those X and Y are actually independent from the move to GitHub and the new imposed workflow and never address the one and most important issue, the overhead of adapting to a completely new workflow and in particular that of the pull-request/public fork approach. I think the JEP should extensively prove why the change is significantly better than the status quo so that this change is worth, it feels to me that the situation is reversed here. Btw, I'll be very happy to host a discussion about this more during FOSDEM and have an actual confrontation, perhaps it's even a better idea to discuss this during the Committer's Workshop (assuming there will be one in February), but so far what I see is that this discussion is a bit stalled. In my previous email I jokingly said (and perhaps it wasn't really really clear I meant it like "good try Mario") to wait one or two years for this to settle, but I'm very convinced that we really need to give more time to the projects that were currently moved to GitHub to see if the additional hassle and the workflow change (including the time and resources needed to adjust the tools and the general ecosystem) is actually really that valuable: this JEP is premature. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From erik.helin at oracle.com Fri Nov 15 11:56:53 2019 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 15 Nov 2019 12:56:53 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <5404f186-9e92-8d31-05ec-51e5972477f2@bothner.com> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> <5404f186-9e92-8d31-05ec-51e5972477f2@bothner.com> Message-ID: <94791b6b-1c2b-3a25-1261-7fb491f095b6@oracle.com> On 11/14/19 10:04 PM, Per Bothner wrote: > On 11/13/19 10:31 AM, Andrew John Hughes wrote: >> Each developer has a fork of the actual repo as it stands now; this is >> the very nature of using a distributed version control system (DVCS). >> What differs with the pull request model is that fork is made public >> rather than patches being generated from it and posted. The advantage of >> that is that other developers can check out the published repository >> rather than attempting to recreate it by applying the patch to their own >> fork. > > The straight-forward way to "check out the published repository" > unfortunately > requires a lot of duplicated (wasted) bandwidth and disk space, for > every time > you want to test a patch.? Probably there is tooling that can mitigate > that. Anytime I clone a git repository I use the `--reference-if-able` flag [0] if I already have a local clone of the repository. For example: $ time git clone https://git.openjdk.java.net/jdk Cloning into 'jdk'... warning: redirecting to https://github.com/openjdk/jdk/ remote: Enumerating objects: 338, done. remote: Counting objects: 100% (338/338), done. remote: Compressing objects: 100% (162/162), done. remote: Total 997493 (delta 98), reused 219 (delta 79), pack-reused 997155 Receiving objects: 100% (997493/997493), 354.40 MiB | 24.43 MiB/s, done. Resolving deltas: 100% (744950/744950), done. Updating files: 100% (67977/67977), done. real 0m38.987s user 0m51.312s sys 0m4.512s $ time git clone --reference-if-able jdk \ https://git.openjdk.java.net/loom Cloning into 'loom'... warning: redirecting to https://github.com/openjdk/loom/ remote: Enumerating objects: 4975, done. remote: Counting objects: 100% (4975/4975), done. remote: Compressing objects: 100% (237/237), done. remote: Total 12878 (delta 4717), reused 4885 (delta 4695), pack-reused 7903 Receiving objects: 100% (12878/12878), 5.83 MiB | 9.15 MiB/s, done. Resolving deltas: 100% (10097/10097), completed with 1019 local objects. Updating files: 100% (68114/68114), done. real 0m12.520s user 0m5.312s sys 0m1.917s In the example above the first clone of the jdk repository took 38.987 seconds. The second clone of the loom repository took only 12.520 seconds because git could reuse almost all the repository data from my *local* jdk clone for the loom clone. > A related annoyance with the pull-request model is that every contributor > needs to have public fork on GitHub, and create a fresh branch for each > change. > That seems a bit of a hassle compared to older ways of working. > > "The JEP proposes to support multiple workflows" - but do they all require > a contributor to explicitly create a branch in a personal fork on GitHub? > If not, how do they avoid that? While you can create a pull request from the "master" branch of your personal fork, it is not recommended due to issues that can arise when you later want to sync the changes from the upstream repository's "master" branch to your personal fork's "master" branch. Hence the recommendation that contributors create a branch in their personal fork for the work they want to contribute. This might perhaps sound harder than it actually is in practice. With the Skara tooling [1] installed I typically do: $ cd /path/to/local/clone/of/personal/fork $ git switch --create bugfix # create new branch $ vim # do the actual work $ git commit -m 'Fixed a bug' # create commit $ git publish # publish branch on GitHub There are of course many other tools one can use instead of the git command-line interface, I just personally have a very CLI heavy workflow. Taking a little step back here my observation has been that almost all frequent OpenJDK contributors use some tooling to handle concurrent work, for example - Mercurial branches - Mercurial bookmarks - Mercurial topics - Mercurial anonymous heads - Mercurial patch queues (MQ) - A fresh local clone for every change Given that it often takes a couple of days to from the initial "RFR" email to pushing the finished commit all frequent contributors need _some_ way to model concurrent work (or else they would be stalled while waiting for reviewers' feedback). All of the above techniques have different pros and cons but I don't think git branches incur more overhead compared to the above listed techniques. > One idea: a separate repository openjdk-prs that would be a clone of and > automatically > track the main openjdk.? In addition, automated tools that process a > patch would create > an automatic branch with the change, and the automatically-generated > pull request > uses that branch.? They branch can be automatically deleted when the PR > is closed. > > (Anyway - just a crazy idea.? I'm no longer an OpenJDK contributor, > though who > knows what might happen in the future.) Crazy ideas are always welcome :) What you propose is certainly doable and is in fact in spirit somewhat similar to the jdk/sandbox repository [2]. We just haven't gotten around to set up a sandbox repository on GitHub, but that is certainly planned. OpenJDK Committers [3] would then be able to push to a branch in the sandbox repository and subsequently create a pull request from that branch. My guess is that most contributors would prefer to have a personal fork (which is similar to having a personal sandbox), but we can certainly set up a shared sandbox repository for those that would prefer it. We already have plenty of tooling to support forwarding commits between repositories, for example we continuously and automatically merge the jdk repository's "master" branch into the mobile repository's "master" branch. Thanks, Erik [0]: https://www.git-scm.com/docs/git-clone#Documentation/git-clone.txt---reference-if-ableltrepositorygt [1]: https://wiki.openjdk.java.net/display/skara#Skara-GettingStarted [2]: https://hg.openjdk.java.net/jdk/sandbox/ [3]: http://openjdk.java.net/bylaws#committer From neugens.limasoftware at gmail.com Fri Nov 15 13:07:12 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 15 Nov 2019 14:07:12 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: Two additional problems with using GitHub are the fact that GitHub does not allow multiple accounts, although you can configure multiple emails that mitigate this issue a bit, you are still bound to mix your work life with your non work life when it comes to OpenJDK contributions, I believe this also has an impact in the nice stats that every now and then show up related to who contribute to OpenJDK. The second, related in some sense, was brought up some weeks ago, but I'm not sure what was the followup on this, it seems that all the emails are generated as coming from @openjdk.java.net, which obviously isn't a real alias. While this kills spam bots, it makes it really hard to reach out the original authors for clarifications and followup post-commit. Cheers, Mario Il giorno mer 13 nov 2019 alle ore 11:36 Andrew Dinn ha scritto: > > On 12/11/2019 16:00, mark.reinhold at oracle.com wrote: > > https://openjdk.java.net/jeps/369 > Firstly, thanks to Joe and Erik for producing a very comprehensive JEP > that addresses so many important questions. There are many aspects of > this proposed move that are very appealing. However, I am afraid I am > still going to start by expressing my severe reservations about one > proposed change: replacing email review with GitHub PRs (sorry guys :-/). > > The JEP has this laudable goal: > > "Ensure that workflows structurally similar to the existing e-mail and > webrev based workflows are supported." > > and further qualifies that with: > > "Today, OpenJDK contributors collaborate via mailing lists, they push > changes to Mercurial repositories, they test changes via the jdk/submit > service, and they file bug reports via the JDK Bug System (JBS). > Contributors can also make use of several command-line interface (CLI) > tools, primarily jcheck, webrev, and defpath. This is a workflow that > many experienced contributors enjoy and find productive. It's therefore > critical to preserve as much of this workflow as possible if we move to > an external provider." > > which one cannot really disagree with. > > The JEP then explains that: > > "Reviewers can now discuss the changes in the PR, using multiple workflows: > > By replying to the RFR email sent to the mailing list(s), in which > case the contents of replies are copied into the PR on GitHub (no GitHub > account is required); > . . . > Any comment made in any of the workflows is reflected in all of the > workflows. One reviewer can add a comment via the mailing list, another > via the web browser, and a third via the command-line and they will all > see each others' comments." > > My experience of GitHub use in the Graal project suggest that this is > not entirely the full picture. My view derived from that experience is > that the GitHub PR is very much an inferior medium for review > discussion. In particular, it definitely fails to be "structurally > similar to the existing e-mail and webrev based workflows". > > Firstly, I'll note that email discussions consist of a tree of dependent > commentary. That commentary often contains quoted material which, > especially when carefully edited (as it normally is), tracks relevant > context. The structuring that results from this use of the reply > hierarchy and quoting permits a given discussion to split into a group > of related subordinate discussions where required while still retaining > a continued thread of relevance to a specific review. Crucially, most > email readers allow such branching discussions to be followed and > extended in /parallel/. > > By contrast discussions in GitHub PRs are essentially linearized (modulo > a single level of nesting of commentary on top level comments). Worse, > the presentation forces all commentary to be flattened into a single > browser pane view. This linear mode of presentation results in a severe > hindrance to separation of, and attention to, separate concerns. It also > fails to preserve and display source relationships that clarify the > provenance and relevance of quoted text i.e. it not only fails to record > but actually obfuscates important context. > > Of course, discussions that remain in email may continue to profit from > the multi-focus aspect of the current workflow. However, I believe that > contributions to the discussion via a GitHub PR will inevitably bypass > and, therefore, invalidate any such structuring contributed via the > email workflow. Not only do I currently see that effect with Graal PRs > but I also see the damage it imposes on flow and quality of discussion. > > Secondly, email reviews are conventionally directed to readers with > different domains of interest and expertise. That sometimes requires > re-routing a discussion to a different list from the one on which it was > first initiated. It also sometimes requires posting comments to multiple > lists, either when discussion is initiated or in mid-stream as the scope > of discussion develops. Managing distribution when using emails lists is > both easily achieved and well understood (n.b. that's not to imply that > deciding which list to send to is easy). > > The JEP suggests that discussions raised via PRs will be routed to lists > 1) derived from the affected files and/or 2) specified by whoever raises > the PR. It doesn't explain how (whether) target lists are to be (may be) > updated as review progresses. It also doesn't state clearly whether > whoever raises the PR or comments on it will have the ability to > override those default choices (I fully expect that option will be > necessary in some cases). > > I need to stress that these concerns should not be considered as minor > details of how the project operates. Easy management of the flow and > direction of discussion is critical to being able to consume and respond > to commentary at the rate needed to keep up with a project as large and > rapidly changing as OpenJDK currently is. Given the central importance > of our review process to ensuring the health of the project and its > products I think it is right to be very concerned about the potential > for problems caused by this switch of medium. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From eric.vergnaud at wanadoo.fr Fri Nov 15 14:59:49 2019 From: eric.vergnaud at wanadoo.fr (Eric Vergnaud) Date: Fri, 15 Nov 2019 22:59:49 +0800 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: Message-ID: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> Hi, Surely we all agree that facts provide better evidence than reasoning ? Git is a massive success! All sorts of teams in all sorts of projects have moved away from their preferred SCM, be it SVN, Mercurial or even Perforce. So without any arrogance, may I suggest that this community listens to the world as much as it listens to its own habits? Personally, I have been refrained from contributing by the absence of a simple Git powered CI. Eric Envoy? de mon iPhone > Le 15 nov. 2019 ? 18:38, Mario Torre a ?crit : > > ?Il giorno ven 15 nov 2019 alle ore 11:17 Stephen Colebourne > ha scritto: >> >> Just to note that I remain hugely supportive of this. GitHub's >> community interaction facilities have been very positive to use from >> my perspective, and I've never regretted moving to git or GitHub. With >> automated testing of patches, it will represent a step change in the >> ability to interact with the project. > > You don't need GitHub and its workflow to have have automated testing > of patches, for instance it's nevertheless a good idea to extend the > hotspot submit repo to cover any patch. > > In all those discussions we've always seen some form of "this will > improve because X and Y" but overall those X and Y are actually > independent from the move to GitHub and the new imposed workflow and > never address the one and most important issue, the overhead of > adapting to a completely new workflow and in particular that of the > pull-request/public fork approach. I think the JEP should extensively > prove why the change is significantly better than the status quo so > that this change is worth, it feels to me that the situation is > reversed here. > > Btw, I'll be very happy to host a discussion about this more during > FOSDEM and have an actual confrontation, perhaps it's even a better > idea to discuss this during the Committer's Workshop (assuming there > will be one in February), but so far what I see is that this > discussion is a bit stalled. > > In my previous email I jokingly said (and perhaps it wasn't really > really clear I meant it like "good try Mario") to wait one or two > years for this to settle, but I'm very convinced that we really need > to give more time to the projects that were currently moved to GitHub > to see if the additional hassle and the workflow change (including the > time and resources needed to adjust the tools and the general > ecosystem) is actually really that valuable: this JEP is premature. > > Cheers, > Mario > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From neugens at redhat.com Fri Nov 15 15:33:38 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 15 Nov 2019 16:33:38 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> Message-ID: On Fri, Nov 15, 2019 at 4:02 PM Eric Vergnaud wrote: > > Hi, > Surely we all agree that facts provide better evidence than reasoning ? > Git is a massive success! All sorts of teams in all sorts of projects have moved away from their preferred SCM, be it SVN, Mercurial or even Perforce. > So without any arrogance, may I suggest that this community listens to the world as much as it listens to its own habits? > Personally, I have been refrained from contributing by the absence of a simple Git powered CI. > Eric This is not a question about Git, it a question about GitHub. And to be honest, if you (or anyone) really wanted to contribute you would have done so, so "absence of contribution" because of a certain tool isn't present isn't much of an argument, I say that without malice and without any arrogance, of course. Moving OpenJDK forward isn't about gathering more contributors, is mostly about the quality of the contributions. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From scolebourne at joda.org Fri Nov 15 16:11:30 2019 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 15 Nov 2019 16:11:30 +0000 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> Message-ID: On Fri, 15 Nov 2019 at 15:35, Mario Torre wrote: > And to be honest, if you (or anyone) really wanted to contribute you > would have done so, so "absence of contribution" because of a certain > tool isn't present isn't much of an argument, I say that without > malice and without any arrogance, of course. An absolutely key reason for not contributing for me is that OpenJDK is on hg. I won't contribute code while it remains on hg, as my experience of OpenJDK on hg from JSR-310 was truly dire. Stephen From thomas.stuefe at gmail.com Fri Nov 15 16:21:48 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 15 Nov 2019 17:21:48 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> Message-ID: As Mario wrote, this JEP is about moving to Github. The move to git is a different JEP (357) and meets broad consensus, I think. Moving to github is a much larger decision. Quite a few large projects use git, but not github. For example, the Linux kernel. ..Thomas On Fri 15. Nov 2019 at 17:11, Stephen Colebourne wrote: > On Fri, 15 Nov 2019 at 15:35, Mario Torre wrote: > > And to be honest, if you (or anyone) really wanted to contribute you > > would have done so, so "absence of contribution" because of a certain > > tool isn't present isn't much of an argument, I say that without > > malice and without any arrogance, of course. > > An absolutely key reason for not contributing for me is that OpenJDK > is on hg. I won't contribute code while it remains on hg, as my > experience of OpenJDK on hg from JSR-310 was truly dire. > > Stephen > From fw at deneb.enyo.de Fri Nov 15 17:54:23 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 15 Nov 2019 18:54:23 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: (Mario Torre's message of "Fri, 15 Nov 2019 14:07:12 +0100") References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: <875zjlf2k0.fsf@mid.deneb.enyo.de> * Mario Torre: > Two additional problems with using GitHub are the fact that GitHub > does not allow multiple accounts, although you can configure multiple > emails that mitigate this issue a bit, you are still bound to mix your > work life with your non work life when it comes to OpenJDK > contributions, I believe this also has an impact in the nice stats > that every now and then show up related to who contribute to OpenJDK. You can have multiple accounts, but all except one must be paid accounts. I expect that employers will cover this because they want to retain control over the Github account if the employee leaves. I know that there is one exception, but I think it is very much an outlier. From franta-java at frantovo.cz Fri Nov 15 18:08:05 2019 From: franta-java at frantovo.cz (=?UTF-8?B?RnJhbnRpxaFlayBLdcSNZXJh?=) Date: Fri, 15 Nov 2019 19:08:05 +0100 Subject: =?UTF-8?Q?Re=3a_New_candidate_JEP=3a_369=3a_Migrate_to_GitHub_?= =?UTF-8?Q?=e2=80=93_contributors_should_not_be_required_to_have_a_GitHub_ac?= =?UTF-8?Q?count?= In-Reply-To: <20191112160000.9698430DBF0@eggemoggin.niobe.net> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> Message-ID: Dne 12. 11. 19 v 17:00 mark.reinhold at oracle.com napsal(a): > https://openjdk.java.net/jeps/369 > > - Mark Hello, I see that there is: ?- Ensure that workflows structurally similar to the existing e-mail and ?? webrev based workflows are supported. ?- Do not require developers to install OpenJDK specific tools in order ?? to contribute. ?- For contributors not wishing to create an account on GitHub, we would ?? continue to accept patches sent to the OpenJDK mailing lists. Could you please make it explicit (in the Goals section), that contributors will not be required to have a GitHub account? (and that users without such account will not be discriminated) I have signed your OCA and I fully understand why such paper is needed. But a completely different thing would be if I had to agree with GitHub's terms and conditions. From the free software (or open source) perspective, I consider it unacceptable if a contributor is forced to sign a contract with a third-party (like GitHub) in order to contribute to the project. I hope that the JEP is meant in this way and you are not going to require GitHub accounts, but please make it explicit and guarantee that OpenJDK is an independent project and does not require contributors to sign a contract with any third party. Thanks, Franta From david.lloyd at redhat.com Fri Nov 15 18:12:33 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 15 Nov 2019 12:12:33 -0600 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> Message-ID: On Fri, Nov 15, 2019 at 10:12 AM Stephen Colebourne wrote: > > On Fri, 15 Nov 2019 at 15:35, Mario Torre wrote: > > And to be honest, if you (or anyone) really wanted to contribute you > > would have done so, so "absence of contribution" because of a certain > > tool isn't present isn't much of an argument, I say that without > > malice and without any arrogance, of course. > > An absolutely key reason for not contributing for me is that OpenJDK > is on hg. I won't contribute code while it remains on hg, as my > experience of OpenJDK on hg from JSR-310 was truly dire. I agree, there are many occasions where I decided not to bother contributing a fix because the tooling is too onerous. Being able to open pull requests means I will probably offer many more contributions, large and small. It's very easy to imagine that this could be true for others as well. -- - DML From dalibor.topic at oracle.com Fri Nov 15 21:12:24 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 15 Nov 2019 22:12:24 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: <21af695d-b5b8-b014-1d05-edbbcafb967e@oracle.com> On 15.11.2019 14:07, Mario Torre wrote: > I believe this also has an impact in the nice stats > that every now and then show up related to who contribute to OpenJDK. This is getting somewhat off-topic, but I use e-mail addresses from JBS as the primary source for contribution attribution. So it's immaterial how many Github accounts someone has, from that perspective. cheers, dalibor topic -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From joe.darcy at oracle.com Fri Nov 15 21:20:18 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 15 Nov 2019 13:20:18 -0800 Subject: =?UTF-8?Q?Re=3a_New_candidate_JEP=3a_369=3a_Migrate_to_GitHub_?= =?UTF-8?Q?=e2=80=93_contributors_should_not_be_required_to_have_a_GitHub_ac?= =?UTF-8?Q?count?= In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> Message-ID: Hello, On 11/15/2019 10:08 AM, Franti?ek Ku?era wrote: > Dne 12. 11. 19 v 17:00 mark.reinhold at oracle.com napsal(a): >> https://openjdk.java.net/jeps/369 >> >> - Mark > > Hello, > > I see that there is: > > ?- Ensure that workflows structurally similar to the existing e-mail and > ?? webrev based workflows are supported. > ?- Do not require developers to install OpenJDK specific tools in order > ?? to contribute. > ?- For contributors not wishing to create an account on GitHub, we would > ?? continue to accept patches sent to the OpenJDK mailing lists. > > Could you please make it explicit (in the Goals section), that > contributors will not be required to have a GitHub account? (and that > users without such account will not be discriminated) > In the "Workflow" section the JEP explicitly states: "However, creating a PR requires an account on GitHub. For contributors not wishing to create an account on GitHub, we would continue to accept patches sent to the OpenJDK mailing lists. Such patches would, however, require a contributor with a GitHub account to create a PR, similar to how many contributors today help newcomers to create and upload webrevs to cr." Cheers, -Joe From kim.barrett at oracle.com Fri Nov 15 22:11:30 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 15 Nov 2019 17:11:30 -0500 Subject: =?utf-8?Q?Re=3A_New_candidate_JEP=3A_369=3A_Migrate_to_GitHub_?= =?utf-8?Q?=E2=80=93_contributors_should_not_be_required_to_have_a_GitHub_?= =?utf-8?Q?account?= In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> Message-ID: <89D57EDA-C038-4698-82F9-05266694C2F8@oracle.com> > On Nov 15, 2019, at 4:20 PM, Joe Darcy wrote: > > Hello, > > On 11/15/2019 10:08 AM, Franti?ek Ku?era wrote: >> Dne 12. 11. 19 v 17:00 mark.reinhold at oracle.com napsal(a): >>> https://openjdk.java.net/jeps/369 >>> >>> - Mark >> >> Hello, >> >> I see that there is: >> >> - Ensure that workflows structurally similar to the existing e-mail and >> webrev based workflows are supported. >> - Do not require developers to install OpenJDK specific tools in order >> to contribute. >> - For contributors not wishing to create an account on GitHub, we would >> continue to accept patches sent to the OpenJDK mailing lists. >> >> Could you please make it explicit (in the Goals section), that >> contributors will not be required to have a GitHub account? (and that >> users without such account will not be discriminated) >> > In the "Workflow" section the JEP explicitly states: > > "However, creating a PR requires an account on GitHub. For contributors not wishing to create an account on GitHub, we would continue to accept patches sent to the OpenJDK mailing lists. Such patches would, however, require a contributor with a GitHub account to create a PR, similar to how many contributors today help newcomers to create and upload webrevs to cr.? An important difference between those two cases is that the expectation with a newcomer is that if they continue to contribute they will eventually be granted the appropriate credentials and permissions and no longer need such help. I'm guessing that if a GitHub account is required to create a pull request, the associated push to the repository will also require a GitHub account. In which case a long-time OpenJDK contributor who is unwilling to create a GitHub account (for whatever reasons) will effectively be losing a key part of their committer status. From joe.darcy at oracle.com Fri Nov 15 22:17:31 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 15 Nov 2019 14:17:31 -0800 Subject: =?UTF-8?Q?Re=3a_New_candidate_JEP=3a_369=3a_Migrate_to_GitHub_?= =?UTF-8?Q?=e2=80=93_contributors_should_not_be_required_to_have_a_GitHub_ac?= =?UTF-8?Q?count?= In-Reply-To: <89D57EDA-C038-4698-82F9-05266694C2F8@oracle.com> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <89D57EDA-C038-4698-82F9-05266694C2F8@oracle.com> Message-ID: <90c6aaf5-bfbe-ae4b-49a1-d777465515c1@oracle.com> Hello, On 11/15/2019 2:11 PM, Kim Barrett wrote: >> On Nov 15, 2019, at 4:20 PM, Joe Darcy wrote: >> >> Hello, >> >> On 11/15/2019 10:08 AM, Franti?ek Ku?era wrote: >>> Dne 12. 11. 19 v 17:00 mark.reinhold at oracle.com napsal(a): >>>> https://openjdk.java.net/jeps/369 >>>> >>>> - Mark >>> Hello, >>> >>> I see that there is: >>> >>> - Ensure that workflows structurally similar to the existing e-mail and >>> webrev based workflows are supported. >>> - Do not require developers to install OpenJDK specific tools in order >>> to contribute. >>> - For contributors not wishing to create an account on GitHub, we would >>> continue to accept patches sent to the OpenJDK mailing lists. >>> >>> Could you please make it explicit (in the Goals section), that >>> contributors will not be required to have a GitHub account? (and that >>> users without such account will not be discriminated) >>> >> In the "Workflow" section the JEP explicitly states: >> >> "However, creating a PR requires an account on GitHub. For contributors not wishing to create an account on GitHub, we would continue to accept patches sent to the OpenJDK mailing lists. Such patches would, however, require a contributor with a GitHub account to create a PR, similar to how many contributors today help newcomers to create and upload webrevs to cr.? > An important difference between those two cases is that the > expectation with a newcomer is that if they continue to contribute > they will eventually be granted the appropriate credentials and > permissions and no longer need such help. > > I'm guessing that if a GitHub account is required to create a pull > request, the associated push to the repository will also require a > GitHub account. In which case a long-time OpenJDK contributor who is > unwilling to create a GitHub account (for whatever reasons) will > effectively be losing a key part of their committer status. Yes, a consequence of the model being proposed is that doing the equivalent of a push will require an account on the hosting provider. Cheers, -Joe From neugens.limasoftware at gmail.com Fri Nov 15 22:22:42 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 15 Nov 2019 23:22:42 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> Message-ID: One can argue that git is onerous the same way, the thing is that you are not used to mercurial so it appears difficult for you. For this reason I may say I won?t contribute a line of code if we switch to git but the reality is that if I want or need for some reason I find my way. After all we started with Classpath, that was cvs... All that said, this JEP is only incidentally about git, it?s about GitHub, and we shouldn?t confuse the two things. At the end of the day everyone will still have to go through the governance model so it can?t happen that we accept random contributions anymore than now, unless this JEP is also about changing the bylaw and giving away with the current role system. Cheers, Mario On Fri 15. Nov 2019 at 19:13, David Lloyd wrote: > On Fri, Nov 15, 2019 at 10:12 AM Stephen Colebourne > wrote: > > > > On Fri, 15 Nov 2019 at 15:35, Mario Torre wrote: > > > And to be honest, if you (or anyone) really wanted to contribute you > > > would have done so, so "absence of contribution" because of a certain > > > tool isn't present isn't much of an argument, I say that without > > > malice and without any arrogance, of course. > > > > An absolutely key reason for not contributing for me is that OpenJDK > > is on hg. I won't contribute code while it remains on hg, as my > > experience of OpenJDK on hg from JSR-310 was truly dire. > > I agree, there are many occasions where I decided not to bother > contributing a fix because the tooling is too onerous. Being able to > open pull requests means I will probably offer many more > contributions, large and small. It's very easy to imagine that this > could be true for others as well. > > -- > - DML > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From joe.darcy at oracle.com Fri Nov 15 22:39:13 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 15 Nov 2019 14:39:13 -0800 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> Message-ID: <3619dd09-ab39-e183-6eb7-c86a717d2ce5@oracle.com> On 11/15/2019 2:22 PM, Mario Torre wrote: > One can argue that git is onerous the same way, the thing is that you are > not used to mercurial so it appears difficult for you. For this reason I > may say I won?t contribute a line of code if we switch to git but the > reality is that if I want or need for some reason I find my way. After all > we started with Classpath, that was cvs... > > All that said, this JEP is only incidentally about git, it?s about GitHub, > and we shouldn?t confuse the two things. > > At the end of the day everyone will still have to go through the governance > model so it can?t happen that we accept random contributions anymore than > now, unless this JEP is also about changing the bylaw and giving away with > the current role system. The governance model implications are explicitly mentioned in the JEP in the goals section: > * Do not change the OpenJDK Bylaws . > * Do not change the OpenJDK Census . > I attended an OpenJDK governing board meeting this October to discuss Skara: ??? ?? https://openjdk.java.net/groups/gb/minutes/2019-10-10 The slides I presented explicitly quote from the current bylaws: Section 6 of the OpenJDK Bylaws: "A Project may have web content, one or more code repositories, and one or more mailing lists. Projects are expected to operate in an open, transparent, and meritocratic manner. Their alignment with these principles will be monitored by the Governing Board." Appendix A of the OpenJDK Bylaws: "The data stored in any infrastructure provided for use by Community members must be made available by some means that enables, without undue effort, the construction of a complete functional clone of that infrastructure and its data as seen by the entire Community." No one present at the meeting disagreed with the assessment that the bylaws would *not* need to be updated to use a hosting provider for the JDK's sources. -Joe From neugens.limasoftware at gmail.com Fri Nov 15 23:22:41 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 16 Nov 2019 00:22:41 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <3619dd09-ab39-e183-6eb7-c86a717d2ce5@oracle.com> References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> <3619dd09-ab39-e183-6eb7-c86a717d2ce5@oracle.com> Message-ID: Hi Joe, Thanks for sharing this. On question still remains however, with the move to a pull request model we effectively give up the role of a committer (even if we maintain it to respect the bylaw it would be an empty role), this is because the reviewer or maintainer that approves the change request of effectively committing and the original author of the patch may have any of the roles from a simple contributor to a reviewer. Is that true or how else would we be dealing with contributions? Cheers, Mario On Fri 15. Nov 2019 at 23:39, Joe Darcy wrote: > On 11/15/2019 2:22 PM, Mario Torre wrote: > > One can argue that git is onerous the same way, the thing is that you are > not used to mercurial so it appears difficult for you. For this reason I > may say I won?t contribute a line of code if we switch to git but the > reality is that if I want or need for some reason I find my way. After all > we started with Classpath, that was cvs... > > All that said, this JEP is only incidentally about git, it?s about GitHub, > and we shouldn?t confuse the two things. > > At the end of the day everyone will still have to go through the governance > model so it can?t happen that we accept random contributions anymore than > now, unless this JEP is also about changing the bylaw and giving away with > the current role system. > > The governance model implications are explicitly mentioned in the JEP in > the goals section: > > > - Do not change the OpenJDK Bylaws . > - Do not change the OpenJDK Census . > > I attended an OpenJDK governing board meeting this October to discuss > Skara: > > https://openjdk.java.net/groups/gb/minutes/2019-10-10 > > The slides I presented explicitly quote from the current bylaws: > > Section 6 of the OpenJDK Bylaws: "A Project may have web content, one or > more code repositories, and one or more mailing lists. Projects are > expected to operate in an open, transparent, and meritocratic manner. Their > alignment with these principles will be monitored by the Governing Board." > > Appendix A of the OpenJDK Bylaws: "The data stored in any infrastructure > provided for use by Community members must be made available by some means > that enables, without undue effort, the construction of a complete > functional clone of that infrastructure and its data as seen by the entire > Community." > > No one present at the meeting disagreed with the assessment that the > bylaws would *not* need to be updated to use a hosting provider for the > JDK's sources. > > > -Joe > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From kevin.rushforth at oracle.com Fri Nov 15 23:34:26 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 15 Nov 2019 15:34:26 -0800 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> <3619dd09-ab39-e183-6eb7-c86a717d2ce5@oracle.com> Message-ID: <41c038e4-95d2-e2f7-785b-c9ace749cc7b@oracle.com> No, that isn't quite right. A contributor who has the role of Committer is the one who initiates the commit, either via the GitHub UI, by entering the "/integrate" command, or via the Skara tooling, by running "git pr integrate". If a project is set up to require reviewers, then there must be at least one approved review by someone with a Reviewer role in the project must approve it, but it is the Committer who integrates it after the review is done, and after all other requirements are satisfied (e.g., many groups require a second reviewer, API changes require a CSR, etc). A contributor who is not a Committer, needs to have a sponsoring Committer "/sponsor" their change after they issue the "/integrate" command to indicate that they are ready for it to be pushed. In both cases, it is the Committer who initiates the push. -- Kevin On 11/15/2019 3:22 PM, Mario Torre wrote: > Hi Joe, > > Thanks for sharing this. > > On question still remains however, with the move to a pull request model we > effectively give up the role of a committer (even if we maintain it to > respect the bylaw it would be an empty role), this is because the reviewer > or maintainer that approves the change request of effectively committing > and the original author of the patch may have any of the roles from a > simple contributor to a reviewer. > > Is that true or how else would we be dealing with contributions? > > Cheers, > Mario > > On Fri 15. Nov 2019 at 23:39, Joe Darcy wrote: > >> On 11/15/2019 2:22 PM, Mario Torre wrote: >> >> One can argue that git is onerous the same way, the thing is that you are >> not used to mercurial so it appears difficult for you. For this reason I >> may say I won?t contribute a line of code if we switch to git but the >> reality is that if I want or need for some reason I find my way. After all >> we started with Classpath, that was cvs... >> >> All that said, this JEP is only incidentally about git, it?s about GitHub, >> and we shouldn?t confuse the two things. >> >> At the end of the day everyone will still have to go through the governance >> model so it can?t happen that we accept random contributions anymore than >> now, unless this JEP is also about changing the bylaw and giving away with >> the current role system. >> >> The governance model implications are explicitly mentioned in the JEP in >> the goals section: >> >> >> - Do not change the OpenJDK Bylaws . >> - Do not change the OpenJDK Census . >> >> I attended an OpenJDK governing board meeting this October to discuss >> Skara: >> >> https://openjdk.java.net/groups/gb/minutes/2019-10-10 >> >> The slides I presented explicitly quote from the current bylaws: >> >> Section 6 of the OpenJDK Bylaws: "A Project may have web content, one or >> more code repositories, and one or more mailing lists. Projects are >> expected to operate in an open, transparent, and meritocratic manner. Their >> alignment with these principles will be monitored by the Governing Board." >> >> Appendix A of the OpenJDK Bylaws: "The data stored in any infrastructure >> provided for use by Community members must be made available by some means >> that enables, without undue effort, the construction of a complete >> functional clone of that infrastructure and its data as seen by the entire >> Community." >> >> No one present at the meeting disagreed with the assessment that the >> bylaws would *not* need to be updated to use a hosting provider for the >> JDK's sources. >> >> >> -Joe >> From neugens.limasoftware at gmail.com Sat Nov 16 01:43:25 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 16 Nov 2019 02:43:25 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <41c038e4-95d2-e2f7-785b-c9ace749cc7b@oracle.com> References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> <3619dd09-ab39-e183-6eb7-c86a717d2ce5@oracle.com> <41c038e4-95d2-e2f7-785b-c9ace749cc7b@oracle.com> Message-ID: Hi Kevin, I admit I had to read the email a few times and my first reaction was how can people say that this process is simpler than the current mercurial workflow. Anyway, I guess I have to try it out before I can be properly critic. Cheers, Mario On Sat 16. Nov 2019 at 00:34, Kevin Rushforth wrote: > No, that isn't quite right. A contributor who has the role of Committer > is the one who initiates the commit, either via the GitHub UI, by > entering the "/integrate" command, or via the Skara tooling, by running > "git pr integrate". > > If a project is set up to require reviewers, then there must be at least > one approved review by someone with a Reviewer role in the project must > approve it, but it is the Committer who integrates it after the review > is done, and after all other requirements are satisfied (e.g., many > groups require a second reviewer, API changes require a CSR, etc). > > A contributor who is not a Committer, needs to have a sponsoring > Committer "/sponsor" their change after they issue the "/integrate" > command to indicate that they are ready for it to be pushed. > > In both cases, it is the Committer who initiates the push. > > -- Kevin > > > On 11/15/2019 3:22 PM, Mario Torre wrote: > > Hi Joe, > > > > Thanks for sharing this. > > > > On question still remains however, with the move to a pull request model > we > > effectively give up the role of a committer (even if we maintain it to > > respect the bylaw it would be an empty role), this is because the > reviewer > > or maintainer that approves the change request of effectively committing > > and the original author of the patch may have any of the roles from a > > simple contributor to a reviewer. > > > > Is that true or how else would we be dealing with contributions? > > > > Cheers, > > Mario > > > > On Fri 15. Nov 2019 at 23:39, Joe Darcy wrote: > > > >> On 11/15/2019 2:22 PM, Mario Torre wrote: > >> > >> One can argue that git is onerous the same way, the thing is that you > are > >> not used to mercurial so it appears difficult for you. For this reason I > >> may say I won?t contribute a line of code if we switch to git but the > >> reality is that if I want or need for some reason I find my way. After > all > >> we started with Classpath, that was cvs... > >> > >> All that said, this JEP is only incidentally about git, it?s about > GitHub, > >> and we shouldn?t confuse the two things. > >> > >> At the end of the day everyone will still have to go through the > governance > >> model so it can?t happen that we accept random contributions anymore > than > >> now, unless this JEP is also about changing the bylaw and giving away > with > >> the current role system. > >> > >> The governance model implications are explicitly mentioned in the JEP in > >> the goals section: > >> > >> > >> - Do not change the OpenJDK Bylaws >. > >> - Do not change the OpenJDK Census >. > >> > >> I attended an OpenJDK governing board meeting this October to discuss > >> Skara: > >> > >> https://openjdk.java.net/groups/gb/minutes/2019-10-10 > >> > >> The slides I presented explicitly quote from the current bylaws: > >> > >> Section 6 of the OpenJDK Bylaws: "A Project may have web content, one or > >> more code repositories, and one or more mailing lists. Projects are > >> expected to operate in an open, transparent, and meritocratic manner. > Their > >> alignment with these principles will be monitored by the Governing > Board." > >> > >> Appendix A of the OpenJDK Bylaws: "The data stored in any infrastructure > >> provided for use by Community members must be made available by some > means > >> that enables, without undue effort, the construction of a complete > >> functional clone of that infrastructure and its data as seen by the > entire > >> Community." > >> > >> No one present at the meeting disagreed with the assessment that the > >> bylaws would *not* need to be updated to use a hosting provider for the > >> JDK's sources. > >> > >> > >> -Joe > >> > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From franta-java at frantovo.cz Sat Nov 16 14:41:58 2019 From: franta-java at frantovo.cz (=?UTF-8?B?RnJhbnRpxaFlayBLdcSNZXJh?=) Date: Sat, 16 Nov 2019 15:41:58 +0100 Subject: =?UTF-8?Q?Re=3a_New_candidate_JEP=3a_369=3a_Migrate_to_GitHub_?= =?UTF-8?Q?=e2=80=93_Eating_your_own_dog_food=3f?= In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> Message-ID: Dne 13. 11. 19 v 15:15 Thomas St?fe napsal(a): > So, this is also an assumption - that the tool chain keeps working and that > the effort spent maintaining it is less than the effort spent today on > maintaining the old infrastructure (which to be fair is done by Oracle > alone). A classic quote: ?There is nothing more expensive than something free?. Why should we expect that anyone is willing to reduce Oracle's costs by providing a service for free or cheaply? Of course, there are economies of scale, but Oracle or OpenJDK itself are quite big and there are much smaller teams or even individuals who run own source code repositories on their own servers. Another thing that is unclear to me: how is Oracle going to offer and sell their cloud services like ?Streamline Team Development and Software Delivery? (that include Version Management ? Git repositories) to the customers, while not providing the hosting service to their own projects like OpenJDK. The centralization of more and more projects under a single provider/corporation (GitHub) is IMHO not a good way to develop software. Especially in the long term. And if we talk about comfort and attractiveness for random contributors ? what about open standards (e.g. for single-sign-on)? Are not they a better way than centralizing everything under a single provider/company? Franta From johan at lodgon.com Sat Nov 16 18:28:26 2019 From: johan at lodgon.com (Johan Vos) Date: Sat, 16 Nov 2019 19:28:26 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <20191112160000.9698430DBF0@eggemoggin.niobe.net> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> Message-ID: I've had the privilege to work with the Skara tools in both the OpenJDK Mobile and the OpenJFX projects. Having read most of the comments in this thread, there are a few things that I would like to add. The quality of a project like OpenJDK highly depends on the committers. If we want to maintain the current high quality, it is important that the current committers, who are responsible for this quality, are ok with changes in the process. My observation during the OpenJDK Committers' Workshops is that most committers are ok. However, it's very important to take into account the critics from committers who do not like this JEP. >From what I've read so far, and from my experience dealing with the Skara team, I personally don't see real showstoppers. One of the things I really like about the Skara approach is the automatic creation of an RFR mail and the creation of a webrev. That already saved me lots of time in the OpenJFX project, time that I could contribute to write code or review PR's. More automation, less chances for typo's are a great thing. I like the guidelines of the bot and the flow is very intuitive. I can choose to work via the web interface or via the CLI. Yes, the GitHub web interface is by no means a 100% match of the email approach, and I don't hide it that I'm not a big fan of the "Web-everywhere-for-everything" approach, on the contrary. However, comparing other github projects I work on with the Skara-based projects I work on, I really like the Skara approach. Thanks to the Skara tools, the dependency on web-based control flow is much lower. And most important, the Skara tools are open source and can be discussed and improved. I honestly don't know what the best approach is for discussing PR's. As stated in other replies, the conversation-tab in the GitHub PR's has its limitations, but it has also stated correctly that email discussions have limitations and can create confusion as well. Looking at the alternatives in the JEP, there is nothing that comes close to the current proposal. While I don't think there will immediately be a large number of high-quality new contributors simply because of the move to github, I am convinced the barrier becomes lower. Moreover, the github approach makes it easier for developers who depend on the JDK to examine the code if needed. I often run into issues with third party software, and when I can easily find the code on github, it makes it much easier to understand, appreciate, or even help. Having to browse through the hg web interface, or download the whole JDK project, is not really inviting. As I stated in the beginning, the high quality of OpenJDK is mainly achieved because of the real smart committers behind it (and the companies paying them), and the high-quality code committed and reviewed by those. There are not many software projects that can celebrate their 25th birthday like this. Committers write code, and use infrastructure to collaborate. Infrastructure evolves. I've been a happy mercurial user for a long time, and gradually moved to git and mainly github over the past years. None of the bottlenecks I ran into have been due to github. As long as the quality bar is not lowered, I'm ok with changes in infrastructure. - Johan Op di 12 nov. 2019 om 17:02 schreef : > https://openjdk.java.net/jeps/369 > > - Mark > From joe.darcy at oracle.com Sat Nov 16 20:38:20 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 16 Nov 2019 12:38:20 -0800 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> Message-ID: <98b61755-e1eb-62cd-d84d-ec4667f316af@oracle.com> Hello, A sentiment that has been expressed several times on this thread is "If someone is dedicated enough to the JDK, they'll just learn to use Mercurial." This can easily go in the other direction; if the JDK moves to Git on a hosting provider, "If someone is dedicated enough to the JDK, they'll just learn to use Git on a hosting provider." As Git is currently the most widely-used SCM and GitHub a common hosting provider, many people may have very little to learn. As has been attested to several times on this thread, there are at least several experienced developers who have been put off from contributing to the JDK because of the SCM situation. My sense is that many developers feel the JDK's continued use of Mercurial is retrograde and that a move to Git on a hosting provider is already years overdue. I think postponing consideration of a migration another year, two years, (five years?, ten years?) would be harmful to the health of the overall JDK effort. Any SCM move has the potential to be disruptive, but such a move should be approached with care rather than timidity. -Joe On 11/15/2019 2:37 AM, Mario Torre wrote: > Il giorno ven 15 nov 2019 alle ore 11:17 Stephen Colebourne > ha scritto: >> Just to note that I remain hugely supportive of this. GitHub's >> community interaction facilities have been very positive to use from >> my perspective, and I've never regretted moving to git or GitHub. With >> automated testing of patches, it will represent a step change in the >> ability to interact with the project. > You don't need GitHub and its workflow to have have automated testing > of patches, for instance it's nevertheless a good idea to extend the > hotspot submit repo to cover any patch. > > In all those discussions we've always seen some form of "this will > improve because X and Y" but overall those X and Y are actually > independent from the move to GitHub and the new imposed workflow and > never address the one and most important issue, the overhead of > adapting to a completely new workflow and in particular that of the > pull-request/public fork approach. I think the JEP should extensively > prove why the change is significantly better than the status quo so > that this change is worth, it feels to me that the situation is > reversed here. > > Btw, I'll be very happy to host a discussion about this more during > FOSDEM and have an actual confrontation, perhaps it's even a better > idea to discuss this during the Committer's Workshop (assuming there > will be one in February), but so far what I see is that this > discussion is a bit stalled. > > In my previous email I jokingly said (and perhaps it wasn't really > really clear I meant it like "good try Mario") to wait one or two > years for this to settle, but I'm very convinced that we really need > to give more time to the projects that were currently moved to GitHub > to see if the additional hassle and the workflow change (including the > time and resources needed to adjust the tools and the general > ecosystem) is actually really that valuable: this JEP is premature. > > Cheers, > Mario > From Dell.Green at ideaworks.co.uk Sun Nov 17 14:20:00 2019 From: Dell.Green at ideaworks.co.uk (Dell Green) Date: Sun, 17 Nov 2019 14:20:00 +0000 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: Message-ID: I'm sure many of us contribute to many open source projects. Tying dedication to a project to the learning of mercurial doesn't factor in that everyone has priorities, and these priorities are not necessarily to invest in the learning of an SCM that none of your other projects use, especially if someone else is paying for your time. Get Outlook for Android ________________________________ From: discuss on behalf of discuss-request at openjdk.java.net Sent: Sunday, November 17, 2019 12:00:19 PM To: discuss at openjdk.java.net Subject: discuss Digest, Vol 151, Issue 15 Send discuss mailing list submissions to discuss at openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit https://mail.openjdk.java.net/mailman/listinfo/discuss or, via email, send a message with subject or body 'help' to discuss-request at openjdk.java.net You can reach the person managing the list at discuss-owner at openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of discuss digest..." Today's Topics: 1. Re: New candidate JEP: 369: Migrate to GitHub ? Eating your own dog food? (Franti?ek Ku?era) 2. Re: New candidate JEP: 369: Migrate to GitHub (Johan Vos) 3. Re: New candidate JEP: 369: Migrate to GitHub (Joe Darcy) ---------------------------------------------------------------------- Message: 1 Date: Sat, 16 Nov 2019 15:41:58 +0100 From: Franti?ek Ku?era To: discuss at openjdk.java.net Subject: Re: New candidate JEP: 369: Migrate to GitHub ? Eating your own dog food? Message-ID: Content-Type: text/plain; charset=utf-8 Dne 13. 11. 19 v 15:15 Thomas St?fe napsal(a): > So, this is also an assumption - that the tool chain keeps working and that > the effort spent maintaining it is less than the effort spent today on > maintaining the old infrastructure (which to be fair is done by Oracle > alone). A classic quote: ?There is nothing more expensive than something free?. Why should we expect that anyone is willing to reduce Oracle's costs by providing a service for free or cheaply? Of course, there are economies of scale, but Oracle or OpenJDK itself are quite big and there are much smaller teams or even individuals who run own source code repositories on their own servers. Another thing that is unclear to me: how is Oracle going to offer and sell their cloud services like ?Streamline Team Development and Software Delivery? (that include Version Management ? Git repositories) to the customers, while not providing the hosting service to their own projects like OpenJDK. The centralization of more and more projects under a single provider/corporation (GitHub) is IMHO not a good way to develop software. Especially in the long term. And if we talk about comfort and attractiveness for random contributors ? what about open standards (e.g. for single-sign-on)? Are not they a better way than centralizing everything under a single provider/company? Franta ------------------------------ Message: 2 Date: Sat, 16 Nov 2019 19:28:26 +0100 From: Johan Vos To: discuss at openjdk.java.net Subject: Re: New candidate JEP: 369: Migrate to GitHub Message-ID: Content-Type: text/plain; charset="UTF-8" I've had the privilege to work with the Skara tools in both the OpenJDK Mobile and the OpenJFX projects. Having read most of the comments in this thread, there are a few things that I would like to add. The quality of a project like OpenJDK highly depends on the committers. If we want to maintain the current high quality, it is important that the current committers, who are responsible for this quality, are ok with changes in the process. My observation during the OpenJDK Committers' Workshops is that most committers are ok. However, it's very important to take into account the critics from committers who do not like this JEP. >From what I've read so far, and from my experience dealing with the Skara team, I personally don't see real showstoppers. One of the things I really like about the Skara approach is the automatic creation of an RFR mail and the creation of a webrev. That already saved me lots of time in the OpenJFX project, time that I could contribute to write code or review PR's. More automation, less chances for typo's are a great thing. I like the guidelines of the bot and the flow is very intuitive. I can choose to work via the web interface or via the CLI. Yes, the GitHub web interface is by no means a 100% match of the email approach, and I don't hide it that I'm not a big fan of the "Web-everywhere-for-everything" approach, on the contrary. However, comparing other github projects I work on with the Skara-based projects I work on, I really like the Skara approach. Thanks to the Skara tools, the dependency on web-based control flow is much lower. And most important, the Skara tools are open source and can be discussed and improved. I honestly don't know what the best approach is for discussing PR's. As stated in other replies, the conversation-tab in the GitHub PR's has its limitations, but it has also stated correctly that email discussions have limitations and can create confusion as well. Looking at the alternatives in the JEP, there is nothing that comes close to the current proposal. While I don't think there will immediately be a large number of high-quality new contributors simply because of the move to github, I am convinced the barrier becomes lower. Moreover, the github approach makes it easier for developers who depend on the JDK to examine the code if needed. I often run into issues with third party software, and when I can easily find the code on github, it makes it much easier to understand, appreciate, or even help. Having to browse through the hg web interface, or download the whole JDK project, is not really inviting. As I stated in the beginning, the high quality of OpenJDK is mainly achieved because of the real smart committers behind it (and the companies paying them), and the high-quality code committed and reviewed by those. There are not many software projects that can celebrate their 25th birthday like this. Committers write code, and use infrastructure to collaborate. Infrastructure evolves. I've been a happy mercurial user for a long time, and gradually moved to git and mainly github over the past years. None of the bottlenecks I ran into have been due to github. As long as the quality bar is not lowered, I'm ok with changes in infrastructure. - Johan Op di 12 nov. 2019 om 17:02 schreef : > https://openjdk.java.net/jeps/369 > > - Mark > ------------------------------ Message: 3 Date: Sat, 16 Nov 2019 12:38:20 -0800 From: Joe Darcy To: Mario Torre , Stephen Colebourne Cc: discuss Subject: Re: New candidate JEP: 369: Migrate to GitHub Message-ID: <98b61755-e1eb-62cd-d84d-ec4667f316af at oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Hello, A sentiment that has been expressed several times on this thread is "If someone is dedicated enough to the JDK, they'll just learn to use Mercurial." This can easily go in the other direction; if the JDK moves to Git on a hosting provider, "If someone is dedicated enough to the JDK, they'll just learn to use Git on a hosting provider." As Git is currently the most widely-used SCM and GitHub a common hosting provider, many people may have very little to learn. As has been attested to several times on this thread, there are at least several experienced developers who have been put off from contributing to the JDK because of the SCM situation. My sense is that many developers feel the JDK's continued use of Mercurial is retrograde and that a move to Git on a hosting provider is already years overdue. I think postponing consideration of a migration another year, two years, (five years?, ten years?) would be harmful to the health of the overall JDK effort. Any SCM move has the potential to be disruptive, but such a move should be approached with care rather than timidity. -Joe On 11/15/2019 2:37 AM, Mario Torre wrote: > Il giorno ven 15 nov 2019 alle ore 11:17 Stephen Colebourne > ha scritto: >> Just to note that I remain hugely supportive of this. GitHub's >> community interaction facilities have been very positive to use from >> my perspective, and I've never regretted moving to git or GitHub. With >> automated testing of patches, it will represent a step change in the >> ability to interact with the project. > You don't need GitHub and its workflow to have have automated testing > of patches, for instance it's nevertheless a good idea to extend the > hotspot submit repo to cover any patch. > > In all those discussions we've always seen some form of "this will > improve because X and Y" but overall those X and Y are actually > independent from the move to GitHub and the new imposed workflow and > never address the one and most important issue, the overhead of > adapting to a completely new workflow and in particular that of the > pull-request/public fork approach. I think the JEP should extensively > prove why the change is significantly better than the status quo so > that this change is worth, it feels to me that the situation is > reversed here. > > Btw, I'll be very happy to host a discussion about this more during > FOSDEM and have an actual confrontation, perhaps it's even a better > idea to discuss this during the Committer's Workshop (assuming there > will be one in February), but so far what I see is that this > discussion is a bit stalled. > > In my previous email I jokingly said (and perhaps it wasn't really > really clear I meant it like "good try Mario") to wait one or two > years for this to settle, but I'm very convinced that we really need > to give more time to the projects that were currently moved to GitHub > to see if the additional hassle and the workflow change (including the > time and resources needed to adjust the tools and the general > ecosystem) is actually really that valuable: this JEP is premature. > > Cheers, > Mario > End of discuss Digest, Vol 151, Issue 15 **************************************** From victorwssilva at gmail.com Sun Nov 17 20:40:29 2019 From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva) Date: Sun, 17 Nov 2019 18:40:29 -0200 Subject: Java download page still pointing to Java 8 Message-ID: Hi. I'm not sure if this is the right place to ask for this, but I'll try anyway, since I couldn't find a better one. I know about some people who thinks that Java 8 is the latest version. Most of those are either very newbies or people locked inside legacy-driven company that are afraid of updating anything and aren't tuned into hearing anything out of their own echo chambers. Also, unfortunately, I don't think that they are a small set of people. Anyway, I was curious of why those people thinks that there was nothing new since Java 8 and asked a few of them. The answer was very simple: Just type "download java" at Google and the first result will point to this page: https://www.java.com/en/download/ Or, in my locale, to this one: https://www.java.com/pt_BR/download/ That page offers Java 8 to be download and gives no hint whatsoever that we are already at 13 and going to 14. This induces many people to download Java 8 thinking that it is the latest version and the site's UI highly induces people to download Java 8. In fact, navigating a few links on the left side panel, I could even find a link to download Java 7, but no single mention to anything newer than Java 8. So, could I humbly ask that this page to be updated to either replace the ancient Java 8 with Java 13 or at least add a very noticeable link somewhere inviting the user to try Java 13 and warn that Java 8 is old? Also, a similar problem happens when you type "download jre" or "download jdk" on Google. You will be directed to pages that invite you to download Java 8 without any mention that there are newer stuff around. From dalibor.topic at oracle.com Mon Nov 18 10:48:04 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 18 Nov 2019 11:48:04 +0100 Subject: Java download page still pointing to Java 8 In-Reply-To: References: Message-ID: <09f0168f-3f0e-c0cd-35ef-b0b3a726745c@oracle.com> On 17.11.2019 21:40, Victor Williams Stafusa da Silva wrote: > Hi. I'm not sure if this is the right place to ask for this, but I'll try > anyway, since I couldn't find a better one. Hi, There is a feedback link on the bottom of the java.com web page(s). cheers, dalibor topic -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Mon Nov 18 11:15:44 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 18 Nov 2019 12:15:44 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> Message-ID: On 14.11.2019 15:55, Mario Torre wrote:> Right, however none of those projects so far have real world, directly > comparable, experiences to share. JMC for one is still running on > mercurial and will only transition to GitHub for the 8.0 release > train, which isn't yet even open. > > I think we really need to get back to this proposal in an year or two > when we understand more of the implications. > Considering that Mercurial requires [0] Python 2.7 and Python 2.7 has six more weeks of life left [1], well ... I don't think it's realistic to expect Mercurial to remain a generally useful tool for two more years, in particular given that there is no roadmap [2] to move Python 3 support in Mercurial out of experimental/beta status in the coming weeks. And that doesn't even consider extensions, since "3. Things need to be investigated" [..] " Nearly every extension will break in Python 3. " So ... yeah. cheers, dalibor topic [0] https://www.mercurial-scm.org/wiki/SupportedPythonVersions [1] https://pythonclock.org/ [2] https://www.mercurial-scm.org/wiki/Python3 -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From neugens at redhat.com Mon Nov 18 11:56:40 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 18 Nov 2019 12:56:40 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> Message-ID: On Mon, Nov 18, 2019 at 12:16 PM Dalibor Topic wrote: > > On 14.11.2019 15:55, Mario Torre wrote:> Right, however none of those > projects so far have real world, directly > > comparable, experiences to share. JMC for one is still running on > > mercurial and will only transition to GitHub for the 8.0 release > > train, which isn't yet even open. > > > > I think we really need to get back to this proposal in an year or two > > when we understand more of the implications. > > > > Considering that Mercurial requires [0] Python 2.7 and Python 2.7 has > six more weeks of life left [1], well ... I don't think it's realistic > to expect Mercurial to remain a generally useful tool for two more > years, in particular given that there is no roadmap [2] to move Python 3 > support in Mercurial out of experimental/beta status in the coming weeks. Well, the same page links to this: https://www.mercurial-scm.org/wiki/Python3 Nevertheless, the issue for me, once again, isn't much about Git, but about GitHub. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From dalibor.topic at oracle.com Mon Nov 18 12:31:45 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 18 Nov 2019 13:31:45 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> Message-ID: <7e6fc968-a20a-62e8-5ea9-e027e8c64ab9@oracle.com> On 18.11.2019 12:56, Mario Torre wrote: > On Mon, Nov 18, 2019 at 12:16 PM Dalibor Topic wrote: >> >> On 14.11.2019 15:55, Mario Torre wrote:> Right, however none of those >> projects so far have real world, directly >>> comparable, experiences to share. JMC for one is still running on >>> mercurial and will only transition to GitHub for the 8.0 release >>> train, which isn't yet even open. >>> >>> I think we really need to get back to this proposal in an year or two >>> when we understand more of the implications. >>> >> >> Considering that Mercurial requires [0] Python 2.7 and Python 2.7 has >> six more weeks of life left [1], well ... I don't think it's realistic >> to expect Mercurial to remain a generally useful tool for two more >> years, in particular given that there is no roadmap [2] to move Python 3 >> support in Mercurial out of experimental/beta status in the coming weeks. > > Well, the same page links to this: > > https://www.mercurial-scm.org/wiki/Python3 Yeah, that page says Mercurial support for Python 3 is beta/experimental, i.e. it's not really ready for those developers who don't use Mercurial to develop Mercurial themselves. ;) Some off-topic, background reading on the current status can be found at [0], a fascinating longer post about the self-justifications for mostly focusing on Python 2 over the past decade can be found in [1]. cheers, dalibor topic [0] https://lobste.rs/s/jvz8qz/why_is_migration_python_3_taking_so_long#c_wwzohi https://lobste.rs/s/3vkmm8/why_i_can_t_remove_python_2_from_my_systems#c_tscufo https://twitter.com/indygreg/status/1187069501424062464 [1] https://gregoryszorc.com/blog/2017/03/13/from-__past__-import-bytes_literals/ -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From franta-java at frantovo.cz Mon Nov 18 13:13:21 2019 From: franta-java at frantovo.cz (=?UTF-8?B?RnJhbnRpxaFlayBLdcSNZXJh?=) Date: Mon, 18 Nov 2019 14:13:21 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> Message-ID: <009ac625-c629-10ab-0261-0e9324461e1a@frantovo.cz> Dne 18. 11. 19 v 12:15 Dalibor Topic napsal(a): > " Nearly every extension will break in Python 3. " > > So ... yeah. AFAIK this applies to the third-party extensions. > Many 3rd party extensions have not yet been ported to work with > Python 3. Does OpenJDK use any such non-core/third-party extensions? Franta From dalibor.topic at oracle.com Mon Nov 18 13:17:56 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 18 Nov 2019 14:17:56 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <009ac625-c629-10ab-0261-0e9324461e1a@frantovo.cz> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> <009ac625-c629-10ab-0261-0e9324461e1a@frantovo.cz> Message-ID: On 18.11.2019 14:13, Franti?ek Ku?era wrote: > Dne 18. 11. 19 v 12:15 Dalibor Topic napsal(a): >> Many 3rd party extensions have not yet been ported to work with > Python 3. > Does OpenJDK use any such non-core/third-party extensions? Yes. See https://openjdk.java.net/projects/code-tools/ for some of them. cheers, dalibor topic -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From franta-java at frantovo.cz Mon Nov 18 14:37:47 2019 From: franta-java at frantovo.cz (=?UTF-8?B?RnJhbnRpxaFlayBLdcSNZXJh?=) Date: Mon, 18 Nov 2019 15:37:47 +0100 Subject: =?UTF-8?Q?Re=3a_New_candidate_JEP=3a_369=3a_Migrate_to_GitHub_?= =?UTF-8?Q?=e2=80=93_Mercurial_extensions_porting_to_Python_3?= In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> <009ac625-c629-10ab-0261-0e9324461e1a@frantovo.cz> Message-ID: <804a5b40-37bb-4481-48f5-e01c3ec8b5a2@frantovo.cz> Dne 18. 11. 19 v 14:17 Dalibor Topic napsal(a): > On 18.11.2019 14:13, Franti?ek Ku?era wrote: >> Dne 18. 11. 19 v 12:15 Dalibor Topic napsal(a): >>> Many 3rd party extensions have not yet been ported to work with > >>> Python 3. >> Does OpenJDK use any such non-core/third-party extensions? > > Yes. See https://openjdk.java.net/projects/code-tools/ for some of them. If I understand it correctly, there are two third-party extensions in use (defpath and trees) + one hook (jcheck). All developed by Oracle. Does Oracle have a plan for porting these Mercurial extensions to Python 3? What is the current status? n.b. Python 2 sunset was announced in 2008 (and in 2014 the sunset was postponed from 2015 to 2020) which is long ago before current discussions/JEPs. Franta From neugens.limasoftware at gmail.com Mon Nov 18 18:46:59 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 18 Nov 2019 19:46:59 +0100 Subject: =?UTF-8?Q?Re=3A_New_candidate_JEP=3A_369=3A_Migrate_to_GitHub_=E2=80=93_Me?= =?UTF-8?Q?rcurial_extensions_porting_to_Python_3?= In-Reply-To: <804a5b40-37bb-4481-48f5-e01c3ec8b5a2@frantovo.cz> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> <009ac625-c629-10ab-0261-0e9324461e1a@frantovo.cz> <804a5b40-37bb-4481-48f5-e01c3ec8b5a2@frantovo.cz> Message-ID: Afaik Trees is only used for JDK 8 (and perhaps 7 and 6?) at this point and was introduced to replace the forest extension, I'm not sure if it's worth spending resources to migrate this to python 3 given there's a script in the jdk sources that does most of the same. I've never used defpath so I'm not sure what it does. The hook is rather important, since it's used to check patches against their bug id and also for style issues, I believe the Skara group has that ported to the Git workflow already. Cheers, Mario Il giorno lun 18 nov 2019 alle ore 15:38 Franti?ek Ku?era ha scritto: > > Dne 18. 11. 19 v 14:17 Dalibor Topic napsal(a): > > On 18.11.2019 14:13, Franti?ek Ku?era wrote: > >> Dne 18. 11. 19 v 12:15 Dalibor Topic napsal(a): > >>> Many 3rd party extensions have not yet been ported to work with > > >>> Python 3. > >> Does OpenJDK use any such non-core/third-party extensions? > > > > Yes. See https://openjdk.java.net/projects/code-tools/ for some of them. > > If I understand it correctly, there are two third-party extensions in > use (defpath and trees) + one hook (jcheck). All developed by Oracle. > > Does Oracle have a plan for porting these Mercurial extensions to Python > 3? What is the current status? > > n.b. Python 2 sunset was announced in 2008 (and in 2014 the sunset was > postponed from 2015 to 2020) which is long ago before current > discussions/JEPs. > > Franta > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From dalibor.topic at oracle.com Tue Nov 19 09:35:19 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 19 Nov 2019 10:35:19 +0100 Subject: =?UTF-8?Q?Re=3a_New_candidate_JEP=3a_369=3a_Migrate_to_GitHub_?= =?UTF-8?Q?=e2=80=93_Mercurial_extensions_porting_to_Python_3?= In-Reply-To: <804a5b40-37bb-4481-48f5-e01c3ec8b5a2@frantovo.cz> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> <009ac625-c629-10ab-0261-0e9324461e1a@frantovo.cz> <804a5b40-37bb-4481-48f5-e01c3ec8b5a2@frantovo.cz> Message-ID: <083a166c-543d-455b-a64f-03c8fe7f3b13@oracle.com> On 18.11.2019 15:37, Franti?ek Ku?era wrote: > Dne 18. 11. 19 v 14:17 Dalibor Topic napsal(a): >> On 18.11.2019 14:13, Franti?ek Ku?era wrote: >>> Dne 18. 11. 19 v 12:15 Dalibor Topic napsal(a): >>>> Many 3rd party extensions have not yet been ported to work with > >>>> Python 3. >>> Does OpenJDK use any such non-core/third-party extensions? >> >> Yes. See https://openjdk.java.net/projects/code-tools/ for some of them. > > If I understand it correctly, there are two third-party extensions in > use (defpath and trees) + one hook (jcheck). All developed by Oracle. > > Does Oracle have a plan for porting these Mercurial extensions to Python > 3? What is the current status? They work on Mercurial on Python 2. Until Mercurial supports Python 3, porting them is rather moot, though, as extensions tend to have to interact fairly closely with Mercurial itself, so afaik you can't run Mercurial on Python 2 while running its extensions on Python 3. Of course, you're welcome to send in Python-3-porting patches for review on the corresponding code-tools mailing lists, in any case. > n.b. Python 2 sunset was announced in 2008 (and in 2014 the sunset was > postponed from 2015 to 2020) which is long ago before current > discussions/JEPs. Yes, as you can see from the blog post I linked earlier in the thread, the focus of Mercurial developers at the time was on supporting Python 2.4. For example, if you look at https://www.mercurial-scm.org/repo/hg/log?rev=py3&revcount=2000 you can observe that Mercurial developers only really started to work on Python 3 support after Python 2 sunset was postponed, with the majority of that work just happening in the last two years. cheers, dalibor topic -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue Nov 19 09:45:08 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 19 Nov 2019 10:45:08 +0100 Subject: =?UTF-8?Q?Re=3a_New_candidate_JEP=3a_369=3a_Migrate_to_GitHub_?= =?UTF-8?Q?=e2=80=93_Mercurial_extensions_porting_to_Python_3?= In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <1d9d45ea-9af5-eeb8-c82b-8d8b50fd1992@oracle.com> <009ac625-c629-10ab-0261-0e9324461e1a@frantovo.cz> <804a5b40-37bb-4481-48f5-e01c3ec8b5a2@frantovo.cz> Message-ID: <551759b9-4178-a60f-a2d9-a3d1ce3cacce@oracle.com> On 18.11.2019 19:46, Mario Torre wrote: > I've never used defpath so I'm not sure what it does. It lets you change default (push) paths and adjust your username accordingly, if it's different from your login name, for example. It's not strictly necessary, as you've observed, but it might be useful when dealing with multiple different repository paths. > The hook is > rather important, since it's used to check patches against their bug > id and also for style issues, I believe the Skara group has that > ported to the Git workflow already. Yes - please see https://github.com/openjdk/skara/tree/master/jcheck for details. cheers, dalibor topic -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From maurizio.cimadamore at oracle.com Tue Nov 19 21:27:56 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 19 Nov 2019 21:27:56 +0000 Subject: Result: New Group: IDE & Tooling Support In-Reply-To: <20191119110215.979670764@eggemoggin.niobe.net> References: <20191119110215.979670764@eggemoggin.niobe.net> Message-ID: <251f1429-1257-0507-3978-24dce3af54f1@oracle.com> Thanks Mark Maurizio On 19/11/2019 19:02, mark.reinhold at oracle.com wrote: > The Governing Board has voted to approve the creation of the > IDE & Tooling Support Group, with Maurizio Cimadamore as the > initial Lead [1]. > > Yes: 3 > No: 0 > Abstain: 0 > > According to the Bylaws definition of Simple Majority, this is > sufficient to approve the new Group and its initial Lead. > > - Mark > > > [1] https://mail.openjdk.java.net/pipermail/gb-discuss/2019-November/000348.html From adinn at redhat.com Thu Nov 21 11:18:35 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 21 Nov 2019 11:18:35 +0000 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <6243b540-60fc-8a3b-7c69-1ff4b18742be@redhat.com> Message-ID: <19fada66-28c6-4587-6174-e6d1cc2c6b76@redhat.com> Hi Erik, Thanks for pointing me at the Skara project and for explaining how you have extended the basic GitHub PR workflow to support important elements of our current process. The tooling does indeed appear to improve the usability and add back necessary operations to a great degree. I am very impressed with the efforts you have made. So, thank you (and others, Joe especially) for your efforts. I /am/ still concerned about two points. 1) It seem a GitHub account is required for anyone who wishes to actually commit a change. I use GitHub or another project so I have an account and (clearly) have no special scruples about relying on GitHub, at least no more so than much of the other communal infrastructure I am obliged -- perhaps, sometimes expediently -- to use. However, I can understand see that some people (even, perhaps, some reviewers) might have reasonable ethical concerns about having to rely on GitHub -- not just for all the tooling it provides but even for simply hosting the code. I am glad that you have offered a path for them still to contribute (ending in contribution via a proxy sponsor) and I hope that will be adequate for anyone with ethical concerns. 2) I am pleased to hear that you very much wish for it to remain possible to initiate and proceed with RFRs using the existing process of creating and publishing a webrev and then negotiating its progress via email only. Also, it is very welcome that that RFRs initiated by a GitHub PR will be automatically provided with an initial webrev at PR open and upated webrevs as new commits are pushed, so making it very easy 3rd parties (especially reviewers) to contribute in their usual way without having to proceed via GitHub. However, I am still not confident that the mixed use of PRs and email will work. I still fear that this mixed usage is not going to result in as coherent a dialogue (or, perhaps, polylogue might be a better term to use) as pure email although I accept your arguments about how it may well suit some people better than others. The other thing I still rank as problematic is an expectation that those who use the PR-based process are not going to be aware of or fully involved in any discussion that starts outside of GitHub. Once again, this is derived from my Graal project experience where mailing to the Graal list was very much like shouting into a void. Of course, I accept that this is not the Graal project and that you are trying very hard to ensure that we retain a workflow that Graal never had in the first place. So, I understand that this expectation may turn out to be misplaced. I am afraid I'd still prefer not to make what I see as a risky and unnecessary move. I accept that it's not possible to prove or disprove your or my expectations without actually making the move and seeing what happens. If we do go down this path then I'd much prefer to do it slowly and piecemeal, with time for assessment of its impact on the project. I believe that is also your intention so I'll leave my objections to rest here and listen to what others have to say on the matter. regards, Andrew Dinn ----------- On 14/11/2019 11:34, Erik Helin wrote: > On 11/13/19 6:39 PM, Andrew Dinn wrote: >> On 13/11/2019 11:42, Erik Helin wrote: >>> Thanks Andrew for reading through it all and providing feedback! Please >>> see my replies inline. >> >> You are very welcome. It definitely merits a considered and fair review. >> >>>> My experience of GitHub use in the Graal project suggest that this is >>>> not entirely the full picture. My view derived from that experience is >>>> that the GitHub PR is very much an inferior medium for review >>>> discussion. In particular, it definitely fails to be "structurally >>>> similar to the existing e-mail and webrev based workflows". >>> >>> I think the key sentence here is "My experience of GitHub use in the >>> Graal project...". Having worked with project on GitHub using Skara >>> tooling and projects on GitHub _not_ using Skara tooling, my view is >>> that the experiences differs quite a bit. >> >> I am happy to hear that you will be supplementing the standard GitHub >> experience with extra tooling. I also must apologize for not looking at >> Skara before writing a critique that perhaps does not do it justice. I >> will take a look and post my thoughts. >> >>> This does not paint the whole picture. You are probably thinking of the >>> "Conversation" tab in a GitHub pull request which is meant for *general* >>> discussion of the patch that is not attached to any particular change in >>> the patch. GitHub's own help documentation [0] states that the >>> "Conversation" tab is meant to be used for: >>> >>> ???? You can comment on a pull request's Conversation tab to leave >>> ???? general comments, questions, or props. >>> >>> You are right that comments in the "Conversation" tab are linearized and >>> does not support a "tree style" view of comments. >>> >>> The good news are that the _other_ form of comments available on a >>> GitHub pull request, a so-called "review comment" or "file comment" [1], >>> does support replies in the form of a tree. These comments are filed >>> under the "Files changed" tab in a pull request. >> >> I'm afraid that makes it sound worse not better. This bifurcates the >> review process into 'general comments' vs 'critique on the code per se', >> with the former forced into a? linear frame while the latter can benefit >> from divide and conquer distinctions. I fear that's an artificial >> division of concerns that will make it harder still to reconcile general >> points with the evidence base for deriving them. >> >>> Personally I think of the comments in the "Conversation" tab as replies >>> to the "00" email in a classic patch series email and the "review >>> comments" in the "Files changed" tab as replies to the "0X" emails >>> actually containing patches. Do you follow? >> >> Well, I agree that sometimes that will work ok. However, I may be wrong >> here but I believe that the code comments are tied to a specific point >> in the file/change set. That's ok when a comment only relates to one >> change. When you wish comment on the combined effect of two or more >> changes at different points in the file the requirement to attach a >> comment to one specific change doesn't really work. Punting such >> comments to the 00 thread doesn't do it either. Quoting the relevant >> lines in a follow-up note does bring the relevant changes into the scope >> of preceding and subsequent replies. >> >> The root point here is that the GitHub PR presentation model is going to >> impose constraints on the way we structure and link our review comments >> because it needs them to conform to it's information structure that is >> essentially driven by it's web page layout. email is inherently much >> more flexible because it is just a hierarchically linked set of texts. >> Of course, GitHub provides aids to simplify the task of creating and >> linking information in its format. Whereas with email one has to >> explicitly structure the information by editing it and placing it in a >> reply sequence. I can see GitHub making some things a lot easier. >> However, my concern is that it may well make some important things that >> we do difficult or maybe even impossible (at the least impractical). > > Yes, email is more free form (and thus more flexible) than essentially > any other medium. The interesting question to ponder here is if this > flexibility helps or hurts the majority of reviews being conducted in > OpenJDK on a daily basis? > > I think we all have experienced where the flexibility of mailing lists > and free-form emails have resulted in less than stellar experiences as > well: > - a thread gets forked to two different mailing lists because one > ? participant forgets to press "Reply all" and instead presses > ? "Reply List" > - a reviewer joins a "RFR" thread after the patch has been pushed since > ? there is no way see on a mailing list whether the patch has been > ? pushed or not > - a contributor forgets to mentions one more important facts in a RFR > ? email such as links to JBS issue(s), which commit the patch should > ? be applied upon or does not supply an incremental webrev > > Looking at the jdk/jdk repository [0] we see that over 95% of all > commits have 3 or less reviewers [1]. Manually skimming the last weeks > of emails on core-libs-dev and hotspot-dev seems (to me) to confirm > this: the majority of the conversations have 1 - 4 participants (one > author and up to three reviewers). Looking at the conversations it also > seems (again, to me) that a majority of them take place on a singe list > and do not move/transfer to other mailing lists. > > With the above in mind I do believe that flexibility and expressiveness > of pull requests combined with Skara's mailing list interoperability is > powerful enough. The experience from OpenJFX transitioning to GitHub + > Skara seem to confirm this, but this of course my interpretation based > on their feedback. > > Now, as I have pointed in some other replies, we do *not* lose the > mailing lists just because we migrate to GitHub + Skara. If you have a > really large patch where you are expecting 5+ reviewers spanning 3+ > mailing lists, then it is more than fine to send an RFC email with a > webrev, just like we do today. The patch will eventually have to become > one more pull requests and subject to the review process, but there is > nothing stopping you from using the mailing lists for the initial feedback. > >>> Now the interesting question is of course how the Skara tooling >>> translates these kinds of comments back-and-forth between mailing lists >>> and GitHub. Here I'm happy to report that the Skara tooling does proper >>> replying, which will cause the "review comments" created under the >>> "Files changed" tab on a pull request to result in a tree-view (in email >>> clients that support such views). >>> >>> You can see of some of this work on the openjfx-dev mailing list [2]. >>> Now keep in mind if you are looking at Pipermail rendering of a mailing >>> list, which lacks some features that most email clients supports (such >>> as folding quoted text and nested replies beyond three levels). A >>> mailing list version of a pull request will in general have the >>> following structure: >>> >>> - RFR: Fix a bug <-- Email describing patch >>> ?? - Re: RFR: Fix a bug <-- This is a general comment >>> ???? - Re: RFR: Fix a bug <-- This is a reply to the general comment >>> ?? - Re: [Rev 01]: RFR: Fix a bug <-- The author updated the patch >>> ???? - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer A on 01 >>> ?????? - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from A on 01 >>> ???? - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer B on 01 >>> ?????? - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from B on 01 >>> ?? - Re: [Rev 02]: RFR: Fix a bug <-- The author updated again >>> ?? - Re: [Approved] RFR: Fix a bug <-- Reviewer A approved the patch >>> ?? - Re: [Approved] RFR: Fix a bug <-- Reviewer B approved the patch >>> ?? - Re: [Integrated] RFR: Fix a bug <-- Author integrated the patch >>> >>> We are tweaking this structure as we get more and more experience with >>> it, but at the moment I'm fairly satisfied with threading and the tree >>> layout. If you have any feedback on this structure/layout, then we are >>> happy to hear it. >> >> Well, I will of course look into this further. Thanks you for pointing >> me at the relevant matter to consider. > > Thanks for digging into this, we are longing for feedback :) > >>> Going in the other direction, mailing list -> GitHub, we also try to >>> preserve the mailing list structure as much as possible. This is >>> actually a harder challenge, since an email is less structured compared >>> to a comment on GitHub. An example of this direction can be found in >>> pull request 231 for the Skara repository [3] where you can see the >>> thread (which is a tree) from skara-dev at openjdk.java.net [4] being >>> "flattened" and uses quotation to try to preserve the flow. >> >> Yes, of course. However, rather than express that as 'email is less >> structured' one might equally state it as 'email is much more flexible' >> or 'GitHub is much more rigid' ;-) > > :) Please see my reply above for my thoughts on this matter. > >>> Here we are currently working on the /cc command that can be used in a >>> comment on pull request, for example: >>> >>> ???? /cc build-dev hotspot-dev >> >> Thanks for clarifying > > No problem at all. > >>> I hope that is does not come across that we are taking mailing list >>> interopability as a minor detail? I think it is fair to say that this is >>> the Skara feature we have spent the most time working on and are >>> constantly improving in order to provide a good experience. >> >> No, I was not addressing that at you -- apologies if ti came across like >> that as I very much appreciate that you do take this seriously -- rather >> at all other OpenJDK project members to try to raise awareness of the >> importance of getting a change like this right. > > No feelings hurt, I just wanted to stress how deeply we care about this > matter. And for the record, yes, I'm well aware of the importance of > getting this change right. I have worked in this community for more than > 7 years now and have a deep respect for it and its members. > > Thanks, > Erik > > [0]: https://git.openjdk.java.net/jdk > [1]: https://gist.github.com/edvbld/a03dec6c84bad054d7529461a38efdf5 > >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill >> > From franta-java at frantovo.cz Thu Nov 21 17:59:03 2019 From: franta-java at frantovo.cz (=?UTF-8?B?RnJhbnRpxaFlayBLdcSNZXJh?=) Date: Thu, 21 Nov 2019 18:59:03 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <19fada66-28c6-4587-6174-e6d1cc2c6b76@redhat.com> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <6243b540-60fc-8a3b-7c69-1ff4b18742be@redhat.com> <19fada66-28c6-4587-6174-e6d1cc2c6b76@redhat.com> Message-ID: Dne 21. 11. 19 v 12:18 Andrew Dinn napsal(a): > I can understand see that some people (even, perhaps, some reviewers) > might have reasonable ethical concerns about having to rely on GitHub > -- not just for all the tooling it provides but even for simply > hosting the code. I am glad that you have offered a path for them > still to contribute (ending in contribution via a proxy sponsor) and > I hope that will be adequate for anyone with ethical concerns. Thanks for your comment. For me, it is much easier to publish my patch/branch on my own Mercurial or Git server (I have both) than read circa 26 pages of legal text and being bound by them (i.e. having a GitHub account). Franta From erik.helin at oracle.com Fri Nov 22 12:09:43 2019 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 22 Nov 2019 13:09:43 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <19fada66-28c6-4587-6174-e6d1cc2c6b76@redhat.com> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <6243b540-60fc-8a3b-7c69-1ff4b18742be@redhat.com> <19fada66-28c6-4587-6174-e6d1cc2c6b76@redhat.com> Message-ID: <228555d7-493c-64cb-a9bb-03d4ca23fea6@oracle.com> On 11/21/19 12:18 PM, Andrew Dinn wrote: > Hi Erik, Hi Andrew, On 11/21/19 12:18 PM, Andrew Dinn wrote: > Thanks for pointing me at the Skara project and for explaining how you > have extended the basic GitHub PR workflow to support important elements > of our current process. The tooling does indeed appear to improve the > usability and add back necessary operations to a great degree. I am very > impressed with the efforts you have made. So, thank you (and others, Joe > especially) for your efforts. I would also like to take this opportunity to thank you for your very insightful and thoughtful feedback. You have really taken the time to read through our work, dig into it and tried to see things from our perspective, something which I'm very thankful for. Getting this kind of feedback is a rare thing nowadays, so again, thank you Andrew. > I /am/ still concerned about two points. > > 1) It seem a GitHub account is required for anyone who wishes to > actually commit a change. I use GitHub or another project so I have an > account and (clearly) have no special scruples about relying on GitHub, > at least no more so than much of the other communal infrastructure I am > obliged -- perhaps, sometimes expediently -- to use. However, I can > understand see that some people (even, perhaps, some reviewers) might > have reasonable ethical concerns about having to rely on GitHub -- not > just for all the tooling it provides but even for simply hosting the > code. I am glad that you have offered a path for them still to > contribute (ending in contribution via a proxy sponsor) and I hope that > will be adequate for anyone with ethical concerns. That is our hope as well. So far we haven't gotten any indications that manual creation of pull requests for contributions coming in via the mailing lists won't be enough, but we have ideas on how to scale that process if necessary. One could for example imagine a bot that scans the mailing lists for initial RFR emails, extracts the cr.openjdk.java.net link to the webrev from the email body and automatically creates a pull request. This is similar in spirit to how the bots today find mailing list emails replying to comments on pull requests. > 2) I am pleased to hear that you very much wish for it to remain > possible to initiate and proceed with RFRs using the existing process of > creating and publishing a webrev and then negotiating its progress via > email only. Yes, the mailing lists are *not* going away. Just to be clear here: as I wrote in my last reply, the patches discussed in such an RFR email thread will eventually have to become one or more pull requests. However if all participants in such an RFR email thread agree that the patches are good, then those pull requests would just be a formality to integrate the changes. > Also, it is very welcome that that RFRs initiated by a > GitHub PR will be automatically provided with an initial webrev at PR > open and upated webrevs as new commits are pushed, so making it very > easy 3rd parties (especially reviewers) to contribute in their usual way > without having to proceed via GitHub. However, I am still not confident > that the mixed use of PRs and email will work. > > I still fear that this mixed usage is not going to result in as coherent > a dialogue (or, perhaps, polylogue might be a better term to use) as > pure email although I accept your arguments about how it may well suit > some people better than others. The other thing I still rank as > problematic is an expectation that those who use the PR-based process > are not going to be aware of or fully involved in any discussion that > starts outside of GitHub. Once again, this is derived from my Graal > project experience where mailing to the Graal list was very much like > shouting into a void. Of course, I accept that this is not the Graal > project and that you are trying very hard to ensure that we retain a > workflow that Graal never had in the first place. So, I understand that > this expectation may turn out to be misplaced. It would disappoint me if OpenJDK contributors would stop paying attention to the mailing lists. As I have stated elsewhere in my replies to others, the OpenJDK mailing lists are used for much more than RFR emails: - design discussions - call for votes - announcements - JEP discussions - occasional bug reports - etc. So, again, it is fully expected that frequent OpenJDK contributors follow the relevant mailing lists for the areas they contribute to. You can therefore reasonably expect that a frequent OpenJDK contributor is aware of discussions that have taken place solely on a relevant mailing list. (I say frequent here because I don't expect a person that in total contribute one or two patches to keep up with the mailing lists.) > I am afraid I'd still prefer not to make what I see as a risky and > unnecessary move. I accept that it's not possible to prove or disprove > your or my expectations without actually making the move and seeing what > happens. If we do go down this path then I'd much prefer to do it slowly > and piecemeal, with time for assessment of its impact on the project. I > believe that is also your intention so I'll leave my objections to rest > here and listen to what others have to say on the matter. I hope that we have shown by now that project Skara is not rushing things. The OpenJDK project Skara was announced July, 2018. Progress has since then been reported and discussed at three consecutive OpenJDK Committers Workshops (Santa Clara, Aug 2018; Brussels, Feb 2019; Santa Clara, Aug 2019). The source code powering Skara has been open source since June, 2019. We have let a few OpenJDK projects of different sizes and with different policies to trial GitHub + Skara and we are continuously improving things based on their feedback. This iterative strategy has proven to successful so far, so I don't see any reason to change it. As I've stated elsewhere in this thread, it has always been my intent to transition a few projects at a time and learn from their experiences _before_ the main JDK repository would be transitioned. Thanks, Erik > regards, > > > Andrew Dinn > ----------- > > On 14/11/2019 11:34, Erik Helin wrote: >> On 11/13/19 6:39 PM, Andrew Dinn wrote: >>> On 13/11/2019 11:42, Erik Helin wrote: >>>> Thanks Andrew for reading through it all and providing feedback! Please >>>> see my replies inline. >>> >>> You are very welcome. It definitely merits a considered and fair review. >>> >>>>> My experience of GitHub use in the Graal project suggest that this is >>>>> not entirely the full picture. My view derived from that experience is >>>>> that the GitHub PR is very much an inferior medium for review >>>>> discussion. In particular, it definitely fails to be "structurally >>>>> similar to the existing e-mail and webrev based workflows". >>>> >>>> I think the key sentence here is "My experience of GitHub use in the >>>> Graal project...". Having worked with project on GitHub using Skara >>>> tooling and projects on GitHub _not_ using Skara tooling, my view is >>>> that the experiences differs quite a bit. >>> >>> I am happy to hear that you will be supplementing the standard GitHub >>> experience with extra tooling. I also must apologize for not looking at >>> Skara before writing a critique that perhaps does not do it justice. I >>> will take a look and post my thoughts. >>> >>>> This does not paint the whole picture. You are probably thinking of the >>>> "Conversation" tab in a GitHub pull request which is meant for *general* >>>> discussion of the patch that is not attached to any particular change in >>>> the patch. GitHub's own help documentation [0] states that the >>>> "Conversation" tab is meant to be used for: >>>> >>>> ???? You can comment on a pull request's Conversation tab to leave >>>> ???? general comments, questions, or props. >>>> >>>> You are right that comments in the "Conversation" tab are linearized and >>>> does not support a "tree style" view of comments. >>>> >>>> The good news are that the _other_ form of comments available on a >>>> GitHub pull request, a so-called "review comment" or "file comment" [1], >>>> does support replies in the form of a tree. These comments are filed >>>> under the "Files changed" tab in a pull request. >>> >>> I'm afraid that makes it sound worse not better. This bifurcates the >>> review process into 'general comments' vs 'critique on the code per se', >>> with the former forced into a? linear frame while the latter can benefit >>> from divide and conquer distinctions. I fear that's an artificial >>> division of concerns that will make it harder still to reconcile general >>> points with the evidence base for deriving them. >>> >>>> Personally I think of the comments in the "Conversation" tab as replies >>>> to the "00" email in a classic patch series email and the "review >>>> comments" in the "Files changed" tab as replies to the "0X" emails >>>> actually containing patches. Do you follow? >>> >>> Well, I agree that sometimes that will work ok. However, I may be wrong >>> here but I believe that the code comments are tied to a specific point >>> in the file/change set. That's ok when a comment only relates to one >>> change. When you wish comment on the combined effect of two or more >>> changes at different points in the file the requirement to attach a >>> comment to one specific change doesn't really work. Punting such >>> comments to the 00 thread doesn't do it either. Quoting the relevant >>> lines in a follow-up note does bring the relevant changes into the scope >>> of preceding and subsequent replies. >>> >>> The root point here is that the GitHub PR presentation model is going to >>> impose constraints on the way we structure and link our review comments >>> because it needs them to conform to it's information structure that is >>> essentially driven by it's web page layout. email is inherently much >>> more flexible because it is just a hierarchically linked set of texts. >>> Of course, GitHub provides aids to simplify the task of creating and >>> linking information in its format. Whereas with email one has to >>> explicitly structure the information by editing it and placing it in a >>> reply sequence. I can see GitHub making some things a lot easier. >>> However, my concern is that it may well make some important things that >>> we do difficult or maybe even impossible (at the least impractical). >> >> Yes, email is more free form (and thus more flexible) than essentially >> any other medium. The interesting question to ponder here is if this >> flexibility helps or hurts the majority of reviews being conducted in >> OpenJDK on a daily basis? >> >> I think we all have experienced where the flexibility of mailing lists >> and free-form emails have resulted in less than stellar experiences as >> well: >> - a thread gets forked to two different mailing lists because one >> ? participant forgets to press "Reply all" and instead presses >> ? "Reply List" >> - a reviewer joins a "RFR" thread after the patch has been pushed since >> ? there is no way see on a mailing list whether the patch has been >> ? pushed or not >> - a contributor forgets to mentions one more important facts in a RFR >> ? email such as links to JBS issue(s), which commit the patch should >> ? be applied upon or does not supply an incremental webrev >> >> Looking at the jdk/jdk repository [0] we see that over 95% of all >> commits have 3 or less reviewers [1]. Manually skimming the last weeks >> of emails on core-libs-dev and hotspot-dev seems (to me) to confirm >> this: the majority of the conversations have 1 - 4 participants (one >> author and up to three reviewers). Looking at the conversations it also >> seems (again, to me) that a majority of them take place on a singe list >> and do not move/transfer to other mailing lists. >> >> With the above in mind I do believe that flexibility and expressiveness >> of pull requests combined with Skara's mailing list interoperability is >> powerful enough. The experience from OpenJFX transitioning to GitHub + >> Skara seem to confirm this, but this of course my interpretation based >> on their feedback. >> >> Now, as I have pointed in some other replies, we do *not* lose the >> mailing lists just because we migrate to GitHub + Skara. If you have a >> really large patch where you are expecting 5+ reviewers spanning 3+ >> mailing lists, then it is more than fine to send an RFC email with a >> webrev, just like we do today. The patch will eventually have to become >> one more pull requests and subject to the review process, but there is >> nothing stopping you from using the mailing lists for the initial feedback. >> >>>> Now the interesting question is of course how the Skara tooling >>>> translates these kinds of comments back-and-forth between mailing lists >>>> and GitHub. Here I'm happy to report that the Skara tooling does proper >>>> replying, which will cause the "review comments" created under the >>>> "Files changed" tab on a pull request to result in a tree-view (in email >>>> clients that support such views). >>>> >>>> You can see of some of this work on the openjfx-dev mailing list [2]. >>>> Now keep in mind if you are looking at Pipermail rendering of a mailing >>>> list, which lacks some features that most email clients supports (such >>>> as folding quoted text and nested replies beyond three levels). A >>>> mailing list version of a pull request will in general have the >>>> following structure: >>>> >>>> - RFR: Fix a bug <-- Email describing patch >>>> ?? - Re: RFR: Fix a bug <-- This is a general comment >>>> ???? - Re: RFR: Fix a bug <-- This is a reply to the general comment >>>> ?? - Re: [Rev 01]: RFR: Fix a bug <-- The author updated the patch >>>> ???? - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer A on 01 >>>> ?????? - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from A on 01 >>>> ???? - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer B on 01 >>>> ?????? - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from B on 01 >>>> ?? - Re: [Rev 02]: RFR: Fix a bug <-- The author updated again >>>> ?? - Re: [Approved] RFR: Fix a bug <-- Reviewer A approved the patch >>>> ?? - Re: [Approved] RFR: Fix a bug <-- Reviewer B approved the patch >>>> ?? - Re: [Integrated] RFR: Fix a bug <-- Author integrated the patch >>>> >>>> We are tweaking this structure as we get more and more experience with >>>> it, but at the moment I'm fairly satisfied with threading and the tree >>>> layout. If you have any feedback on this structure/layout, then we are >>>> happy to hear it. >>> >>> Well, I will of course look into this further. Thanks you for pointing >>> me at the relevant matter to consider. >> >> Thanks for digging into this, we are longing for feedback :) >> >>>> Going in the other direction, mailing list -> GitHub, we also try to >>>> preserve the mailing list structure as much as possible. This is >>>> actually a harder challenge, since an email is less structured compared >>>> to a comment on GitHub. An example of this direction can be found in >>>> pull request 231 for the Skara repository [3] where you can see the >>>> thread (which is a tree) from skara-dev at openjdk.java.net [4] being >>>> "flattened" and uses quotation to try to preserve the flow. >>> >>> Yes, of course. However, rather than express that as 'email is less >>> structured' one might equally state it as 'email is much more flexible' >>> or 'GitHub is much more rigid' ;-) >> >> :) Please see my reply above for my thoughts on this matter. >> >>>> Here we are currently working on the /cc command that can be used in a >>>> comment on pull request, for example: >>>> >>>> ???? /cc build-dev hotspot-dev >>> >>> Thanks for clarifying >> >> No problem at all. >> >>>> I hope that is does not come across that we are taking mailing list >>>> interopability as a minor detail? I think it is fair to say that this is >>>> the Skara feature we have spent the most time working on and are >>>> constantly improving in order to provide a good experience. >>> >>> No, I was not addressing that at you -- apologies if ti came across like >>> that as I very much appreciate that you do take this seriously -- rather >>> at all other OpenJDK project members to try to raise awareness of the >>> importance of getting a change like this right. >> >> No feelings hurt, I just wanted to stress how deeply we care about this >> matter. And for the record, yes, I'm well aware of the importance of >> getting this change right. I have worked in this community for more than >> 7 years now and have a deep respect for it and its members. >> >> Thanks, >> Erik >> >> [0]: https://git.openjdk.java.net/jdk >> [1]: https://gist.github.com/edvbld/a03dec6c84bad054d7529461a38efdf5 >> >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> Senior Principal Software Engineer >>> Red Hat UK Ltd >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham, Michael ("Mike") O'Neill >>> >> > From neugens at redhat.com Fri Nov 22 13:05:12 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 22 Nov 2019 14:05:12 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <228555d7-493c-64cb-a9bb-03d4ca23fea6@oracle.com> References: <20191112160000.9698430DBF0@eggemoggin.niobe.net> <47b91c65-6603-8ad2-bdf2-644c314d3eb0@redhat.com> <6243b540-60fc-8a3b-7c69-1ff4b18742be@redhat.com> <19fada66-28c6-4587-6174-e6d1cc2c6b76@redhat.com> <228555d7-493c-64cb-a9bb-03d4ca23fea6@oracle.com> Message-ID: Hi Erik, I second Andrew's sentiment. While I still have a *very* large share of doubts, you and the project Skara folks have done a really awesome job in hiding most of the worse of the GitHub experience. I was reading a PR last day and although I still somehow need to get used to the email format at least the email thread was spot on directly on the review. When I visited the GitHub interface, I was flooded by nonsense about missing OCA and various automated replies that hide the actual review. Of course, I know those happen on the mailing list too, and also it's generally less likely to have new contributions that cause this extra data to be visible, but in the normal email exchange those administrative messages tend to be relegated in their own thread that is easy to skip, on GitHub there doesn't seem to be any way to hide them. This is one example only, and like I said, I still have my share of doubts and need my time to understand all the implications, but definitely the project Skara tooling helps bringing back some of the old rational and clean workflow rather than the Github nonsense ;) Cheers, Mario Cheers, Mario On Fri, Nov 22, 2019 at 1:10 PM Erik Helin wrote: > > On 11/21/19 12:18 PM, Andrew Dinn wrote: > > Hi Erik, > > Hi Andrew, > > On 11/21/19 12:18 PM, Andrew Dinn wrote: > > Thanks for pointing me at the Skara project and for explaining how you > > have extended the basic GitHub PR workflow to support important elements > > of our current process. The tooling does indeed appear to improve the > > usability and add back necessary operations to a great degree. I am very > > impressed with the efforts you have made. So, thank you (and others, Joe > > especially) for your efforts. > > I would also like to take this opportunity to thank you for your very > insightful and thoughtful feedback. You have really taken the time to > read through our work, dig into it and tried to see things from our > perspective, something which I'm very thankful for. Getting this kind of > feedback is a rare thing nowadays, so again, thank you Andrew. > > > I /am/ still concerned about two points. > > > > 1) It seem a GitHub account is required for anyone who wishes to > > actually commit a change. I use GitHub or another project so I have an > > account and (clearly) have no special scruples about relying on GitHub, > > at least no more so than much of the other communal infrastructure I am > > obliged -- perhaps, sometimes expediently -- to use. However, I can > > understand see that some people (even, perhaps, some reviewers) might > > have reasonable ethical concerns about having to rely on GitHub -- not > > just for all the tooling it provides but even for simply hosting the > > code. I am glad that you have offered a path for them still to > > contribute (ending in contribution via a proxy sponsor) and I hope that > > will be adequate for anyone with ethical concerns. > > That is our hope as well. > > So far we haven't gotten any indications that manual creation of pull > requests for contributions coming in via the mailing lists won't be > enough, but we have ideas on how to scale that process if necessary. One > could for example imagine a bot that scans the mailing lists for initial > RFR emails, extracts the cr.openjdk.java.net link to the webrev from the > email body and automatically creates a pull request. This is similar in > spirit to how the bots today find mailing list emails replying to > comments on pull requests. > > > 2) I am pleased to hear that you very much wish for it to remain > > possible to initiate and proceed with RFRs using the existing process of > > creating and publishing a webrev and then negotiating its progress via > > email only. > > Yes, the mailing lists are *not* going away. Just to be clear here: as I > wrote in my last reply, the patches discussed in such an RFR email > thread will eventually have to become one or more pull requests. However > if all participants in such an RFR email thread agree that the patches > are good, then those pull requests would just be a formality to > integrate the changes. > > > Also, it is very welcome that that RFRs initiated by a > > GitHub PR will be automatically provided with an initial webrev at PR > > open and upated webrevs as new commits are pushed, so making it very > > easy 3rd parties (especially reviewers) to contribute in their usual way > > without having to proceed via GitHub. However, I am still not confident > > that the mixed use of PRs and email will work. > > > > I still fear that this mixed usage is not going to result in as coherent > > a dialogue (or, perhaps, polylogue might be a better term to use) as > > pure email although I accept your arguments about how it may well suit > > some people better than others. The other thing I still rank as > > problematic is an expectation that those who use the PR-based process > > are not going to be aware of or fully involved in any discussion that > > starts outside of GitHub. Once again, this is derived from my Graal > > project experience where mailing to the Graal list was very much like > > shouting into a void. Of course, I accept that this is not the Graal > > project and that you are trying very hard to ensure that we retain a > > workflow that Graal never had in the first place. So, I understand that > > this expectation may turn out to be misplaced. > > It would disappoint me if OpenJDK contributors would stop paying > attention to the mailing lists. As I have stated elsewhere in my replies > to others, the OpenJDK mailing lists are used for much more than RFR emails: > - design discussions > - call for votes > - announcements > - JEP discussions > - occasional bug reports > - etc. > > So, again, it is fully expected that frequent OpenJDK contributors > follow the relevant mailing lists for the areas they contribute to. You > can therefore reasonably expect that a frequent OpenJDK contributor is > aware of discussions that have taken place solely on a relevant mailing > list. > > (I say frequent here because I don't expect a person that in total > contribute one or two patches to keep up with the mailing lists.) > > > I am afraid I'd still prefer not to make what I see as a risky and > > unnecessary move. I accept that it's not possible to prove or disprove > > your or my expectations without actually making the move and seeing what > > happens. If we do go down this path then I'd much prefer to do it slowly > > and piecemeal, with time for assessment of its impact on the project. I > > believe that is also your intention so I'll leave my objections to rest > > here and listen to what others have to say on the matter. > > I hope that we have shown by now that project Skara is not rushing > things. The OpenJDK project Skara was announced July, 2018. Progress has > since then been reported and discussed at three consecutive OpenJDK > Committers Workshops (Santa Clara, Aug 2018; Brussels, Feb 2019; Santa > Clara, Aug 2019). The source code powering Skara has been open source > since June, 2019. We have let a few OpenJDK projects of different sizes > and with different policies to trial GitHub + Skara and we are > continuously improving things based on their feedback. > > This iterative strategy has proven to successful so far, so I don't see > any reason to change it. As I've stated elsewhere in this thread, it has > always been my intent to transition a few projects at a time and learn > from their experiences _before_ the main JDK repository would be > transitioned. > > Thanks, > Erik > > > regards, > > > > > > Andrew Dinn > > ----------- > > > > On 14/11/2019 11:34, Erik Helin wrote: > >> On 11/13/19 6:39 PM, Andrew Dinn wrote: > >>> On 13/11/2019 11:42, Erik Helin wrote: > >>>> Thanks Andrew for reading through it all and providing feedback! Please > >>>> see my replies inline. > >>> > >>> You are very welcome. It definitely merits a considered and fair review. > >>> > >>>>> My experience of GitHub use in the Graal project suggest that this is > >>>>> not entirely the full picture. My view derived from that experience is > >>>>> that the GitHub PR is very much an inferior medium for review > >>>>> discussion. In particular, it definitely fails to be "structurally > >>>>> similar to the existing e-mail and webrev based workflows". > >>>> > >>>> I think the key sentence here is "My experience of GitHub use in the > >>>> Graal project...". Having worked with project on GitHub using Skara > >>>> tooling and projects on GitHub _not_ using Skara tooling, my view is > >>>> that the experiences differs quite a bit. > >>> > >>> I am happy to hear that you will be supplementing the standard GitHub > >>> experience with extra tooling. I also must apologize for not looking at > >>> Skara before writing a critique that perhaps does not do it justice. I > >>> will take a look and post my thoughts. > >>> > >>>> This does not paint the whole picture. You are probably thinking of the > >>>> "Conversation" tab in a GitHub pull request which is meant for *general* > >>>> discussion of the patch that is not attached to any particular change in > >>>> the patch. GitHub's own help documentation [0] states that the > >>>> "Conversation" tab is meant to be used for: > >>>> > >>>> You can comment on a pull request's Conversation tab to leave > >>>> general comments, questions, or props. > >>>> > >>>> You are right that comments in the "Conversation" tab are linearized and > >>>> does not support a "tree style" view of comments. > >>>> > >>>> The good news are that the _other_ form of comments available on a > >>>> GitHub pull request, a so-called "review comment" or "file comment" [1], > >>>> does support replies in the form of a tree. These comments are filed > >>>> under the "Files changed" tab in a pull request. > >>> > >>> I'm afraid that makes it sound worse not better. This bifurcates the > >>> review process into 'general comments' vs 'critique on the code per se', > >>> with the former forced into a linear frame while the latter can benefit > >>> from divide and conquer distinctions. I fear that's an artificial > >>> division of concerns that will make it harder still to reconcile general > >>> points with the evidence base for deriving them. > >>> > >>>> Personally I think of the comments in the "Conversation" tab as replies > >>>> to the "00" email in a classic patch series email and the "review > >>>> comments" in the "Files changed" tab as replies to the "0X" emails > >>>> actually containing patches. Do you follow? > >>> > >>> Well, I agree that sometimes that will work ok. However, I may be wrong > >>> here but I believe that the code comments are tied to a specific point > >>> in the file/change set. That's ok when a comment only relates to one > >>> change. When you wish comment on the combined effect of two or more > >>> changes at different points in the file the requirement to attach a > >>> comment to one specific change doesn't really work. Punting such > >>> comments to the 00 thread doesn't do it either. Quoting the relevant > >>> lines in a follow-up note does bring the relevant changes into the scope > >>> of preceding and subsequent replies. > >>> > >>> The root point here is that the GitHub PR presentation model is going to > >>> impose constraints on the way we structure and link our review comments > >>> because it needs them to conform to it's information structure that is > >>> essentially driven by it's web page layout. email is inherently much > >>> more flexible because it is just a hierarchically linked set of texts. > >>> Of course, GitHub provides aids to simplify the task of creating and > >>> linking information in its format. Whereas with email one has to > >>> explicitly structure the information by editing it and placing it in a > >>> reply sequence. I can see GitHub making some things a lot easier. > >>> However, my concern is that it may well make some important things that > >>> we do difficult or maybe even impossible (at the least impractical). > >> > >> Yes, email is more free form (and thus more flexible) than essentially > >> any other medium. The interesting question to ponder here is if this > >> flexibility helps or hurts the majority of reviews being conducted in > >> OpenJDK on a daily basis? > >> > >> I think we all have experienced where the flexibility of mailing lists > >> and free-form emails have resulted in less than stellar experiences as > >> well: > >> - a thread gets forked to two different mailing lists because one > >> participant forgets to press "Reply all" and instead presses > >> "Reply List" > >> - a reviewer joins a "RFR" thread after the patch has been pushed since > >> there is no way see on a mailing list whether the patch has been > >> pushed or not > >> - a contributor forgets to mentions one more important facts in a RFR > >> email such as links to JBS issue(s), which commit the patch should > >> be applied upon or does not supply an incremental webrev > >> > >> Looking at the jdk/jdk repository [0] we see that over 95% of all > >> commits have 3 or less reviewers [1]. Manually skimming the last weeks > >> of emails on core-libs-dev and hotspot-dev seems (to me) to confirm > >> this: the majority of the conversations have 1 - 4 participants (one > >> author and up to three reviewers). Looking at the conversations it also > >> seems (again, to me) that a majority of them take place on a singe list > >> and do not move/transfer to other mailing lists. > >> > >> With the above in mind I do believe that flexibility and expressiveness > >> of pull requests combined with Skara's mailing list interoperability is > >> powerful enough. The experience from OpenJFX transitioning to GitHub + > >> Skara seem to confirm this, but this of course my interpretation based > >> on their feedback. > >> > >> Now, as I have pointed in some other replies, we do *not* lose the > >> mailing lists just because we migrate to GitHub + Skara. If you have a > >> really large patch where you are expecting 5+ reviewers spanning 3+ > >> mailing lists, then it is more than fine to send an RFC email with a > >> webrev, just like we do today. The patch will eventually have to become > >> one more pull requests and subject to the review process, but there is > >> nothing stopping you from using the mailing lists for the initial feedback. > >> > >>>> Now the interesting question is of course how the Skara tooling > >>>> translates these kinds of comments back-and-forth between mailing lists > >>>> and GitHub. Here I'm happy to report that the Skara tooling does proper > >>>> replying, which will cause the "review comments" created under the > >>>> "Files changed" tab on a pull request to result in a tree-view (in email > >>>> clients that support such views). > >>>> > >>>> You can see of some of this work on the openjfx-dev mailing list [2]. > >>>> Now keep in mind if you are looking at Pipermail rendering of a mailing > >>>> list, which lacks some features that most email clients supports (such > >>>> as folding quoted text and nested replies beyond three levels). A > >>>> mailing list version of a pull request will in general have the > >>>> following structure: > >>>> > >>>> - RFR: Fix a bug <-- Email describing patch > >>>> - Re: RFR: Fix a bug <-- This is a general comment > >>>> - Re: RFR: Fix a bug <-- This is a reply to the general comment > >>>> - Re: [Rev 01]: RFR: Fix a bug <-- The author updated the patch > >>>> - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer A on 01 > >>>> - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from A on 01 > >>>> - Re: [Rev 01]: RFR: Fix a bug <-- comment from reviewer B on 01 > >>>> - Re: [Rev 01]: RFR: Fix a bug <-- reply to comment from B on 01 > >>>> - Re: [Rev 02]: RFR: Fix a bug <-- The author updated again > >>>> - Re: [Approved] RFR: Fix a bug <-- Reviewer A approved the patch > >>>> - Re: [Approved] RFR: Fix a bug <-- Reviewer B approved the patch > >>>> - Re: [Integrated] RFR: Fix a bug <-- Author integrated the patch > >>>> > >>>> We are tweaking this structure as we get more and more experience with > >>>> it, but at the moment I'm fairly satisfied with threading and the tree > >>>> layout. If you have any feedback on this structure/layout, then we are > >>>> happy to hear it. > >>> > >>> Well, I will of course look into this further. Thanks you for pointing > >>> me at the relevant matter to consider. > >> > >> Thanks for digging into this, we are longing for feedback :) > >> > >>>> Going in the other direction, mailing list -> GitHub, we also try to > >>>> preserve the mailing list structure as much as possible. This is > >>>> actually a harder challenge, since an email is less structured compared > >>>> to a comment on GitHub. An example of this direction can be found in > >>>> pull request 231 for the Skara repository [3] where you can see the > >>>> thread (which is a tree) from skara-dev at openjdk.java.net [4] being > >>>> "flattened" and uses quotation to try to preserve the flow. > >>> > >>> Yes, of course. However, rather than express that as 'email is less > >>> structured' one might equally state it as 'email is much more flexible' > >>> or 'GitHub is much more rigid' ;-) > >> > >> :) Please see my reply above for my thoughts on this matter. > >> > >>>> Here we are currently working on the /cc command that can be used in a > >>>> comment on pull request, for example: > >>>> > >>>> /cc build-dev hotspot-dev > >>> > >>> Thanks for clarifying > >> > >> No problem at all. > >> > >>>> I hope that is does not come across that we are taking mailing list > >>>> interopability as a minor detail? I think it is fair to say that this is > >>>> the Skara feature we have spent the most time working on and are > >>>> constantly improving in order to provide a good experience. > >>> > >>> No, I was not addressing that at you -- apologies if ti came across like > >>> that as I very much appreciate that you do take this seriously -- rather > >>> at all other OpenJDK project members to try to raise awareness of the > >>> importance of getting a change like this right. > >> > >> No feelings hurt, I just wanted to stress how deeply we care about this > >> matter. And for the record, yes, I'm well aware of the importance of > >> getting this change right. I have worked in this community for more than > >> 7 years now and have a deep respect for it and its members. > >> > >> Thanks, > >> Erik > >> > >> [0]: https://git.openjdk.java.net/jdk > >> [1]: https://gist.github.com/edvbld/a03dec6c84bad054d7529461a38efdf5 > >> > >>> regards, > >>> > >>> > >>> Andrew Dinn > >>> ----------- > >>> Senior Principal Software Engineer > >>> Red Hat UK Ltd > >>> Registered in England and Wales under Company Registration No. 03798903 > >>> Directors: Michael Cunningham, Michael ("Mike") O'Neill > >>> > >> > > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Fri Nov 22 13:20:42 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 22 Nov 2019 14:20:42 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <41c038e4-95d2-e2f7-785b-c9ace749cc7b@oracle.com> References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> <3619dd09-ab39-e183-6eb7-c86a717d2ce5@oracle.com> <41c038e4-95d2-e2f7-785b-c9ace749cc7b@oracle.com> Message-ID: What happens if I'm a committer then? Can I simply skip the github interface, the required public fork and instead just clone locally, do my work and commit? I.E. a workflow like this: file bug git clone directly-upstream-openjdk do some work && create webrev && send email request && get approval git push Or will I be forced to use the public fork and send PRs? Cheers, Mario On Sat, Nov 16, 2019 at 12:35 AM Kevin Rushforth wrote: > > No, that isn't quite right. A contributor who has the role of Committer > is the one who initiates the commit, either via the GitHub UI, by > entering the "/integrate" command, or via the Skara tooling, by running > "git pr integrate". > > If a project is set up to require reviewers, then there must be at least > one approved review by someone with a Reviewer role in the project must > approve it, but it is the Committer who integrates it after the review > is done, and after all other requirements are satisfied (e.g., many > groups require a second reviewer, API changes require a CSR, etc). > > A contributor who is not a Committer, needs to have a sponsoring > Committer "/sponsor" their change after they issue the "/integrate" > command to indicate that they are ready for it to be pushed. > > In both cases, it is the Committer who initiates the push. > > -- Kevin > > > On 11/15/2019 3:22 PM, Mario Torre wrote: > > Hi Joe, > > > > Thanks for sharing this. > > > > On question still remains however, with the move to a pull request model we > > effectively give up the role of a committer (even if we maintain it to > > respect the bylaw it would be an empty role), this is because the reviewer > > or maintainer that approves the change request of effectively committing > > and the original author of the patch may have any of the roles from a > > simple contributor to a reviewer. > > > > Is that true or how else would we be dealing with contributions? > > > > Cheers, > > Mario > > > > On Fri 15. Nov 2019 at 23:39, Joe Darcy wrote: > > > >> On 11/15/2019 2:22 PM, Mario Torre wrote: > >> > >> One can argue that git is onerous the same way, the thing is that you are > >> not used to mercurial so it appears difficult for you. For this reason I > >> may say I won?t contribute a line of code if we switch to git but the > >> reality is that if I want or need for some reason I find my way. After all > >> we started with Classpath, that was cvs... > >> > >> All that said, this JEP is only incidentally about git, it?s about GitHub, > >> and we shouldn?t confuse the two things. > >> > >> At the end of the day everyone will still have to go through the governance > >> model so it can?t happen that we accept random contributions anymore than > >> now, unless this JEP is also about changing the bylaw and giving away with > >> the current role system. > >> > >> The governance model implications are explicitly mentioned in the JEP in > >> the goals section: > >> > >> > >> - Do not change the OpenJDK Bylaws . > >> - Do not change the OpenJDK Census . > >> > >> I attended an OpenJDK governing board meeting this October to discuss > >> Skara: > >> > >> https://openjdk.java.net/groups/gb/minutes/2019-10-10 > >> > >> The slides I presented explicitly quote from the current bylaws: > >> > >> Section 6 of the OpenJDK Bylaws: "A Project may have web content, one or > >> more code repositories, and one or more mailing lists. Projects are > >> expected to operate in an open, transparent, and meritocratic manner. Their > >> alignment with these principles will be monitored by the Governing Board." > >> > >> Appendix A of the OpenJDK Bylaws: "The data stored in any infrastructure > >> provided for use by Community members must be made available by some means > >> that enables, without undue effort, the construction of a complete > >> functional clone of that infrastructure and its data as seen by the entire > >> Community." > >> > >> No one present at the meeting disagreed with the assessment that the > >> bylaws would *not* need to be updated to use a hosting provider for the > >> JDK's sources. > >> > >> > >> -Joe > >> > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From kevin.rushforth at oracle.com Fri Nov 22 14:44:51 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 22 Nov 2019 06:44:51 -0800 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> <3619dd09-ab39-e183-6eb7-c86a717d2ce5@oracle.com> <41c038e4-95d2-e2f7-785b-c9ace749cc7b@oracle.com> Message-ID: <81823fae-fce0-70de-a74b-dfcbd778861f@oracle.com> You will need a personal fork of the repo, and you need to submit a pull request, but you can do that without ever visiting the GitHub web UI, using only the Skara command line tools, if you like. Workflow could be: file bug create a branch in your personal fork push fix to your branch of your fork git pr create ... git pr integrate -- Kevin On 11/22/2019 5:20 AM, Mario Torre wrote: > What happens if I'm a committer then? Can I simply skip the github > interface, the required public fork and instead just clone locally, do > my work and commit? > > I.E. a workflow like this: > > file bug > git clone directly-upstream-openjdk > do some work && create webrev && send email request && get approval > git push > > Or will I be forced to use the public fork and send PRs? > > Cheers, > Mario > > On Sat, Nov 16, 2019 at 12:35 AM Kevin Rushforth > wrote: >> No, that isn't quite right. A contributor who has the role of Committer >> is the one who initiates the commit, either via the GitHub UI, by >> entering the "/integrate" command, or via the Skara tooling, by running >> "git pr integrate". >> >> If a project is set up to require reviewers, then there must be at least >> one approved review by someone with a Reviewer role in the project must >> approve it, but it is the Committer who integrates it after the review >> is done, and after all other requirements are satisfied (e.g., many >> groups require a second reviewer, API changes require a CSR, etc). >> >> A contributor who is not a Committer, needs to have a sponsoring >> Committer "/sponsor" their change after they issue the "/integrate" >> command to indicate that they are ready for it to be pushed. >> >> In both cases, it is the Committer who initiates the push. >> >> -- Kevin >> >> >> On 11/15/2019 3:22 PM, Mario Torre wrote: >>> Hi Joe, >>> >>> Thanks for sharing this. >>> >>> On question still remains however, with the move to a pull request model we >>> effectively give up the role of a committer (even if we maintain it to >>> respect the bylaw it would be an empty role), this is because the reviewer >>> or maintainer that approves the change request of effectively committing >>> and the original author of the patch may have any of the roles from a >>> simple contributor to a reviewer. >>> >>> Is that true or how else would we be dealing with contributions? >>> >>> Cheers, >>> Mario >>> >>> On Fri 15. Nov 2019 at 23:39, Joe Darcy wrote: >>> >>>> On 11/15/2019 2:22 PM, Mario Torre wrote: >>>> >>>> One can argue that git is onerous the same way, the thing is that you are >>>> not used to mercurial so it appears difficult for you. For this reason I >>>> may say I won?t contribute a line of code if we switch to git but the >>>> reality is that if I want or need for some reason I find my way. After all >>>> we started with Classpath, that was cvs... >>>> >>>> All that said, this JEP is only incidentally about git, it?s about GitHub, >>>> and we shouldn?t confuse the two things. >>>> >>>> At the end of the day everyone will still have to go through the governance >>>> model so it can?t happen that we accept random contributions anymore than >>>> now, unless this JEP is also about changing the bylaw and giving away with >>>> the current role system. >>>> >>>> The governance model implications are explicitly mentioned in the JEP in >>>> the goals section: >>>> >>>> >>>> - Do not change the OpenJDK Bylaws . >>>> - Do not change the OpenJDK Census . >>>> >>>> I attended an OpenJDK governing board meeting this October to discuss >>>> Skara: >>>> >>>> https://openjdk.java.net/groups/gb/minutes/2019-10-10 >>>> >>>> The slides I presented explicitly quote from the current bylaws: >>>> >>>> Section 6 of the OpenJDK Bylaws: "A Project may have web content, one or >>>> more code repositories, and one or more mailing lists. Projects are >>>> expected to operate in an open, transparent, and meritocratic manner. Their >>>> alignment with these principles will be monitored by the Governing Board." >>>> >>>> Appendix A of the OpenJDK Bylaws: "The data stored in any infrastructure >>>> provided for use by Community members must be made available by some means >>>> that enables, without undue effort, the construction of a complete >>>> functional clone of that infrastructure and its data as seen by the entire >>>> Community." >>>> >>>> No one present at the meeting disagreed with the assessment that the >>>> bylaws would *not* need to be updated to use a hosting provider for the >>>> JDK's sources. >>>> >>>> >>>> -Joe >>>> > From neugens at redhat.com Fri Nov 22 15:00:59 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 22 Nov 2019 16:00:59 +0100 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <81823fae-fce0-70de-a74b-dfcbd778861f@oracle.com> References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> <3619dd09-ab39-e183-6eb7-c86a717d2ce5@oracle.com> <41c038e4-95d2-e2f7-785b-c9ace749cc7b@oracle.com> <81823fae-fce0-70de-a74b-dfcbd778861f@oracle.com> Message-ID: On Fri, Nov 22, 2019 at 3:45 PM Kevin Rushforth wrote: > > You will need a personal fork of the repo, and you need to submit a pull > request, but you can do that without ever visiting the GitHub web UI, > using only the Skara command line tools, if you like. > > Workflow could be: > > file bug > create a branch in your personal fork > push fix to your branch of your fork > git pr create ... > > git pr integrate > Maybe I'm really misunderstanding, but this means that if I'm working on 5 backports concurrently, I need to have 5 public branches where to push my fixes before I can integrate them into the main repository... This is going to be interesting. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From kevin.rushforth at oracle.com Fri Nov 22 16:08:19 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 22 Nov 2019 08:08:19 -0800 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> <3619dd09-ab39-e183-6eb7-c86a717d2ce5@oracle.com> <41c038e4-95d2-e2f7-785b-c9ace749cc7b@oracle.com> <81823fae-fce0-70de-a74b-dfcbd778861f@oracle.com> Message-ID: On 11/22/2019 7:00 AM, Mario Torre wrote: > On Fri, Nov 22, 2019 at 3:45 PM Kevin Rushforth > wrote: >> You will need a personal fork of the repo, and you need to submit a pull >> request, but you can do that without ever visiting the GitHub web UI, >> using only the Skara command line tools, if you like. >> >> Workflow could be: >> >> file bug >> create a branch in your personal fork >> push fix to your branch of your fork >> git pr create ... >> >> git pr integrate >> > Maybe I'm really misunderstanding, but this means that if I'm working > on 5 backports concurrently, I need to have 5 public branches where to > push my fixes before I can integrate them into the main repository... Yes, but it's 5 branches in your single public repository. A branch is cheap. -- Kevin From eric.vergnaud at wanadoo.fr Sun Nov 24 02:53:50 2019 From: eric.vergnaud at wanadoo.fr (Eric Vergnaud) Date: Sun, 24 Nov 2019 10:53:50 +0800 Subject: New candidate JEP: 369: Migrate to GitHub In-Reply-To: <81823fae-fce0-70de-a74b-dfcbd778861f@oracle.com> References: <33F69983-EE39-440C-ABE7-306FC8C31D49@wanadoo.fr> <3619dd09-ab39-e183-6eb7-c86a717d2ce5@oracle.com> <41c038e4-95d2-e2f7-785b-c9ace749cc7b@oracle.com> <81823fae-fce0-70de-a74b-dfcbd778861f@oracle.com> Message-ID: <8F792174-3782-4533-AAD0-34CAAB0D7BDE@wanadoo.fr> Not advertising anything, there are all sorts of tools out there, to suit your personal taste. I personally use Source Tree, so I only rarely visit GitHub, and almost never use cmd line git. > Le 22 nov. 2019 ? 22:44, Kevin Rushforth a ?crit : > > You will need a personal fork of the repo, and you need to submit a pull request, but you can do that without ever visiting the GitHub web UI, using only the Skara command line tools, if you like. > > Workflow could be: > > file bug > create a branch in your personal fork > push fix to your branch of your fork > git pr create ... > > git pr integrate > > -- Kevin > > On 11/22/2019 5:20 AM, Mario Torre wrote: >> What happens if I'm a committer then? Can I simply skip the github >> interface, the required public fork and instead just clone locally, do >> my work and commit? >> >> I.E. a workflow like this: >> >> file bug >> git clone directly-upstream-openjdk >> do some work && create webrev && send email request && get approval >> git push >> >> Or will I be forced to use the public fork and send PRs? >> >> Cheers, >> Mario >> >> On Sat, Nov 16, 2019 at 12:35 AM Kevin Rushforth >> wrote: >>> No, that isn't quite right. A contributor who has the role of Committer >>> is the one who initiates the commit, either via the GitHub UI, by >>> entering the "/integrate" command, or via the Skara tooling, by running >>> "git pr integrate". >>> >>> If a project is set up to require reviewers, then there must be at least >>> one approved review by someone with a Reviewer role in the project must >>> approve it, but it is the Committer who integrates it after the review >>> is done, and after all other requirements are satisfied (e.g., many >>> groups require a second reviewer, API changes require a CSR, etc). >>> >>> A contributor who is not a Committer, needs to have a sponsoring >>> Committer "/sponsor" their change after they issue the "/integrate" >>> command to indicate that they are ready for it to be pushed. >>> >>> In both cases, it is the Committer who initiates the push. >>> >>> -- Kevin >>> >>> >>> On 11/15/2019 3:22 PM, Mario Torre wrote: >>>> Hi Joe, >>>> >>>> Thanks for sharing this. >>>> >>>> On question still remains however, with the move to a pull request model we >>>> effectively give up the role of a committer (even if we maintain it to >>>> respect the bylaw it would be an empty role), this is because the reviewer >>>> or maintainer that approves the change request of effectively committing >>>> and the original author of the patch may have any of the roles from a >>>> simple contributor to a reviewer. >>>> >>>> Is that true or how else would we be dealing with contributions? >>>> >>>> Cheers, >>>> Mario >>>> >>>> On Fri 15. Nov 2019 at 23:39, Joe Darcy wrote: >>>> >>>>> On 11/15/2019 2:22 PM, Mario Torre wrote: >>>>> >>>>> One can argue that git is onerous the same way, the thing is that you are >>>>> not used to mercurial so it appears difficult for you. For this reason I >>>>> may say I won?t contribute a line of code if we switch to git but the >>>>> reality is that if I want or need for some reason I find my way. After all >>>>> we started with Classpath, that was cvs... >>>>> >>>>> All that said, this JEP is only incidentally about git, it?s about GitHub, >>>>> and we shouldn?t confuse the two things. >>>>> >>>>> At the end of the day everyone will still have to go through the governance >>>>> model so it can?t happen that we accept random contributions anymore than >>>>> now, unless this JEP is also about changing the bylaw and giving away with >>>>> the current role system. >>>>> >>>>> The governance model implications are explicitly mentioned in the JEP in >>>>> the goals section: >>>>> >>>>> >>>>> - Do not change the OpenJDK Bylaws . >>>>> - Do not change the OpenJDK Census . >>>>> >>>>> I attended an OpenJDK governing board meeting this October to discuss >>>>> Skara: >>>>> >>>>> https://openjdk.java.net/groups/gb/minutes/2019-10-10 >>>>> >>>>> The slides I presented explicitly quote from the current bylaws: >>>>> >>>>> Section 6 of the OpenJDK Bylaws: "A Project may have web content, one or >>>>> more code repositories, and one or more mailing lists. Projects are >>>>> expected to operate in an open, transparent, and meritocratic manner. Their >>>>> alignment with these principles will be monitored by the Governing Board." >>>>> >>>>> Appendix A of the OpenJDK Bylaws: "The data stored in any infrastructure >>>>> provided for use by Community members must be made available by some means >>>>> that enables, without undue effort, the construction of a complete >>>>> functional clone of that infrastructure and its data as seen by the entire >>>>> Community." >>>>> >>>>> No one present at the meeting disagreed with the assessment that the >>>>> bylaws would *not* need to be updated to use a hosting provider for the >>>>> JDK's sources. >>>>> >>>>> >>>>> -Joe >>>>> >> > From thomas.stuefe at gmail.com Mon Nov 25 10:01:12 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Nov 2019 11:01:12 +0100 Subject: Committers workshop after FOSDEM? Message-ID: Hi, will there be a Committers Workshop after FOSDEM, like we had last year? Thanks, Thomas From hohensee at amazon.com Mon Nov 25 19:12:43 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 25 Nov 2019 19:12:43 +0000 Subject: Committers workshop after FOSDEM? In-Reply-To: References: Message-ID: <4E4499EF-409F-449D-9344-12D883E65870@amazon.com> Yes. See Mark's announcement on the announce list. Paul ?On 11/25/19, 2:02 AM, "discuss on behalf of Thomas St?fe" wrote: Hi, will there be a Committers Workshop after FOSDEM, like we had last year? Thanks, Thomas From thomas.stuefe at gmail.com Mon Nov 25 19:19:36 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Nov 2019 20:19:36 +0100 Subject: Committers workshop after FOSDEM? In-Reply-To: <4E4499EF-409F-449D-9344-12D883E65870@amazon.com> References: <4E4499EF-409F-449D-9344-12D883E65870@amazon.com> Message-ID: Thank you Paul. On Mon, Nov 25, 2019 at 8:12 PM Hohensee, Paul wrote: > Yes. See Mark's announcement on the announce list. > > Paul > > ?On 11/25/19, 2:02 AM, "discuss on behalf of Thomas St?fe" < > discuss-bounces at openjdk.java.net on behalf of thomas.stuefe at gmail.com> > wrote: > > Hi, > > will there be a Committers Workshop after FOSDEM, like we had last > year? > > Thanks, Thomas > > > From neugens.limasoftware at gmail.com Fri Nov 29 18:56:01 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 29 Nov 2019 19:56:01 +0100 Subject: Free Java DevRoom deadline extended! Message-ID: Hello everyone! It?s Christmas earlier again this year ;) By popular demand we are excited to extend the deadline for submission to the 10th of December (23:59 CET)! I will shortly update the website, but the new deadline is effective immediately! Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/