From david.holmes at oracle.com Wed Sep 1 01:42:45 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Sep 2021 11:42:45 +1000 Subject: [External] : Re: GitHub/Mailing list communication defunct? In-Reply-To: References: <095fc050-dbb1-107d-eac9-89c974ba42b8@oracle.com> <59dd2185-104f-3235-6d8a-5f581f6d99be@gmail.com> Message-ID: <16971c98-d84e-7ba3-2b06-7bbb70aa717e@oracle.com> FYI the problem has now been identified and a fix prepared. It should be deployed soon. https://bugs.openjdk.java.net/browse/SKARA-1148 Only certain mailing lists are affected and it can change each month IIUC. David On 12/08/2021 10:03 am, David Holmes wrote: > Just FYI the problem is still under investigation and still seems to > persist for some ML's but not all. > > David > > On 28/07/2021 3:44 am, tim.bell at oracle.com wrote: >> Hello >> >>> if someone comments/replies directly to the mailing list thread (like >>> Bernd and I did, during this past hour[2]), those comments aren't >>> being registered in that github PR. This used to work previously and >>> seems to be broken right now. >> >> We are aware of this problem and still investigating.? We don't have a >> root cause or an ETA for this. >> >> Tim >> >> >> On 7/22/21 09:21, Jaikiran Pai wrote: >>> FWIW, it looks like this isn't fully back to normal. From what I can >>> see in one of the PR's[1] I'm involved in, if I comment directly on >>> the PR through the github UI, a mail is now getting delivered to the >>> relevant mailing lists. So this part is back to normal now. >>> >>> However, if someone comments/replies directly to the mailing list >>> thread (like Bernd and I did, during this past hour[2]), those >>> comments aren't being registered in that github PR. This used to work >>> previously and seems to be broken right now. >>> >>> [1] >>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/4607__;!!ACWV5N9M2RV99hQ!eNjD04SNNH9INHTt0cyyed12lRNw9aZfSspNKh0ILIUQCIcvka-_vJ8XHXipGIQ$ >>> >>> [2] >>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079994.html >>> >>> >>> >>> -Jaikiran >>> >>> On 22/07/21 3:03 am, tim.bell at oracle.com wrote: >>>>> just recognized that all of a sudden the traffic on the OpenJDK >>>>> mailing lists dropped >>>> >>>> About an hour ago we corrected a problem on the Skara server >>>> processing external (EG: github) messages.? Message traffic should >>>> be flowing again. >>>> >>>> Messages for events during the outage are lost.? We will be holding >>>> a port-mortem to investigate why this outage was not noticed sooner, >>>> and why there was a data loss. >>>> >>>> Tim >>>> >>>> >>>> On 7/21/21 14:29, David Holmes wrote: >>>>> Hi Christoph, >>>>> >>>>> On 22/07/2021 1:07 am, Langer, Christoph wrote: >>>>>> Hi, >>>>>> >>>>>> there's still no traffic on the mailing lists... >>>>>> >>>>>> It would be much appreciated if you could share an update on the >>>>>> status. >>>>> >>>>> There was no update to share I'm afraid but it has now been resolved. >>>>> >>>>> It seems likely that the missing mail is gone forever unfortunately. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> Thanks >>>>>> Christoph >>>>>> >>>>>> From: Langer, Christoph >>>>>> Sent: Dienstag, 20. Juli 2021 08:23 >>>>>> To: ops at openjdk.java.net; skara-dev at openjdk.java.net; >>>>>> jdk-dev at openjdk.java.net >>>>>> Subject: GitHub/Mailing list communication defunct? >>>>>> >>>>>> Hi, >>>>>> >>>>>> I just recognized that all of a sudden the traffic on the OpenJDK >>>>>> mailing lists dropped... First I thought it's an issue with my >>>>>> account but looking at the pipermail archives, I don't find any >>>>>> mails after e.g. some time yesterday. And I guess there's still >>>>>> the usual activity on GitHub... >>>>>> >>>>>> Are you aware of an issue? >>>>>> >>>>>> Thanks & Best regards >>>>>> Christoph >>>>>> >>>> >>> >> From erikj at openjdk.java.net Wed Sep 1 14:06:11 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 1 Sep 2021 14:06:11 GMT Subject: Integrated: 1148: Emails on mailing lists are not posted to GitHub PR In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 19:06:29 GMT, Erik Joelsson wrote: > For a bit over a month, the mlbridge bot seems to be having trouble posting emails as comments in PRs. Especially the hotspot-dev list has been experiencing this. This patch should fix that problem. > > The reading of the mailing list archives happens in MailmanListReader::conversations. There we loop over mailing lists and months. If a particular archive file (combo of mailing list and month) does not exist, the inner loop breaks. This break is the bug. In our case, the mailing list ide-support-dev does not have any emails for August and (I think because of that) the URL https://mail.openjdk.java.net/pipermail/ide-support-dev/2021-August.txt returns 404. This is triggering the break, which is stopping the inner loop (which loops over mailing lists) so it never gets to hotspot-dev (and a few others). > > Looking at the history, this broke in SKARA-843, where the inner loop was added. The break statements then started acting on the wrong loop. > > I'm also improving some log messages which I needed while debugging this. This pull request has now been integrated. Changeset: 59c46b88 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/59c46b888358dbc839613081fe0e0d74b4819cb0 Stats: 16 lines in 3 files changed: 0 ins; 3 del; 13 mod 1148: Emails on mailing lists are not posted to GitHub PR Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1212 From erikj at openjdk.java.net Wed Sep 1 14:06:32 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 1 Sep 2021 14:06:32 GMT Subject: Integrated: 1129: [REDO] The mlbridge bot occasionally posts the same comments twice on Github In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 20:12:58 GMT, Erik Joelsson wrote: > Redo of SKARA-1058. The patch is exactly the same as I don't think it was the cause for SKARA-1128. This pull request has now been integrated. Changeset: 273d83d9 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/273d83d90b3987b326db27770a153679c6f9c163 Stats: 38 lines in 10 files changed: 9 ins; 18 del; 11 mod 1129: [REDO] The mlbridge bot occasionally posts the same comments twice on Github Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1213 From erik.joelsson at oracle.com Wed Sep 1 14:59:46 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 1 Sep 2021 07:59:46 -0700 Subject: [External] : Re: GitHub/Mailing list communication defunct? In-Reply-To: <16971c98-d84e-7ba3-2b06-7bbb70aa717e@oracle.com> References: <095fc050-dbb1-107d-eac9-89c974ba42b8@oracle.com> <59dd2185-104f-3235-6d8a-5f581f6d99be@gmail.com> <16971c98-d84e-7ba3-2b06-7bbb70aa717e@oracle.com> Message-ID: The fix was deployed about 30 mins ago and I've seen several missing emails being posted since. However, Skara has a built in limit to only consider emails up to 14 days old. Since this has been defunct for a much longer time, I'm going to temporarily deploy a version with a longer limit so that older emails are found and posted. /Erik On 2021-08-31 18:42, David Holmes wrote: > FYI the problem has now been identified and a fix prepared. It should > be deployed soon. > > https://bugs.openjdk.java.net/browse/SKARA-1148 > > Only certain mailing lists are affected and it can change each month > IIUC. > > David > > On 12/08/2021 10:03 am, David Holmes wrote: >> Just FYI the problem is still under investigation and still seems to >> persist for some ML's but not all. >> >> David >> >> On 28/07/2021 3:44 am, tim.bell at oracle.com wrote: >>> Hello >>> >>>> if someone comments/replies directly to the mailing list thread >>>> (like Bernd and I did, during this past hour[2]), those comments >>>> aren't being registered in that github PR. This used to work >>>> previously and seems to be broken right now. >>> >>> We are aware of this problem and still investigating.? We don't have >>> a root cause or an ETA for this. >>> >>> Tim >>> >>> >>> On 7/22/21 09:21, Jaikiran Pai wrote: >>>> FWIW, it looks like this isn't fully back to normal. From what I >>>> can see in one of the PR's[1] I'm involved in, if I comment >>>> directly on the PR through the github UI, a mail is now getting >>>> delivered to the relevant mailing lists. So this part is back to >>>> normal now. >>>> >>>> However, if someone comments/replies directly to the mailing list >>>> thread (like Bernd and I did, during this past hour[2]), those >>>> comments aren't being registered in that github PR. This used to >>>> work previously and seems to be broken right now. >>>> >>>> [1] >>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/4607__;!!ACWV5N9M2RV99hQ!eNjD04SNNH9INHTt0cyyed12lRNw9aZfSspNKh0ILIUQCIcvka-_vJ8XHXipGIQ$ >>>> >>>> [2] >>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079994.html >>>> >>>> >>>> >>>> -Jaikiran >>>> >>>> On 22/07/21 3:03 am, tim.bell at oracle.com wrote: >>>>>> just recognized that all of a sudden the traffic on the OpenJDK >>>>>> mailing lists dropped >>>>> >>>>> About an hour ago we corrected a problem on the Skara server >>>>> processing external (EG: github) messages.? Message traffic should >>>>> be flowing again. >>>>> >>>>> Messages for events during the outage are lost.? We will be >>>>> holding a port-mortem to investigate why this outage was not >>>>> noticed sooner, and why there was a data loss. >>>>> >>>>> Tim >>>>> >>>>> >>>>> On 7/21/21 14:29, David Holmes wrote: >>>>>> Hi Christoph, >>>>>> >>>>>> On 22/07/2021 1:07 am, Langer, Christoph wrote: >>>>>>> Hi, >>>>>>> >>>>>>> there's still no traffic on the mailing lists... >>>>>>> >>>>>>> It would be much appreciated if you could share an update on the >>>>>>> status. >>>>>> >>>>>> There was no update to share I'm afraid but it has now been >>>>>> resolved. >>>>>> >>>>>> It seems likely that the missing mail is gone forever unfortunately. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> Thanks >>>>>>> Christoph >>>>>>> >>>>>>> From: Langer, Christoph >>>>>>> Sent: Dienstag, 20. Juli 2021 08:23 >>>>>>> To: ops at openjdk.java.net; skara-dev at openjdk.java.net; >>>>>>> jdk-dev at openjdk.java.net >>>>>>> Subject: GitHub/Mailing list communication defunct? >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I just recognized that all of a sudden the traffic on the >>>>>>> OpenJDK mailing lists dropped... First I thought it's an issue >>>>>>> with my account but looking at the pipermail archives, I don't >>>>>>> find any mails after e.g. some time yesterday. And I guess >>>>>>> there's still the usual activity on GitHub... >>>>>>> >>>>>>> Are you aware of an issue? >>>>>>> >>>>>>> Thanks & Best regards >>>>>>> Christoph >>>>>>> >>>>> >>>> >>> From erikj at openjdk.java.net Thu Sep 2 21:49:53 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 2 Sep 2021 21:49:53 GMT Subject: RFR: 1153: Some emails still not posted as comments in PR Message-ID: After fixing SKARA-1148, there were still some emails that weren't being posted as comments in PRs. The underlying cause this time was emails that Skara thinks it has sent, but they never were, so they weren't present in the mail archive. Emails sent in response to such missing emails have bad In-Reply-To headers as they point to emails that aren't in the archive. When the Mbox parser tries to piece together conversations, it fails to find the correct parents in these cases. The reason we need to piece conversations together is to find the original RFR email, which contains the pull request link. This is how each email is associated with the correct pull request. The fix for this is to also look at the References header as a backup. The References header contains the whole ancestor chain of email IDs, so using that, we can connect conversations regardless of missing emails in between, especially since we only really care about the first email in the conversation. Looking at the pipermail thread view, this is what it must be doing as it would otherwise fail miserably. I also tweaked the loops here to hopefully do a bit less work, which I think is worth it due to the pretty large number of emails being parsed here. In addition to this small change to Mbox, I'm also tinkering with some other things that are related. These were things I stumbled over and needed to properly debug and test the issue. As I noted in SKARA-1148 already, the MailingListArchiveReaderBot is doing a lot of redundant work. I blame this on SKARA-843, where this bot was changed from one global instance to running one instance for each configured repository. There were two problems introduced with this change. 1. Each instance still has all the configured repositories, so every found conversation is evaluated against every repository in every instance. This creates an unnecessary N^2 complexity in number of configured repositories. 2. Each instance has its own MailingListReader, configured for exactly the set of mailing lists used for the repository. We have a lot of repositories that share the exact same mailing list config. This means that each of these instances will read all the archives for themselves, with no sharing of this data. The reader already does caching, so after the first time around, it's much faster. Still, the first time around we read jdk-updates-dev a pretty large number of times. My solution for 1 is to only have one single repository in each MailingListArchiveReaderBot. This looks like a simple oversight in the previous patch. For 2, I make sure to only create one MailingListReader for each unique set of mailing lists. This will not remove all the redundant reads, but it will bring them down significantly. I also think it's the functionally correct solution as we will then only consider email threads on the relevant mailing lists for each repository, so less unnecessary (and potentially bad) cross evaluation between mailing lists and repositories that aren't configured as related. To get 2 to actually work correctly, I needed to tweak the logic that protects us from running the wrong WorkItems concurrently. To be able to share MailingListReader between multiple WorkItems, we have WorkItem::concurrentWith. Unfortunately, this method was also used to detect duplicate WorkItems in the pending pool of the scheduler. This is correct in most cases, but not here. An ArchiveReaderWorkItem for jdk11u and jdk15u shares MailingListReader, but queueing one should not replace the other. To solve this I added another method WorkItem::replaces for this particular check (with a default method to preserve the current behavior for all other WorkItems). Finally I also changed ArchiveReaderWorkItem::toString to print the repository name rather than the list of mailing lists. This made a lot more sense to me while debugging as we now create an instance per repository rather than based on mailinglists. ------------- Commit messages: - SKARA-1153 Changes: https://git.openjdk.java.net/skara/pull/1214/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1214&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1153 Stats: 156 lines in 8 files changed: 100 ins; 18 del; 38 mod Patch: https://git.openjdk.java.net/skara/pull/1214.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1214/head:pull/1214 PR: https://git.openjdk.java.net/skara/pull/1214 From kcr at openjdk.java.net Thu Sep 2 22:45:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Sep 2021 22:45:36 GMT Subject: RFR: 1153: Some emails still not posted as comments in PR In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 21:46:12 GMT, Erik Joelsson wrote: > After fixing SKARA-1148, there were still some emails that weren't being posted as comments in PRs. The underlying cause this time was emails that Skara thinks it has sent, but they never were, so they weren't present in the mail archive. Emails sent in response to such missing emails have bad In-Reply-To headers as they point to emails that aren't in the archive. When the Mbox parser tries to piece together conversations, it fails to find the correct parents in these cases. > > The reason we need to piece conversations together is to find the original RFR email, which contains the pull request link. This is how each email is associated with the correct pull request. > > The fix for this is to also look at the References header as a backup. The References header contains the whole ancestor chain of email IDs, so using that, we can connect conversations regardless of missing emails in between, especially since we only really care about the first email in the conversation. Looking at the pipermail thread view, this is what it must be doing as it would otherwise fail miserably. I also tweaked the loops here to hopefully do a bit less work, which I think is worth it due to the pretty large number of emails being parsed here. > > In addition to this small change to Mbox, I'm also tinkering with some other things that are related. These were things I stumbled over and needed to properly debug and test the issue. > > As I noted in SKARA-1148 already, the MailingListArchiveReaderBot is doing a lot of redundant work. I blame this on SKARA-843, where this bot was changed from one global instance to running one instance for each configured repository. There were two problems introduced with this change. > > 1. Each instance still has all the configured repositories, so every found conversation is evaluated against every repository in every instance. This creates an unnecessary N^2 complexity in number of configured repositories. > 2. Each instance has its own MailingListReader, configured for exactly the set of mailing lists used for the repository. We have a lot of repositories that share the exact same mailing list config. This means that each of these instances will read all the archives for themselves, with no sharing of this data. The reader already does caching, so after the first time around, it's much faster. Still, the first time around we read jdk-updates-dev a pretty large number of times. > > My solution for 1 is to only have one single repository in each MailingListArchiveReaderBot. This looks like a simple oversight in the previous patch. > > For 2, I make sure to only create one MailingListReader for each unique set of mailing lists. This will not remove all the redundant reads, but it will bring them down significantly. I also think it's the functionally correct solution as we will then only consider email threads on the relevant mailing lists for each repository, so less unnecessary (and potentially bad) cross evaluation between mailing lists and repositories that aren't configured as related. > > To get 2 to actually work correctly, I needed to tweak the logic that protects us from running the wrong WorkItems concurrently. To be able to share MailingListReader between multiple WorkItems, we have WorkItem::concurrentWith. Unfortunately, this method was also used to detect duplicate WorkItems in the pending pool of the scheduler. This is correct in most cases, but not here. An ArchiveReaderWorkItem for jdk11u and jdk15u shares MailingListReader, but queueing one should not replace the other. To solve this I added another method WorkItem::replaces for this particular check (with a default method to preserve the current behavior for all other WorkItems). > > Finally I also changed ArchiveReaderWorkItem::toString to print the repository name rather than the list of mailing lists. This made a lot more sense to me while debugging as we now create an instance per repository rather than based on mailinglists. This looks good as far as I can tell. I left a couple questions. Is this something you can test before deploying? bot/src/main/java/org/openjdk/skara/bot/BotRunner.java line 254: > 252: for (var pendingItem : pending.entrySet()) { > 253: // If there are pending items of the same type that we cannot run concurrently with, replace them. > 254: if (item.replaces(pendingItem.getKey())) { I presume that `a.concurrentWith(b) == b.concurrentWith(a)` for all work items (meaning that `concurrentWith` is a commutative operation)? The reason I ask is that the old code checked `pendingItem.getKey().concurrentWith(item)` while the new code checks `item.concurrentWith(pendingItem.getKey()))`. I expect it is fine. mailinglist/src/main/java/org/openjdk/skara/mailinglist/Mbox.java line 101: > 99: for (var email : emailsToCheck) { > 100: if (email.id().toString().contains("")) { > 101: log.warning("Found first email of jdk#5300 in mbox"); What is the purpose of this check? ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1214 From erikj at openjdk.java.net Fri Sep 3 12:36:56 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Sep 2021 12:36:56 GMT Subject: RFR: 1153: Some emails still not posted as comments in PR [v2] In-Reply-To: References: Message-ID: > After fixing SKARA-1148, there were still some emails that weren't being posted as comments in PRs. The underlying cause this time was emails that Skara thinks it has sent, but they never were, so they weren't present in the mail archive. Emails sent in response to such missing emails have bad In-Reply-To headers as they point to emails that aren't in the archive. When the Mbox parser tries to piece together conversations, it fails to find the correct parents in these cases. > > The reason we need to piece conversations together is to find the original RFR email, which contains the pull request link. This is how each email is associated with the correct pull request. > > The fix for this is to also look at the References header as a backup. The References header contains the whole ancestor chain of email IDs, so using that, we can connect conversations regardless of missing emails in between, especially since we only really care about the first email in the conversation. Looking at the pipermail thread view, this is what it must be doing as it would otherwise fail miserably. I also tweaked the loops here to hopefully do a bit less work, which I think is worth it due to the pretty large number of emails being parsed here. > > In addition to this small change to Mbox, I'm also tinkering with some other things that are related. These were things I stumbled over and needed to properly debug and test the issue. > > As I noted in SKARA-1148 already, the MailingListArchiveReaderBot is doing a lot of redundant work. I blame this on SKARA-843, where this bot was changed from one global instance to running one instance for each configured repository. There were two problems introduced with this change. > > 1. Each instance still has all the configured repositories, so every found conversation is evaluated against every repository in every instance. This creates an unnecessary N^2 complexity in number of configured repositories. > 2. Each instance has its own MailingListReader, configured for exactly the set of mailing lists used for the repository. We have a lot of repositories that share the exact same mailing list config. This means that each of these instances will read all the archives for themselves, with no sharing of this data. The reader already does caching, so after the first time around, it's much faster. Still, the first time around we read jdk-updates-dev a pretty large number of times. > > My solution for 1 is to only have one single repository in each MailingListArchiveReaderBot. This looks like a simple oversight in the previous patch. > > For 2, I make sure to only create one MailingListReader for each unique set of mailing lists. This will not remove all the redundant reads, but it will bring them down significantly. I also think it's the functionally correct solution as we will then only consider email threads on the relevant mailing lists for each repository, so less unnecessary (and potentially bad) cross evaluation between mailing lists and repositories that aren't configured as related. > > To get 2 to actually work correctly, I needed to tweak the logic that protects us from running the wrong WorkItems concurrently. To be able to share MailingListReader between multiple WorkItems, we have WorkItem::concurrentWith. Unfortunately, this method was also used to detect duplicate WorkItems in the pending pool of the scheduler. This is correct in most cases, but not here. An ArchiveReaderWorkItem for jdk11u and jdk15u shares MailingListReader, but queueing one should not replace the other. To solve this I added another method WorkItem::replaces for this particular check (with a default method to preserve the current behavior for all other WorkItems). > > Finally I also changed ArchiveReaderWorkItem::toString to print the repository name rather than the list of mailing lists. This made a lot more sense to me while debugging as we now create an instance per repository rather than based on mailinglists. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Remove debug code ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1214/files - new: https://git.openjdk.java.net/skara/pull/1214/files/9569d07b..fda3fbb9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1214&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1214&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1214.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1214/head:pull/1214 PR: https://git.openjdk.java.net/skara/pull/1214 From kcr at openjdk.java.net Fri Sep 3 12:36:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Sep 2021 12:36:56 GMT Subject: RFR: 1153: Some emails still not posted as comments in PR [v2] In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 12:34:08 GMT, Erik Joelsson wrote: >> After fixing SKARA-1148, there were still some emails that weren't being posted as comments in PRs. The underlying cause this time was emails that Skara thinks it has sent, but they never were, so they weren't present in the mail archive. Emails sent in response to such missing emails have bad In-Reply-To headers as they point to emails that aren't in the archive. When the Mbox parser tries to piece together conversations, it fails to find the correct parents in these cases. >> >> The reason we need to piece conversations together is to find the original RFR email, which contains the pull request link. This is how each email is associated with the correct pull request. >> >> The fix for this is to also look at the References header as a backup. The References header contains the whole ancestor chain of email IDs, so using that, we can connect conversations regardless of missing emails in between, especially since we only really care about the first email in the conversation. Looking at the pipermail thread view, this is what it must be doing as it would otherwise fail miserably. I also tweaked the loops here to hopefully do a bit less work, which I think is worth it due to the pretty large number of emails being parsed here. >> >> In addition to this small change to Mbox, I'm also tinkering with some other things that are related. These were things I stumbled over and needed to properly debug and test the issue. >> >> As I noted in SKARA-1148 already, the MailingListArchiveReaderBot is doing a lot of redundant work. I blame this on SKARA-843, where this bot was changed from one global instance to running one instance for each configured repository. There were two problems introduced with this change. >> >> 1. Each instance still has all the configured repositories, so every found conversation is evaluated against every repository in every instance. This creates an unnecessary N^2 complexity in number of configured repositories. >> 2. Each instance has its own MailingListReader, configured for exactly the set of mailing lists used for the repository. We have a lot of repositories that share the exact same mailing list config. This means that each of these instances will read all the archives for themselves, with no sharing of this data. The reader already does caching, so after the first time around, it's much faster. Still, the first time around we read jdk-updates-dev a pretty large number of times. >> >> My solution for 1 is to only have one single repository in each MailingListArchiveReaderBot. This looks like a simple oversight in the previous patch. >> >> For 2, I make sure to only create one MailingListReader for each unique set of mailing lists. This will not remove all the redundant reads, but it will bring them down significantly. I also think it's the functionally correct solution as we will then only consider email threads on the relevant mailing lists for each repository, so less unnecessary (and potentially bad) cross evaluation between mailing lists and repositories that aren't configured as related. >> >> To get 2 to actually work correctly, I needed to tweak the logic that protects us from running the wrong WorkItems concurrently. To be able to share MailingListReader between multiple WorkItems, we have WorkItem::concurrentWith. Unfortunately, this method was also used to detect duplicate WorkItems in the pending pool of the scheduler. This is correct in most cases, but not here. An ArchiveReaderWorkItem for jdk11u and jdk15u shares MailingListReader, but queueing one should not replace the other. To solve this I added another method WorkItem::replaces for this particular check (with a default method to preserve the current behavior for all other WorkItems). >> >> Finally I also changed ArchiveReaderWorkItem::toString to print the repository name rather than the list of mailing lists. This made a lot more sense to me while debugging as we now create an instance per repository rather than based on mailinglists. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Remove debug code Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1214 From erikj at openjdk.java.net Fri Sep 3 12:36:58 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Sep 2021 12:36:58 GMT Subject: RFR: 1153: Some emails still not posted as comments in PR [v2] In-Reply-To: References: Message-ID: <31WV5kbmMfQkoWJGxUDNtLrFfsQYxlmDV5jUgvSVfQk=.8f47d53a-1975-4194-8c46-fd99016524fa@github.com> On Thu, 2 Sep 2021 22:43:11 GMT, Kevin Rushforth wrote: > Is this something you can test before deploying? With a local edit of the BotRunner, I have manually tested the MailingListArchiveReaderBot and ArchiveReaderWorkItem by running them with the full production configuration, but prevented any other WorkItems from actually running. I've then inspected the set of CommentPosterWorkItems that get scheduled. > bot/src/main/java/org/openjdk/skara/bot/BotRunner.java line 254: > >> 252: for (var pendingItem : pending.entrySet()) { >> 253: // If there are pending items of the same type that we cannot run concurrently with, replace them. >> 254: if (item.replaces(pendingItem.getKey())) { > > I presume that `a.concurrentWith(b) == b.concurrentWith(a)` for all work items (meaning that `concurrentWith` is a commutative operation)? The reason I ask is that the old code checked `pendingItem.getKey().concurrentWith(item)` while the new code checks `item.concurrentWith(pendingItem.getKey()))`. I expect it is fine. As far as I can tell, it's commutative. I flipped it around because it made more sense to me to ask "replaces?" that way, but who calls who really shouldn't matter in either case. > mailinglist/src/main/java/org/openjdk/skara/mailinglist/Mbox.java line 101: > >> 99: for (var email : emailsToCheck) { >> 100: if (email.id().toString().contains("")) { >> 101: log.warning("Found first email of jdk#5300 in mbox"); > > What is the purpose of this check? Ah, that's a left over debug message (and break point line) from my testing. Will remove. ------------- PR: https://git.openjdk.java.net/skara/pull/1214 From erikj at openjdk.java.net Fri Sep 3 12:42:51 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Sep 2021 12:42:51 GMT Subject: RFR: 1153: Some emails still not posted as comments in PR [v3] In-Reply-To: References: Message-ID: > After fixing SKARA-1148, there were still some emails that weren't being posted as comments in PRs. The underlying cause this time was emails that Skara thinks it has sent, but they never were, so they weren't present in the mail archive. Emails sent in response to such missing emails have bad In-Reply-To headers as they point to emails that aren't in the archive. When the Mbox parser tries to piece together conversations, it fails to find the correct parents in these cases. > > The reason we need to piece conversations together is to find the original RFR email, which contains the pull request link. This is how each email is associated with the correct pull request. > > The fix for this is to also look at the References header as a backup. The References header contains the whole ancestor chain of email IDs, so using that, we can connect conversations regardless of missing emails in between, especially since we only really care about the first email in the conversation. Looking at the pipermail thread view, this is what it must be doing as it would otherwise fail miserably. I also tweaked the loops here to hopefully do a bit less work, which I think is worth it due to the pretty large number of emails being parsed here. > > In addition to this small change to Mbox, I'm also tinkering with some other things that are related. These were things I stumbled over and needed to properly debug and test the issue. > > As I noted in SKARA-1148 already, the MailingListArchiveReaderBot is doing a lot of redundant work. I blame this on SKARA-843, where this bot was changed from one global instance to running one instance for each configured repository. There were two problems introduced with this change. > > 1. Each instance still has all the configured repositories, so every found conversation is evaluated against every repository in every instance. This creates an unnecessary N^2 complexity in number of configured repositories. > 2. Each instance has its own MailingListReader, configured for exactly the set of mailing lists used for the repository. We have a lot of repositories that share the exact same mailing list config. This means that each of these instances will read all the archives for themselves, with no sharing of this data. The reader already does caching, so after the first time around, it's much faster. Still, the first time around we read jdk-updates-dev a pretty large number of times. > > My solution for 1 is to only have one single repository in each MailingListArchiveReaderBot. This looks like a simple oversight in the previous patch. > > For 2, I make sure to only create one MailingListReader for each unique set of mailing lists. This will not remove all the redundant reads, but it will bring them down significantly. I also think it's the functionally correct solution as we will then only consider email threads on the relevant mailing lists for each repository, so less unnecessary (and potentially bad) cross evaluation between mailing lists and repositories that aren't configured as related. > > To get 2 to actually work correctly, I needed to tweak the logic that protects us from running the wrong WorkItems concurrently. To be able to share MailingListReader between multiple WorkItems, we have WorkItem::concurrentWith. Unfortunately, this method was also used to detect duplicate WorkItems in the pending pool of the scheduler. This is correct in most cases, but not here. An ArchiveReaderWorkItem for jdk11u and jdk15u shares MailingListReader, but queueing one should not replace the other. To solve this I added another method WorkItem::replaces for this particular check (with a default method to preserve the current behavior for all other WorkItems). > > Finally I also changed ArchiveReaderWorkItem::toString to print the repository name rather than the list of mailing lists. This made a lot more sense to me while debugging as we now create an instance per repository rather than based on mailinglists. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Added comment ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1214/files - new: https://git.openjdk.java.net/skara/pull/1214/files/fda3fbb9..feece7c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1214&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1214&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1214.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1214/head:pull/1214 PR: https://git.openjdk.java.net/skara/pull/1214 From erikj at openjdk.java.net Fri Sep 3 16:57:16 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Sep 2021 16:57:16 GMT Subject: Integrated: 1153: Some emails still not posted as comments in PR In-Reply-To: References: Message-ID: <1J6ymy5n_C_3NQlQSYlYdqW63gvVspCwPxxL2oqkbkA=.1f296461-c90a-4039-a92d-a7dc958f3166@github.com> On Thu, 2 Sep 2021 21:46:12 GMT, Erik Joelsson wrote: > After fixing SKARA-1148, there were still some emails that weren't being posted as comments in PRs. The underlying cause this time was emails that Skara thinks it has sent, but they never were, so they weren't present in the mail archive. Emails sent in response to such missing emails have bad In-Reply-To headers as they point to emails that aren't in the archive. When the Mbox parser tries to piece together conversations, it fails to find the correct parents in these cases. > > The reason we need to piece conversations together is to find the original RFR email, which contains the pull request link. This is how each email is associated with the correct pull request. > > The fix for this is to also look at the References header as a backup. The References header contains the whole ancestor chain of email IDs, so using that, we can connect conversations regardless of missing emails in between, especially since we only really care about the first email in the conversation. Looking at the pipermail thread view, this is what it must be doing as it would otherwise fail miserably. I also tweaked the loops here to hopefully do a bit less work, which I think is worth it due to the pretty large number of emails being parsed here. > > In addition to this small change to Mbox, I'm also tinkering with some other things that are related. These were things I stumbled over and needed to properly debug and test the issue. > > As I noted in SKARA-1148 already, the MailingListArchiveReaderBot is doing a lot of redundant work. I blame this on SKARA-843, where this bot was changed from one global instance to running one instance for each configured repository. There were two problems introduced with this change. > > 1. Each instance still has all the configured repositories, so every found conversation is evaluated against every repository in every instance. This creates an unnecessary N^2 complexity in number of configured repositories. > 2. Each instance has its own MailingListReader, configured for exactly the set of mailing lists used for the repository. We have a lot of repositories that share the exact same mailing list config. This means that each of these instances will read all the archives for themselves, with no sharing of this data. The reader already does caching, so after the first time around, it's much faster. Still, the first time around we read jdk-updates-dev a pretty large number of times. > > My solution for 1 is to only have one single repository in each MailingListArchiveReaderBot. This looks like a simple oversight in the previous patch. > > For 2, I make sure to only create one MailingListReader for each unique set of mailing lists. This will not remove all the redundant reads, but it will bring them down significantly. I also think it's the functionally correct solution as we will then only consider email threads on the relevant mailing lists for each repository, so less unnecessary (and potentially bad) cross evaluation between mailing lists and repositories that aren't configured as related. > > To get 2 to actually work correctly, I needed to tweak the logic that protects us from running the wrong WorkItems concurrently. To be able to share MailingListReader between multiple WorkItems, we have WorkItem::concurrentWith. Unfortunately, this method was also used to detect duplicate WorkItems in the pending pool of the scheduler. This is correct in most cases, but not here. An ArchiveReaderWorkItem for jdk11u and jdk15u shares MailingListReader, but queueing one should not replace the other. To solve this I added another method WorkItem::replaces for this particular check (with a default method to preserve the current behavior for all other WorkItems). > > Finally I also changed ArchiveReaderWorkItem::toString to print the repository name rather than the list of mailing lists. This made a lot more sense to me while debugging as we now create an instance per repository rather than based on mailinglists. This pull request has now been integrated. Changeset: 3293f7af Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/3293f7afda04febc4ca212d2a7acedb682d5cb5f Stats: 158 lines in 8 files changed: 102 ins; 21 del; 35 mod 1153: Some emails still not posted as comments in PR Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1214 From erikj at openjdk.java.net Fri Sep 3 16:57:16 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Sep 2021 16:57:16 GMT Subject: RFR: 1153: Some emails still not posted as comments in PR [v3] In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 12:42:51 GMT, Erik Joelsson wrote: >> After fixing SKARA-1148, there were still some emails that weren't being posted as comments in PRs. The underlying cause this time was emails that Skara thinks it has sent, but they never were, so they weren't present in the mail archive. Emails sent in response to such missing emails have bad In-Reply-To headers as they point to emails that aren't in the archive. When the Mbox parser tries to piece together conversations, it fails to find the correct parents in these cases. >> >> The reason we need to piece conversations together is to find the original RFR email, which contains the pull request link. This is how each email is associated with the correct pull request. >> >> The fix for this is to also look at the References header as a backup. The References header contains the whole ancestor chain of email IDs, so using that, we can connect conversations regardless of missing emails in between, especially since we only really care about the first email in the conversation. Looking at the pipermail thread view, this is what it must be doing as it would otherwise fail miserably. I also tweaked the loops here to hopefully do a bit less work, which I think is worth it due to the pretty large number of emails being parsed here. >> >> In addition to this small change to Mbox, I'm also tinkering with some other things that are related. These were things I stumbled over and needed to properly debug and test the issue. >> >> As I noted in SKARA-1148 already, the MailingListArchiveReaderBot is doing a lot of redundant work. I blame this on SKARA-843, where this bot was changed from one global instance to running one instance for each configured repository. There were two problems introduced with this change. >> >> 1. Each instance still has all the configured repositories, so every found conversation is evaluated against every repository in every instance. This creates an unnecessary N^2 complexity in number of configured repositories. >> 2. Each instance has its own MailingListReader, configured for exactly the set of mailing lists used for the repository. We have a lot of repositories that share the exact same mailing list config. This means that each of these instances will read all the archives for themselves, with no sharing of this data. The reader already does caching, so after the first time around, it's much faster. Still, the first time around we read jdk-updates-dev a pretty large number of times. >> >> My solution for 1 is to only have one single repository in each MailingListArchiveReaderBot. This looks like a simple oversight in the previous patch. >> >> For 2, I make sure to only create one MailingListReader for each unique set of mailing lists. This will not remove all the redundant reads, but it will bring them down significantly. I also think it's the functionally correct solution as we will then only consider email threads on the relevant mailing lists for each repository, so less unnecessary (and potentially bad) cross evaluation between mailing lists and repositories that aren't configured as related. >> >> To get 2 to actually work correctly, I needed to tweak the logic that protects us from running the wrong WorkItems concurrently. To be able to share MailingListReader between multiple WorkItems, we have WorkItem::concurrentWith. Unfortunately, this method was also used to detect duplicate WorkItems in the pending pool of the scheduler. This is correct in most cases, but not here. An ArchiveReaderWorkItem for jdk11u and jdk15u shares MailingListReader, but queueing one should not replace the other. To solve this I added another method WorkItem::replaces for this particular check (with a default method to preserve the current behavior for all other WorkItems). >> >> Finally I also changed ArchiveReaderWorkItem::toString to print the repository name rather than the list of mailing lists. This made a lot more sense to me while debugging as we now create an instance per repository rather than based on mailinglists. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Added comment Thanks Kevin! ------------- PR: https://git.openjdk.java.net/skara/pull/1214 From erikj at openjdk.java.net Fri Sep 3 21:25:02 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Sep 2021 21:25:02 GMT Subject: RFR: 1125: OpenJDK 7 backports incorrectly tagged with hgupdate-sync Message-ID: This patch makes "openjdk7u" a valid JdkVersion in the Skara version parser. This was preventing the SyncLabelBot from properly setting or removing the hgupdate-sync label on backports with this fixVersion. ------------- Commit messages: - SKARA-1125 Changes: https://git.openjdk.java.net/skara/pull/1215/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1215&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1125 Stats: 17 lines in 3 files changed: 13 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/skara/pull/1215.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1215/head:pull/1215 PR: https://git.openjdk.java.net/skara/pull/1215 From kcr at openjdk.java.net Fri Sep 3 21:35:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Sep 2021 21:35:52 GMT Subject: RFR: 1125: OpenJDK 7 backports incorrectly tagged with hgupdate-sync In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 21:21:14 GMT, Erik Joelsson wrote: > This patch makes "openjdk7u" a valid JdkVersion in the Skara version parser. This was preventing the SyncLabelBot from properly setting or removing the hgupdate-sync label on backports with this fixVersion. Marked as reviewed by kcr (Reviewer). jbs/src/main/java/org/openjdk/skara/jbs/JdkVersion.java line 42: > 40: > 41: // Match a version string symbolizing some future, but yet undefined, update of a major version > 42: private final static Pattern futureUpdatePattern = Pattern.compile("((openjdk)?[1-9][0-9]*u)(-([a-z0-9]+))?$"); This seems like it has some overlap with `ojVersionPattern`. It might be OK, though. ------------- PR: https://git.openjdk.java.net/skara/pull/1215 From ihse at openjdk.java.net Mon Sep 6 08:31:13 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 6 Sep 2021 08:31:13 GMT Subject: RFR: 1125: OpenJDK 7 backports incorrectly tagged with hgupdate-sync In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 21:21:14 GMT, Erik Joelsson wrote: > This patch makes "openjdk7u" a valid JdkVersion in the Skara version parser. This was preventing the SyncLabelBot from properly setting or removing the hgupdate-sync label on backports with this fixVersion. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1215 From erikj at openjdk.java.net Tue Sep 7 16:00:53 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 7 Sep 2021 16:00:53 GMT Subject: RFR: 1125: OpenJDK 7 backports incorrectly tagged with hgupdate-sync In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 21:29:55 GMT, Kevin Rushforth wrote: >> This patch makes "openjdk7u" a valid JdkVersion in the Skara version parser. This was preventing the SyncLabelBot from properly setting or removing the hgupdate-sync label on backports with this fixVersion. > > jbs/src/main/java/org/openjdk/skara/jbs/JdkVersion.java line 42: > >> 40: >> 41: // Match a version string symbolizing some future, but yet undefined, update of a major version >> 42: private final static Pattern futureUpdatePattern = Pattern.compile("((openjdk)?[1-9][0-9]*u)(-([a-z0-9]+))?$"); > > This seems like it has some overlap with `ojVersionPattern`. It might be OK, though. Right, there is certainly overlap between some of these expressions. In the end I picked this one to extend as I thought the most defining feature was the 'u' without any number after it. ------------- PR: https://git.openjdk.java.net/skara/pull/1215 From erikj at openjdk.java.net Tue Sep 7 18:44:09 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 7 Sep 2021 18:44:09 GMT Subject: Integrated: 1125: OpenJDK 7 backports incorrectly tagged with hgupdate-sync In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 21:21:14 GMT, Erik Joelsson wrote: > This patch makes "openjdk7u" a valid JdkVersion in the Skara version parser. This was preventing the SyncLabelBot from properly setting or removing the hgupdate-sync label on backports with this fixVersion. This pull request has now been integrated. Changeset: 34c565e9 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/34c565e99d217afb25db9d776f176c6b5d17a8d7 Stats: 17 lines in 3 files changed: 13 ins; 0 del; 4 mod 1125: OpenJDK 7 backports incorrectly tagged with hgupdate-sync Reviewed-by: kcr, ihse ------------- PR: https://git.openjdk.java.net/skara/pull/1215 From erikj at openjdk.java.net Tue Sep 7 19:28:47 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 7 Sep 2021 19:28:47 GMT Subject: RFR: 1150: Migrate skara tooling for client code to reference the new client-libs-dev list Message-ID: Here is my attempt at trying to rewrite the rules for automatic labeling for the new "client" label and client-libs-dev mailing list. I took the combined contents of the previous 2d, awt, sound and swing labels, sorted the lines and then tried to manually merge as much as possible. It's possible I didn't get everything correct or at least not fully optimized. ------------- Commit messages: - Merge branch 'master' into SKARA-1150-client-libs-dev - SKARA-1150 Changes: https://git.openjdk.java.net/skara/pull/1216/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1216&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1150 Stats: 128 lines in 1 file changed: 26 ins; 85 del; 17 mod Patch: https://git.openjdk.java.net/skara/pull/1216.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1216/head:pull/1216 PR: https://git.openjdk.java.net/skara/pull/1216 From kcr at openjdk.java.net Tue Sep 7 20:59:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Sep 2021 20:59:54 GMT Subject: RFR: 1150: Migrate skara tooling for client code to reference the new client-libs-dev list In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 19:25:11 GMT, Erik Joelsson wrote: > Here is my attempt at trying to rewrite the rules for automatic labeling for the new "client" label and client-libs-dev mailing list. I took the combined contents of the previous 2d, awt, sound and swing labels, sorted the lines and then tried to manually merge as much as possible. It's possible I didn't get everything correct or at least not fully optimized. @prrace should take a look at this. It can probably be optimized further if we assume that everything under `src/java.desktop`, with the exception of the two directories that are part of `java.beans` should get the `client` label. This will pick up a couple directories (for accessibility) and a handful of other files that weren't included before, but I suspect that was probably an oversight. With that assumption, I think this would be the minimal reduction: src/java.desktop/aix src/java.desktop/linux src/java.desktop/macosx src/java.desktop/share/classes/com/sun/accessibility src/java.desktop/share/classes/com/sun/imageio src/java.desktop/share/classes/com/sun/java src/java.desktop/share/classes/com/sun/media src/java.desktop/share/classes/com/sun/swing src/java.desktop/share/classes/java/applet src/java.desktop/share/classes/java/awt src/java.desktop/share/classes/javax src/java.desktop/share/classes/sun src/java.desktop/share/conf src/java.desktop/share/legal src/java.desktop/share/native src/java.desktop/unix src/java.desktop/windows And then you would probably add the 3 beans files that formerly had the `2d` label, plus the build and test files from your PR. Let's see what Phil says. ------------- PR: https://git.openjdk.java.net/skara/pull/1216 From prr at openjdk.java.net Tue Sep 7 21:44:20 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 7 Sep 2021 21:44:20 GMT Subject: RFR: 1150: Migrate skara tooling for client code to reference the new client-libs-dev list In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 20:57:28 GMT, Kevin Rushforth wrote: > And then you would probably add the 3 beans files that formerly had the `2d` label, plus the build and test files from your PR. Let's see what Phil says. Phil doesn't understand why beans is still separate. In the JBS I wrote "All subscribers to client mailing lists - those for the above groups and also the beans-dev list have been subscribed to the new client-libs-dev list." So beans-dev is going away too .. so the entire java.desktop module should be mapped to client-libs-dev It should be one trivial mapping except for a double-mapping to client and build for the build related files that reside in the desktop module .. although I don't know that I see them there in this change ? Actually neither before, nor after, the change. Perhaps they moved after skara built this mapping. You may also find it useful to look at what I put here : https://openjdk.java.net/groups/client-libs/ It enumerates all the source, demo, test, make/build files I could identify that are handled by client-libs jdk.unsupported.desktop is there but unless I'm missing something is unmapped. You can cross-reference the tests + demos between the json and that web page too. ------------- PR: https://git.openjdk.java.net/skara/pull/1216 From erikj at openjdk.java.net Tue Sep 7 21:46:57 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 7 Sep 2021 21:46:57 GMT Subject: RFR: 1150: Migrate skara tooling for client code to reference the new client-libs-dev list In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 19:25:11 GMT, Erik Joelsson wrote: > Here is my attempt at trying to rewrite the rules for automatic labeling for the new "client" label and client-libs-dev mailing list. I took the combined contents of the previous 2d, awt, sound and swing labels, sorted the lines and then tried to manually merge as much as possible. It's possible I didn't get everything correct or at least not fully optimized. Thanks for the input Phil and Kevin, I missed that beans was also included. I will simplify this further. ------------- PR: https://git.openjdk.java.net/skara/pull/1216 From erikj at openjdk.java.net Wed Sep 8 19:19:46 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 8 Sep 2021 19:19:46 GMT Subject: RFR: 1150: Migrate skara tooling for client code to reference the new client-libs-dev list [v2] In-Reply-To: References: Message-ID: <-HgW0SAobi3sDePifu2QWxetwvGQLfL9erD3m3N1TYo=.cbafa9ea-9ac2-4159-a1b0-1373e75ffc6b@github.com> > Here is my attempt at trying to rewrite the rules for automatic labeling for the new "client" label and client-libs-dev mailing list. I took the combined contents of the previous 2d, awt, sound and swing labels, sorted the lines and then tried to manually merge as much as possible. It's possible I didn't get everything correct or at least not fully optimized. Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: - Renamed label to client - Simplified mappings based on feedback ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1216/files - new: https://git.openjdk.java.net/skara/pull/1216/files/06490edd..2c0dfee7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1216&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1216&range=00-01 Stats: 40 lines in 1 file changed: 2 ins; 32 del; 6 mod Patch: https://git.openjdk.java.net/skara/pull/1216.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1216/head:pull/1216 PR: https://git.openjdk.java.net/skara/pull/1216 From ihse at openjdk.java.net Wed Sep 8 20:47:49 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 8 Sep 2021 20:47:49 GMT Subject: RFR: 1150: Migrate skara tooling for client code to reference the new client-libs-dev list [v2] In-Reply-To: <-HgW0SAobi3sDePifu2QWxetwvGQLfL9erD3m3N1TYo=.cbafa9ea-9ac2-4159-a1b0-1373e75ffc6b@github.com> References: <-HgW0SAobi3sDePifu2QWxetwvGQLfL9erD3m3N1TYo=.cbafa9ea-9ac2-4159-a1b0-1373e75ffc6b@github.com> Message-ID: <_GAB4rUzdUw5KleRatUivP2FsELGImbT9uEIjJrCVtA=.15eecddc-02bd-4d6c-9380-8694681f6b64@github.com> On Wed, 8 Sep 2021 19:19:46 GMT, Erik Joelsson wrote: >> Here is my attempt at trying to rewrite the rules for automatic labeling for the new "client" label and client-libs-dev mailing list. I took the combined contents of the previous 2d, awt, sound and swing labels, sorted the lines and then tried to manually merge as much as possible. It's possible I didn't get everything correct or at least not fully optimized. > > Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: > > - Renamed label to client > - Simplified mappings based on feedback Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1216 From kcr at openjdk.java.net Wed Sep 8 22:11:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Sep 2021 22:11:38 GMT Subject: RFR: 1150: Migrate skara tooling for client code to reference the new client-libs-dev list [v2] In-Reply-To: <-HgW0SAobi3sDePifu2QWxetwvGQLfL9erD3m3N1TYo=.cbafa9ea-9ac2-4159-a1b0-1373e75ffc6b@github.com> References: <-HgW0SAobi3sDePifu2QWxetwvGQLfL9erD3m3N1TYo=.cbafa9ea-9ac2-4159-a1b0-1373e75ffc6b@github.com> Message-ID: On Wed, 8 Sep 2021 19:19:46 GMT, Erik Joelsson wrote: >> Here is my attempt at trying to rewrite the rules for automatic labeling for the new "client" label and client-libs-dev mailing list. I took the combined contents of the previous 2d, awt, sound and swing labels, sorted the lines and then tried to manually merge as much as possible. It's possible I didn't get everything correct or at least not fully optimized. > > Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: > > - Renamed label to client > - Simplified mappings based on feedback Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1216 From erikj at openjdk.java.net Thu Sep 9 20:42:15 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 9 Sep 2021 20:42:15 GMT Subject: Integrated: 1150: Migrate skara tooling for client code to reference the new client-libs-dev list In-Reply-To: References: Message-ID: <6p9pB1Jy1lVAVRVXDHFpbrPn53CINKQqbn1PTWSD1U4=.53ecea09-be24-4e76-a01c-84bd8811b8c9@github.com> On Tue, 7 Sep 2021 19:25:11 GMT, Erik Joelsson wrote: > Here is my attempt at trying to rewrite the rules for automatic labeling for the new "client" label and client-libs-dev mailing list. I took the combined contents of the previous 2d, awt, sound and swing labels, sorted the lines and then tried to manually merge as much as possible. It's possible I didn't get everything correct or at least not fully optimized. This pull request has now been integrated. Changeset: e398e44b Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/e398e44b7682d6f99789c8ff00622766c2be82c5 Stats: 141 lines in 1 file changed: 26 ins; 115 del; 0 mod 1150: Migrate skara tooling for client code to reference the new client-libs-dev list Reviewed-by: ihse, kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1216 From serb at openjdk.java.net Fri Sep 10 03:07:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 10 Sep 2021 03:07:28 GMT Subject: RFR: 1167: Update the mapping of files for the client group Message-ID: <19mK46G1E6HZudLV1MS-BF6aZtDAbZpdmbxAhW7WfK8=.d913cc92-d78d-4042-a595-cf3e50fac8d6@github.com> A few records related to the client are added to the jdk.json ------------- Commit messages: - Update jdk.json Changes: https://git.openjdk.java.net/skara/pull/1217/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1217&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1167 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1217.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1217/head:pull/1217 PR: https://git.openjdk.java.net/skara/pull/1217 From serb at openjdk.java.net Fri Sep 10 03:07:29 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 10 Sep 2021 03:07:29 GMT Subject: RFR: 1167: Update the mapping of files for the client group In-Reply-To: <19mK46G1E6HZudLV1MS-BF6aZtDAbZpdmbxAhW7WfK8=.d913cc92-d78d-4042-a595-cf3e50fac8d6@github.com> References: <19mK46G1E6HZudLV1MS-BF6aZtDAbZpdmbxAhW7WfK8=.d913cc92-d78d-4042-a595-cf3e50fac8d6@github.com> Message-ID: On Fri, 10 Sep 2021 02:59:46 GMT, Sergey Bylokhov wrote: > A few records related to the client are added to the jdk.json config/mailinglist/rules/jdk.json line 15: > 13: "client": [ > 14: "make/\\w+(Demos|X11)", > 15: "make/autoconf/lib-(alsa|cups|font|freetype|x11)", Is it fine in a few places to use the "font" instead of "fontconfig" and "x11" instead of "x11wrappergen"? config/mailinglist/rules/jdk.json line 17: > 15: "make/autoconf/lib-(alsa|cups|font|freetype|x11)", > 16: "make/data/(font|x11)", > 17: "make/jdk/src/classes/build/tools/(generatenimbus/|x11wrappergen)", Why nimbus has a slash at the end? it can be removed? ------------- PR: https://git.openjdk.java.net/skara/pull/1217 From erikj at openjdk.java.net Fri Sep 10 12:40:40 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 10 Sep 2021 12:40:40 GMT Subject: RFR: 1167: Update the mapping of files for the client group In-Reply-To: <19mK46G1E6HZudLV1MS-BF6aZtDAbZpdmbxAhW7WfK8=.d913cc92-d78d-4042-a595-cf3e50fac8d6@github.com> References: <19mK46G1E6HZudLV1MS-BF6aZtDAbZpdmbxAhW7WfK8=.d913cc92-d78d-4042-a595-cf3e50fac8d6@github.com> Message-ID: On Fri, 10 Sep 2021 02:59:46 GMT, Sergey Bylokhov wrote: > A few records related to the client are added to the jdk.json Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1217 From erikj at openjdk.java.net Fri Sep 10 12:40:41 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 10 Sep 2021 12:40:41 GMT Subject: RFR: 1167: Update the mapping of files for the client group In-Reply-To: References: <19mK46G1E6HZudLV1MS-BF6aZtDAbZpdmbxAhW7WfK8=.d913cc92-d78d-4042-a595-cf3e50fac8d6@github.com> Message-ID: On Fri, 10 Sep 2021 03:01:32 GMT, Sergey Bylokhov wrote: >> A few records related to the client are added to the jdk.json > > config/mailinglist/rules/jdk.json line 15: > >> 13: "client": [ >> 14: "make/\\w+(Demos|X11)", >> 15: "make/autoconf/lib-(alsa|cups|font|freetype|x11)", > > Is it fine in a few places to use the "font" instead of "fontconfig" and "x11" instead of "x11wrappergen"? My understanding is that the regexp is used to match a prefix. If you add a slash at the end, you enforce a full directory name instead of a partial match. Feel free to rewrite as you like. > config/mailinglist/rules/jdk.json line 17: > >> 15: "make/autoconf/lib-(alsa|cups|font|freetype|x11)", >> 16: "make/data/(font|x11)", >> 17: "make/jdk/src/classes/build/tools/(generatenimbus/|x11wrappergen)", > > Why nimbus has a slash at the end? it can be removed? As said in the other comment, the slash enforces a full match on a directory instead of a partial. I don't know why this particular dir has a slash when so many others do not. Feel free to rewrite as you like. ------------- PR: https://git.openjdk.java.net/skara/pull/1217 From serb at openjdk.java.net Fri Sep 10 19:41:54 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 10 Sep 2021 19:41:54 GMT Subject: RFR: 1167: Update the mapping of files for the client group [v2] In-Reply-To: <19mK46G1E6HZudLV1MS-BF6aZtDAbZpdmbxAhW7WfK8=.d913cc92-d78d-4042-a595-cf3e50fac8d6@github.com> References: <19mK46G1E6HZudLV1MS-BF6aZtDAbZpdmbxAhW7WfK8=.d913cc92-d78d-4042-a595-cf3e50fac8d6@github.com> Message-ID: > A few records related to the client are added to the jdk.json Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: Update jdk.json ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1217/files - new: https://git.openjdk.java.net/skara/pull/1217/files/1f2b3f14..e87b712f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1217&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1217&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1217.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1217/head:pull/1217 PR: https://git.openjdk.java.net/skara/pull/1217 From erikj at openjdk.java.net Fri Sep 10 20:12:53 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 10 Sep 2021 20:12:53 GMT Subject: RFR: 1167: Update the mapping of files for the client group [v2] In-Reply-To: References: <19mK46G1E6HZudLV1MS-BF6aZtDAbZpdmbxAhW7WfK8=.d913cc92-d78d-4042-a595-cf3e50fac8d6@github.com> Message-ID: On Fri, 10 Sep 2021 19:41:54 GMT, Sergey Bylokhov wrote: >> A few records related to the client are added to the jdk.json > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > Update jdk.json Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1217 From kcr at openjdk.java.net Fri Sep 10 20:38:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Sep 2021 20:38:29 GMT Subject: RFR: 1167: Update the mapping of files for the client group [v2] In-Reply-To: References: <19mK46G1E6HZudLV1MS-BF6aZtDAbZpdmbxAhW7WfK8=.d913cc92-d78d-4042-a595-cf3e50fac8d6@github.com> Message-ID: On Fri, 10 Sep 2021 19:41:54 GMT, Sergey Bylokhov wrote: >> A few records related to the client are added to the jdk.json > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > Update jdk.json Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1217 From serb at openjdk.java.net Sat Sep 11 11:57:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 11 Sep 2021 11:57:28 GMT Subject: Integrated: 1167: Update the mapping of files for the client group In-Reply-To: <19mK46G1E6HZudLV1MS-BF6aZtDAbZpdmbxAhW7WfK8=.d913cc92-d78d-4042-a595-cf3e50fac8d6@github.com> References: <19mK46G1E6HZudLV1MS-BF6aZtDAbZpdmbxAhW7WfK8=.d913cc92-d78d-4042-a595-cf3e50fac8d6@github.com> Message-ID: On Fri, 10 Sep 2021 02:59:46 GMT, Sergey Bylokhov wrote: > A few records related to the client are added to the jdk.json This pull request has now been integrated. Changeset: d816d143 Author: Sergey Bylokhov Committer: Kevin Rushforth URL: https://git.openjdk.java.net/skara/commit/d816d1431e0efc9a4024c5ff3deea13642c62707 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod 1167: Update the mapping of files for the client group Reviewed-by: erikj, kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1217 From erikj at openjdk.java.net Mon Sep 13 15:43:26 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 13 Sep 2021 15:43:26 GMT Subject: RFR: 1170: Notify bot reposts commit comments if another notifier fails Message-ID: Prevent the CommitCommentNotifier from posting the exact same comment twice. ------------- Commit messages: - SKARA-1170 Changes: https://git.openjdk.java.net/skara/pull/1218/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1218&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1170 Stats: 67 lines in 2 files changed: 66 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1218.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1218/head:pull/1218 PR: https://git.openjdk.java.net/skara/pull/1218 From kcr at openjdk.java.net Mon Sep 13 15:51:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Sep 2021 15:51:52 GMT Subject: RFR: 1170: Notify bot reposts commit comments if another notifier fails In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 15:39:11 GMT, Erik Joelsson wrote: > Prevent the CommitCommentNotifier from posting the exact same comment twice. Looks good. bots/notify/src/test/java/org/openjdk/skara/bots/notify/comment/CommitCommentNotifierTests.java line 175: > 173: void testNoRepeatedCommitComment(TestInfo testInfo) throws IOException { > 174: try (var credentials = new HostCredentials(testInfo); > 175: var tempFolder = new TemporaryDirectory()) { Minor: indentation is different from below lines. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1218 From erikj at openjdk.java.net Mon Sep 13 16:34:52 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 13 Sep 2021 16:34:52 GMT Subject: RFR: 1170: Notify bot reposts commit comments if another notifier fails In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 15:48:41 GMT, Kevin Rushforth wrote: >> Prevent the CommitCommentNotifier from posting the exact same comment twice. > > bots/notify/src/test/java/org/openjdk/skara/bots/notify/comment/CommitCommentNotifierTests.java line 175: > >> 173: void testNoRepeatedCommitComment(TestInfo testInfo) throws IOException { >> 174: try (var credentials = new HostCredentials(testInfo); >> 175: var tempFolder = new TemporaryDirectory()) { > > Minor: indentation is different from below lines. Yes, that seems to be a recurring style choice in the codebase. The contents of the try () is lined up with the start of the opening parentheses. ------------- PR: https://git.openjdk.java.net/skara/pull/1218 From erikj at openjdk.java.net Mon Sep 13 18:41:03 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 13 Sep 2021 18:41:03 GMT Subject: Integrated: Better logging in mlbridge Message-ID: <4iTklb_ekWcbIolMUdVpGjnFQEsIqb3jFso9t6TPnlg=.3d211263-8f4c-43f7-af16-4030b3c886d2@github.com> Minor fix to get better logging information to help investigate SKARA-1172. ------------- Commit messages: - Better logging in mlbridge Changes: https://git.openjdk.java.net/skara/pull/1219/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1219&range=00 Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1219.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1219/head:pull/1219 PR: https://git.openjdk.java.net/skara/pull/1219 From kcr at openjdk.java.net Mon Sep 13 18:41:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Sep 2021 18:41:03 GMT Subject: Integrated: Better logging in mlbridge In-Reply-To: <4iTklb_ekWcbIolMUdVpGjnFQEsIqb3jFso9t6TPnlg=.3d211263-8f4c-43f7-af16-4030b3c886d2@github.com> References: <4iTklb_ekWcbIolMUdVpGjnFQEsIqb3jFso9t6TPnlg=.3d211263-8f4c-43f7-af16-4030b3c886d2@github.com> Message-ID: On Mon, 13 Sep 2021 18:31:50 GMT, Erik Joelsson wrote: > Minor fix to get better logging information to help investigate SKARA-1172. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1219 From erikj at openjdk.java.net Mon Sep 13 18:41:03 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 13 Sep 2021 18:41:03 GMT Subject: Integrated: Better logging in mlbridge In-Reply-To: <4iTklb_ekWcbIolMUdVpGjnFQEsIqb3jFso9t6TPnlg=.3d211263-8f4c-43f7-af16-4030b3c886d2@github.com> References: <4iTklb_ekWcbIolMUdVpGjnFQEsIqb3jFso9t6TPnlg=.3d211263-8f4c-43f7-af16-4030b3c886d2@github.com> Message-ID: On Mon, 13 Sep 2021 18:31:50 GMT, Erik Joelsson wrote: > Minor fix to get better logging information to help investigate SKARA-1172. This pull request has now been integrated. Changeset: 57944f63 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/57944f638cf7ab3e17765ad388231d233e053bcd Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod Better logging in mlbridge Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1219 From erikj at openjdk.java.net Mon Sep 13 19:02:50 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 13 Sep 2021 19:02:50 GMT Subject: Integrated: 1170: Notify bot reposts commit comments if another notifier fails In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 15:39:11 GMT, Erik Joelsson wrote: > Prevent the CommitCommentNotifier from posting the exact same comment twice. This pull request has now been integrated. Changeset: a6c854a5 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/a6c854a5af65c4dc9488829ca24843dc1cff7783 Stats: 67 lines in 2 files changed: 66 ins; 0 del; 1 mod 1170: Notify bot reposts commit comments if another notifier fails Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1218 From erikj at openjdk.java.net Mon Sep 13 19:49:47 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 13 Sep 2021 19:49:47 GMT Subject: RFR: 1166: New Gitlab version is causing "Initial paginated response no longer paginated" errors Message-ID: This patch changes the exception thrown when a paginated rest query suddenly returns a results without pages. Instead of a RuntimeException I'm throwing an UncheckedRestException, which makes the BotRunner treat it as a warning instead of logging SEVERE. The assumption is that this happens randomly, just like other rest call failures, and that most WorkItems will just have to be rerun at a later time. ------------- Commit messages: - SKARA-1166 Changes: https://git.openjdk.java.net/skara/pull/1220/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1220&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1166 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1220.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1220/head:pull/1220 PR: https://git.openjdk.java.net/skara/pull/1220 From kcr at openjdk.java.net Mon Sep 13 19:52:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Sep 2021 19:52:31 GMT Subject: RFR: 1166: New Gitlab version is causing "Initial paginated response no longer paginated" errors In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 19:45:43 GMT, Erik Joelsson wrote: > This patch changes the exception thrown when a paginated rest query suddenly returns a results without pages. Instead of a RuntimeException I'm throwing an UncheckedRestException, which makes the BotRunner treat it as a warning instead of logging SEVERE. The assumption is that this happens randomly, just like other rest call failures, and that most WorkItems will just have to be rerun at a later time. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1220 From erikj at openjdk.java.net Mon Sep 13 20:54:13 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 13 Sep 2021 20:54:13 GMT Subject: Integrated: 1166: New Gitlab version is causing "Initial paginated response no longer paginated" errors In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 19:45:43 GMT, Erik Joelsson wrote: > This patch changes the exception thrown when a paginated rest query suddenly returns a results without pages. Instead of a RuntimeException I'm throwing an UncheckedRestException, which makes the BotRunner treat it as a warning instead of logging SEVERE. The assumption is that this happens randomly, just like other rest call failures, and that most WorkItems will just have to be rerun at a later time. This pull request has now been integrated. Changeset: 38e1a409 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/38e1a409c6d94771d4301a657f89195003ac6f7b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 1166: New Gitlab version is causing "Initial paginated response no longer paginated" errors Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1220 From erik.joelsson at oracle.com Tue Sep 14 13:57:46 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 14 Sep 2021 06:57:46 -0700 Subject: Switch jdk8u development to Git/Skara Message-ID: Hello, Back in February there was a discussion about moving the OpenJDK 8u development to Git/Skara together with the jdk11u move [1]. The conclusion then, as I understood it, was to wait until sometime after jdk11u was moved to give people a chance to get familiar with the new development process and iron out the details on how it should be applied. The jdk11u move took place over the summer, so I thought now would be a good time to revisit the discussion for jdk8u. The move for 8u is a bit trickier than 11u as a necessary pre step is to first consolidate the Mercurial repositories into one, like we did for JDK 10. I have already produced a prototype conversion during the previous discussion [2], but it's quite outdated at this time. Unfortunately, the consolidation process is not easily automated and only incremental to a point (basically on a per promotion tag level, but even that comes with some caveats in the update world where multiple releases are are being developed in parallel). Because of this it's not feasible to setup a live mirror like we did for jdk11u. Instead, we will need to plan for up to a week (worst case) of downtime where I produce the final consolidated HG repository, and then let Skara convert and publish this to Github. Ideally it should only take 1-2 days, but these consolidations have been finicky in the past, so better plan for the worst. Another option would be to transition in 2 steps, first to a consolidated HG repo, then to Git. This certainly has other drawbacks, having to adjust to and support another development process for a short period of time. It would, however, make the final transition to Git much smoother and similar to the jdk11u transition. I would like to hear from the maintainers of jdk8u what your preferred strategy would be and what timelines that would make sense to you. /Erik [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-February/013402.html [2] https://github.com/openjdk/jdk8u From erik.joelsson at oracle.com Wed Sep 15 12:28:41 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 15 Sep 2021 05:28:41 -0700 Subject: Switch jdk8u development to Git/Skara In-Reply-To: References: Message-ID: <6189dd25-c696-21f2-9f69-fba54732811f@oracle.com> On 2021-09-14 06:57, erik.joelsson at oracle.com wrote: > [2] https://github.com/openjdk/jdk8u This has now been updated with everything including tag jdk8u312-b05. /Erik From volker.simonis at gmail.com Wed Sep 15 13:25:04 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Sep 2021 15:25:04 +0200 Subject: Switch jdk8u development to Git/Skara In-Reply-To: <6189dd25-c696-21f2-9f69-fba54732811f@oracle.com> References: <6189dd25-c696-21f2-9f69-fba54732811f@oracle.com> Message-ID: Hi Erik, thanks for not having forgotten about this issue :) Taking into account that 8u will be supported for at least five more years until 2026 [1,2] and that all downports are meanwhile originating from Git repositories I'm still strongly in favour of this migration in general. Regarding the technical migration details I think I'd slightly in favour of the big-bang. one-step variant but I'm happy to accept the decision of the current 8u maintainers, whatever that will be. Best regards, Volker [1] https://access.redhat.com/articles/1299013#OpenJDK_Update_Release [2] https://aws.amazon.com/de/about-aws/whats-new/2020/08/amazon-corretto-8-11-support-extended/ On Wed, Sep 15, 2021 at 2:28 PM wrote: > > > On 2021-09-14 06:57, erik.joelsson at oracle.com wrote: > > [2] https://github.com/openjdk/jdk8u > > This has now been updated with everything including tag jdk8u312-b05. > > /Erik > > From vkempik at azul.com Fri Sep 17 10:35:00 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Fri, 17 Sep 2021 10:35:00 +0000 Subject: Switch jdk8u development to Git/Skara In-Reply-To: References: <6189dd25-c696-21f2-9f69-fba54732811f@oracle.com> Message-ID: Hello If Skara?s ?/backport? command can be updated to do patch unshuffling then it will be a huge thing to ease backporting. Regards, Vladimir > 15 ????. 2021 ?., ? 16:25, Volker Simonis ???????(?): > > Hi Erik, > > thanks for not having forgotten about this issue :) > > Taking into account that 8u will be supported for at least five more > years until 2026 [1,2] and that all downports are meanwhile > originating from Git repositories I'm still strongly in favour of this > migration in general. > > Regarding the technical migration details I think I'd slightly in > favour of the big-bang. one-step variant but I'm happy to accept the > decision of the current 8u maintainers, whatever that will be. > > Best regards, > Volker > > [1] https://access.redhat.com/articles/1299013#OpenJDK_Update_Release > [2] https://aws.amazon.com/de/about-aws/whats-new/2020/08/amazon-corretto-8-11-support-extended/ > > On Wed, Sep 15, 2021 at 2:28 PM wrote: >> >> >> On 2021-09-14 06:57, erik.joelsson at oracle.com wrote: >>> [2] https://github.com/openjdk/jdk8u >> >> This has now been updated with everything including tag jdk8u312-b05. >> >> /Erik >> >> From erikj at openjdk.java.net Fri Sep 17 22:05:47 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 17 Sep 2021 22:05:47 GMT Subject: RFR: 1079: Support ability to defer and delegate timing of an integration Message-ID: Here is my first stab at implementing a way for a PR author to defer integration to another committer. The usecase for this is if the timing of the integration is important, but the author may not be available to issue the /integrate command at the desired time. Here is how it works: There are two new arguments to the /integrate command "defer" and "undefer". If the author of a PR issues "/integrate defer", the PR enters the deferred state (which is marked by the label "deferred"). This enables any committer to issue "/integrate" to actually perform the integration. When a PR is integrated by someone other than the author, then that person gets attributed in the Git committer field, just like when a change is sponsored. The author can revert this ability at any time before integration happens by issuing "/integrate undefer". This is similar to how sponsoring a change works, but not quite the same. When setting up for being sponsored, the /integrate command will run all the checks and record the specific hash that the author wishes to commit. I skipped this kind of rigorous book keeping here as I think it is more likely to get in the way in the desired usecase. The whole point is that timing is important and the author is not available, so better to leave things more open in my opinion. I'm open to informed suggestions on how this could potentially be improved on a conceptual level. When writing the test, I based it on the simpleMerge test already present. It took some work to properly understand what was happening in that test, and to make it clearer (at least to me), I have renamed and reorganized things a little bit. In these tests, the HostedRepository instances ("author", "integrator", "reviewer" etc) represent users and are used to create PR test instances (or views) which the test can use to interact with the PR as different users. To make this clearer, I introduced the botUser explicitly as that is also a user that sometimes issues commands and interacts with a PR, and used that for things that the bot is doing. I also changed some other users around so that they perform the role for which they are named (reviewer reviews, not the integrator). When composing the messages that the bot will print back in comments, I noticed that "PR" and "pull request" were used interchangeably. I decided to standardize on "pull request". ------------- Commit messages: - SKARA-1079 Changes: https://git.openjdk.java.net/skara/pull/1221/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1221&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1079 Stats: 213 lines in 5 files changed: 173 ins; 23 del; 17 mod Patch: https://git.openjdk.java.net/skara/pull/1221.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1221/head:pull/1221 PR: https://git.openjdk.java.net/skara/pull/1221 From kcr at openjdk.java.net Fri Sep 17 23:11:20 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Sep 2021 23:11:20 GMT Subject: RFR: 1079: Support ability to defer and delegate timing of an integration In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 22:00:04 GMT, Erik Joelsson wrote: > Here is my first stab at implementing a way for a PR author to defer integration to another committer. The usecase for this is if the timing of the integration is important, but the author may not be available to issue the /integrate command at the desired time. > > Here is how it works: There are two new arguments to the /integrate command "defer" and "undefer". If the author of a PR issues "/integrate defer", the PR enters the deferred state (which is marked by the label "deferred"). This enables any committer to issue "/integrate" to actually perform the integration. When a PR is integrated by someone other than the author, then that person gets attributed in the Git committer field, just like when a change is sponsored. The author can revert this ability at any time before integration happens by issuing "/integrate undefer". > > This is similar to how sponsoring a change works, but not quite the same. When setting up for being sponsored, the /integrate command will run all the checks and record the specific hash that the author wishes to commit. I skipped this kind of rigorous book keeping here as I think it is more likely to get in the way in the desired usecase. The whole point is that timing is important and the author is not available, so better to leave things more open in my opinion. > > I'm open to informed suggestions on how this could potentially be improved on a conceptual level. > > When writing the test, I based it on the simpleMerge test already present. It took some work to properly understand what was happening in that test, and to make it clearer (at least to me), I have renamed and reorganized things a little bit. In these tests, the HostedRepository instances ("author", "integrator", "reviewer" etc) represent users and are used to create PR test instances (or views) which the test can use to interact with the PR as different users. To make this clearer, I introduced the botUser explicitly as that is also a user that sometimes issues commands and interacts with a PR, and used that for things that the bot is doing. I also changed some other users around so that they perform the role for which they are named (reviewer reviews, not the integrator). > > When composing the messages that the bot will print back in comments, I noticed that "PR" and "pull request" were used interchangeably. I decided to standardize on "pull request". I'll do a review of the implementation when I can. Conceptually, this seems like a good approach to me. I wonder if there would be a benefit in having the ability to defer to a specific Committer (or maybe list of Committers)? As you say, one of the use cases might be when a specific timing is needed. Another case might be a coordination with another developer so that both yours and their PR go in at roughly the same time. In both of those cases, it seems more likely that I would want a specific delegate to be able to integrate on my behalf. I don't know if this additional flexibility is worth the complexity. ------------- PR: https://git.openjdk.java.net/skara/pull/1221 From erikj at openjdk.java.net Mon Sep 20 20:12:36 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 20 Sep 2021 20:12:36 GMT Subject: RFR: 1079: Support ability to defer and delegate timing of an integration In-Reply-To: References: Message-ID: <_Ui4F_9JfqAGja8sG1jfQ4sBeDokYuZ_h1ze_u2bk4U=.922e7cb4-c5e8-4060-943d-94fe83196ab5@github.com> On Fri, 17 Sep 2021 22:00:04 GMT, Erik Joelsson wrote: > Here is my first stab at implementing a way for a PR author to defer integration to another committer. The usecase for this is if the timing of the integration is important, but the author may not be available to issue the /integrate command at the desired time. > > Here is how it works: There are two new arguments to the /integrate command "defer" and "undefer". If the author of a PR issues "/integrate defer", the PR enters the deferred state (which is marked by the label "deferred"). This enables any committer to issue "/integrate" to actually perform the integration. When a PR is integrated by someone other than the author, then that person gets attributed in the Git committer field, just like when a change is sponsored. The author can revert this ability at any time before integration happens by issuing "/integrate undefer". > > This is similar to how sponsoring a change works, but not quite the same. When setting up for being sponsored, the /integrate command will run all the checks and record the specific hash that the author wishes to commit. I skipped this kind of rigorous book keeping here as I think it is more likely to get in the way in the desired usecase. The whole point is that timing is important and the author is not available, so better to leave things more open in my opinion. > > I'm open to informed suggestions on how this could potentially be improved on a conceptual level. > > When writing the test, I based it on the simpleMerge test already present. It took some work to properly understand what was happening in that test, and to make it clearer (at least to me), I have renamed and reorganized things a little bit. In these tests, the HostedRepository instances ("author", "integrator", "reviewer" etc) represent users and are used to create PR test instances (or views) which the test can use to interact with the PR as different users. To make this clearer, I introduced the botUser explicitly as that is also a user that sometimes issues commands and interacts with a PR, and used that for things that the bot is doing. I also changed some other users around so that they perform the role for which they are named (reviewer reviews, not the integrator). > > When composing the messages that the bot will print back in comments, I noticed that "PR" and "pull request" were used interchangeably. I decided to standardize on "pull request". I was considering maintaining a list of valid integrators, but in the end I felt like it just added complexity to solve a problem I doubt we would ever really have. I do believe we can trust committers within the OpenJDK to not go around and issue /integrate in other people's PRs. ------------- PR: https://git.openjdk.java.net/skara/pull/1221 From erikj at openjdk.java.net Mon Sep 20 20:47:56 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 20 Sep 2021 20:47:56 GMT Subject: RFR: 1180: Improve logging when WorkItems run for too long Message-ID: When trying to investigate SKARA-1178, I was finding myself lacking vital information in the logs. Specifically I wanted to know which WorkItem instances in particular (workId) that were running for too long, and also how long they had actually been running. (The current calculation will always just show the timeout value.) This patch changes things around a bit in the BotRunner to make these values available when logging a timeout warning. ------------- Commit messages: - SKARA-1180 Changes: https://git.openjdk.java.net/skara/pull/1222/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1222&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1180 Stats: 27 lines in 1 file changed: 10 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/skara/pull/1222.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1222/head:pull/1222 PR: https://git.openjdk.java.net/skara/pull/1222 From kcr at openjdk.java.net Mon Sep 20 22:18:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 20 Sep 2021 22:18:49 GMT Subject: RFR: 1180: Improve logging when WorkItems run for too long In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 20:43:14 GMT, Erik Joelsson wrote: > When trying to investigate SKARA-1178, I was finding myself lacking vital information in the logs. Specifically I wanted to know which WorkItem instances in particular (workId) that were running for too long, and also how long they had actually been running. (The current calculation will always just show the timeout value.) > > This patch changes things around a bit in the BotRunner to make these values available when logging a timeout warning. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1222 From kcr at openjdk.java.net Mon Sep 20 22:46:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 20 Sep 2021 22:46:57 GMT Subject: RFR: 1079: Support ability to defer and delegate timing of an integration In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 22:00:04 GMT, Erik Joelsson wrote: > Here is my first stab at implementing a way for a PR author to defer integration to another committer. The usecase for this is if the timing of the integration is important, but the author may not be available to issue the /integrate command at the desired time. > > Here is how it works: There are two new arguments to the /integrate command "defer" and "undefer". If the author of a PR issues "/integrate defer", the PR enters the deferred state (which is marked by the label "deferred"). This enables any committer to issue "/integrate" to actually perform the integration. When a PR is integrated by someone other than the author, then that person gets attributed in the Git committer field, just like when a change is sponsored. The author can revert this ability at any time before integration happens by issuing "/integrate undefer". > > This is similar to how sponsoring a change works, but not quite the same. When setting up for being sponsored, the /integrate command will run all the checks and record the specific hash that the author wishes to commit. I skipped this kind of rigorous book keeping here as I think it is more likely to get in the way in the desired usecase. The whole point is that timing is important and the author is not available, so better to leave things more open in my opinion. > > I'm open to informed suggestions on how this could potentially be improved on a conceptual level. > > When writing the test, I based it on the simpleMerge test already present. It took some work to properly understand what was happening in that test, and to make it clearer (at least to me), I have renamed and reorganized things a little bit. In these tests, the HostedRepository instances ("author", "integrator", "reviewer" etc) represent users and are used to create PR test instances (or views) which the test can use to interact with the PR as different users. To make this clearer, I introduced the botUser explicitly as that is also a user that sometimes issues commands and interacts with a PR, and used that for things that the bot is doing. I also changed some other users around so that they perform the role for which they are named (reviewer reviews, not the integrator). > > When composing the messages that the bot will print back in comments, I noticed that "PR" and "pull request" were used interchangeably. I decided to standardize on "pull request". The fix and test both look good. I added a couple minor comments on the test. bots/pr/src/test/java/org/openjdk/skara/bots/pr/IntegrateTests.java line 1359: > 1357: assertEquals(1, undeferred, "Missing undeferred message"); > 1358: assertFalse(authorPr.labelNames().contains("deferred")); > 1359: Is it worth attempting to `/integrate` as the integrator here (which should fail since you've set it back to manual)? bots/pr/src/test/java/org/openjdk/skara/bots/pr/IntegrateTests.java line 1385: > 1383: var headCommit = pushedRepo.commits(headHash.hex() + "^.." + headHash.hex()).asList().get(0); > 1384: > 1385: // Author and committer should be the same Not the same as each other. bots/pr/src/test/java/org/openjdk/skara/bots/pr/IntegrateTests.java line 1392: > 1390: assertTrue(authorPr.labelNames().contains("integrated")); > 1391: > 1392: // Ready label should have been removed Minor: `// Ready and defer labels ...` ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1221 From erikj at openjdk.java.net Tue Sep 21 19:01:51 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 21 Sep 2021 19:01:51 GMT Subject: Integrated: 1180: Improve logging when WorkItems run for too long In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 20:43:14 GMT, Erik Joelsson wrote: > When trying to investigate SKARA-1178, I was finding myself lacking vital information in the logs. Specifically I wanted to know which WorkItem instances in particular (workId) that were running for too long, and also how long they had actually been running. (The current calculation will always just show the timeout value.) > > This patch changes things around a bit in the BotRunner to make these values available when logging a timeout warning. This pull request has now been integrated. Changeset: 03e8d58d Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/03e8d58d99ff909d67dad6f216036662c3950aa8 Stats: 27 lines in 1 file changed: 10 ins; 0 del; 17 mod 1180: Improve logging when WorkItems run for too long Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1222 From erikj at openjdk.java.net Tue Sep 21 22:07:28 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 21 Sep 2021 22:07:28 GMT Subject: RFR: 1079: Support ability to defer and delegate timing of an integration [v2] In-Reply-To: References: Message-ID: > Here is my first stab at implementing a way for a PR author to defer integration to another committer. The usecase for this is if the timing of the integration is important, but the author may not be available to issue the /integrate command at the desired time. > > Here is how it works: There are two new arguments to the /integrate command "defer" and "undefer". If the author of a PR issues "/integrate defer", the PR enters the deferred state (which is marked by the label "deferred"). This enables any committer to issue "/integrate" to actually perform the integration. When a PR is integrated by someone other than the author, then that person gets attributed in the Git committer field, just like when a change is sponsored. The author can revert this ability at any time before integration happens by issuing "/integrate undefer". > > This is similar to how sponsoring a change works, but not quite the same. When setting up for being sponsored, the /integrate command will run all the checks and record the specific hash that the author wishes to commit. I skipped this kind of rigorous book keeping here as I think it is more likely to get in the way in the desired usecase. The whole point is that timing is important and the author is not available, so better to leave things more open in my opinion. > > I'm open to informed suggestions on how this could potentially be improved on a conceptual level. > > When writing the test, I based it on the simpleMerge test already present. It took some work to properly understand what was happening in that test, and to make it clearer (at least to me), I have renamed and reorganized things a little bit. In these tests, the HostedRepository instances ("author", "integrator", "reviewer" etc) represent users and are used to create PR test instances (or views) which the test can use to interact with the PR as different users. To make this clearer, I introduced the botUser explicitly as that is also a user that sometimes issues commands and interacts with a PR, and used that for things that the bot is doing. I also changed some other users around so that they perform the role for which they are named (reviewer reviews, not the integrator). > > When composing the messages that the bot will print back in comments, I noticed that "PR" and "pull request" were used interchangeably. I decided to standardize on "pull request". Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: - Fix comment - Adjusted for review comments ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1221/files - new: https://git.openjdk.java.net/skara/pull/1221/files/d861a3e0..ff720eb5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1221&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1221&range=00-01 Stats: 15 lines in 1 file changed: 11 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1221.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1221/head:pull/1221 PR: https://git.openjdk.java.net/skara/pull/1221 From kcr at openjdk.java.net Tue Sep 21 22:12:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Sep 2021 22:12:58 GMT Subject: RFR: 1079: Support ability to defer and delegate timing of an integration [v2] In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 22:07:28 GMT, Erik Joelsson wrote: >> Here is my first stab at implementing a way for a PR author to defer integration to another committer. The usecase for this is if the timing of the integration is important, but the author may not be available to issue the /integrate command at the desired time. >> >> Here is how it works: There are two new arguments to the /integrate command "defer" and "undefer". If the author of a PR issues "/integrate defer", the PR enters the deferred state (which is marked by the label "deferred"). This enables any committer to issue "/integrate" to actually perform the integration. When a PR is integrated by someone other than the author, then that person gets attributed in the Git committer field, just like when a change is sponsored. The author can revert this ability at any time before integration happens by issuing "/integrate undefer". >> >> This is similar to how sponsoring a change works, but not quite the same. When setting up for being sponsored, the /integrate command will run all the checks and record the specific hash that the author wishes to commit. I skipped this kind of rigorous book keeping here as I think it is more likely to get in the way in the desired usecase. The whole point is that timing is important and the author is not available, so better to leave things more open in my opinion. >> >> I'm open to informed suggestions on how this could potentially be improved on a conceptual level. >> >> When writing the test, I based it on the simpleMerge test already present. It took some work to properly understand what was happening in that test, and to make it clearer (at least to me), I have renamed and reorganized things a little bit. In these tests, the HostedRepository instances ("author", "integrator", "reviewer" etc) represent users and are used to create PR test instances (or views) which the test can use to interact with the PR as different users. To make this clearer, I introduced the botUser explicitly as that is also a user that sometimes issues commands and interacts with a PR, and used that for things that the bot is doing. I also changed some other users around so that they perform the role for which they are named (reviewer reviews, not the integrator). >> >> When composing the messages that the bot will print back in comments, I noticed that "PR" and "pull request" were used interchangeably. I decided to standardize on "pull request". > > Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: > > - Fix comment > - Adjusted for review comments Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1221 From nlisker at gmail.com Wed Sep 22 17:39:00 2021 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 22 Sep 2021 20:39:00 +0300 Subject: SKARA-286 Add more info about CSR in the PR's first comment Message-ID: Hi. A long while ago I filed https://bugs.openjdk.java.net/browse/SKARA-286 I still think that providing a link to the CSR just like there is a link to the issue is useful. The point about a checkbox for the CSR is not that important since there's a dedicated indicator now (though I'm not sure why a checkbox like the other requirements was not good enough). Can a link be added? Thanks, Nir From erik.joelsson at oracle.com Wed Sep 22 18:26:07 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 22 Sep 2021 11:26:07 -0700 Subject: SKARA-286 Add more info about CSR in the PR's first comment In-Reply-To: References: Message-ID: Hello Nir, Your request is probably a good idea, but unfortunately the current situation is that we have 69 open enhancement requests on Skara and very limited resources allocated to the project. Given this I think it's unlikely that I or any other current Skara maintainer will be able to get to this anytime soon. As with most open source projects, contributions are welcome. /Erik On 2021-09-22 10:39, Nir Lisker wrote: > Hi. > > A long while ago I filed https://bugs.openjdk.java.net/browse/SKARA-286 > > I still think that providing a link to the CSR just like there is a link to > the issue is useful. The point about a checkbox for the CSR is not that > important since there's a dedicated indicator now (though I'm not sure why > a checkbox like the other requirements was not good enough). > > Can a link be added? > > Thanks, > Nir From jai.forums2013 at gmail.com Mon Sep 27 06:45:46 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 27 Sep 2021 12:15:46 +0530 Subject: Is jcheck on GitHub PRs down? Message-ID: <440cc50b-617b-a323-a93f-3b6a1b8a8671@gmail.com> In some of the recent PRs, I'm seeing that the "jcheck" job is no longer running. Is that intentional or is that job currently down? Sample PRs: https://github.com/openjdk/jdk/pull/5709 https://github.com/openjdk/jdk/pull/5710 I am also seeing some other odd issues (where an review/approval doesn't trigger the PR description to be updated with reviewers), perhaps those are related to this same bot/job? -Jaikiran From david.holmes at oracle.com Mon Sep 27 08:50:24 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Sep 2021 18:50:24 +1000 Subject: Is jcheck on GitHub PRs down? In-Reply-To: References: <440cc50b-617b-a323-a93f-3b6a1b8a8671@gmail.com> Message-ID: <268ea624-7021-8f03-8fd3-05eab487fe3d@oracle.com> The bots are having another problem. It is being investigated. David On 27/09/2021 6:33 pm, Severin Gehwolf wrote: > On Mon, 2021-09-27 at 06:56 +0000, Lindenmaier, Goetz wrote: >> Hi, >> >> I observed this too. >> Yesterday I thought the bots would not work at all, but then they >> processed my PRs at some point. >> >> But now again I am waiting for my >> /backport jdk11u-dev >> command for 30+min. >> https://github.com/openjdk/jdk/commit/0544a732a44309bf7cbb44846dd9320c6096de17 >> I'll work around this by just making the downport PRs by hand. > > Sounds like a repeat of: > https://bugs.openjdk.java.net/browse/SKARA-1178 > > Erik, it seems it's not fixed after all? > > Thanks, > Severin > From erik.joelsson at oracle.com Mon Sep 27 13:52:59 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 27 Sep 2021 06:52:59 -0700 Subject: Is jcheck on GitHub PRs down? In-Reply-To: <268ea624-7021-8f03-8fd3-05eab487fe3d@oracle.com> References: <440cc50b-617b-a323-a93f-3b6a1b8a8671@gmail.com> <268ea624-7021-8f03-8fd3-05eab487fe3d@oracle.com> Message-ID: <96ddedea-3e6b-5dd1-1307-424bc3ac71b8@oracle.com> Hello, I believe I've found the underlying cause for the slowdown of the PR bot. I will be working on a fix today. In the meantime, regular restarts will alleviate the problem. https://bugs.openjdk.java.net/browse/SKARA-1191 /Erik On 2021-09-27 01:50, David Holmes wrote: > The bots are having another problem. It is being investigated. > > David > > On 27/09/2021 6:33 pm, Severin Gehwolf wrote: >> On Mon, 2021-09-27 at 06:56 +0000, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I observed this too. >>> Yesterday I thought the bots would not work at all, but then they >>> processed my PRs at some point. >>> >>> But now again I am waiting for my >>> /backport jdk11u-dev >>> command for 30+min. >>> https://github.com/openjdk/jdk/commit/0544a732a44309bf7cbb44846dd9320c6096de17 >>> >>> I'll work around this by just making the downport PRs by hand. >> >> Sounds like a repeat of: >> https://bugs.openjdk.java.net/browse/SKARA-1178 >> >> Erik, it seems it's not fixed after all? >> >> Thanks, >> Severin >> From erikj at openjdk.java.net Mon Sep 27 20:42:06 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 27 Sep 2021 20:42:06 GMT Subject: RFR: 1191: CommitCommentWorkItem overwhelms scheduler Message-ID: Main goal if this patch is to fix the scheduling issue caused by CommitCommentsWorkItems::concurrentWith always returning true. To solve this a little nicer, I decided to expand on the idea I introduced a while back with PullRequest::isSame, and add the corresponding method to HostedRepository. This made implementing the ::concurrentWith methods cleaner IMO. In addition to this, I decided to add two new gauges to the metrics collection, which would have made it much easier to discover this issue if we already had them. These gauges report the number of active and pending WorkItems we have respectively in the BotRunner, summarized per WorkItem type using labels. To achieve this as nicely as I could, I refactored the BotRunner a little bit, moving all adds and removes for the active and pending maps to specific methods. ------------- Commit messages: - SKARA-1191 Changes: https://git.openjdk.java.net/skara/pull/1223/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1223&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1191 Stats: 78 lines in 6 files changed: 59 ins; 7 del; 12 mod Patch: https://git.openjdk.java.net/skara/pull/1223.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1223/head:pull/1223 PR: https://git.openjdk.java.net/skara/pull/1223 From kcr at openjdk.java.net Mon Sep 27 21:21:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 27 Sep 2021 21:21:14 GMT Subject: RFR: 1191: CommitCommentWorkItem overwhelms scheduler In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 20:35:13 GMT, Erik Joelsson wrote: > Main goal if this patch is to fix the scheduling issue caused by CommitCommentsWorkItems::concurrentWith always returning true. To solve this a little nicer, I decided to expand on the idea I introduced a while back with PullRequest::isSame, and add the corresponding method to HostedRepository. This made implementing the ::concurrentWith methods cleaner IMO. > > In addition to this, I decided to add two new gauges to the metrics collection, which would have made it much easier to discover this issue if we already had them. These gauges report the number of active and pending WorkItems we have respectively in the BotRunner, summarized per WorkItem type using labels. To achieve this as nicely as I could, I refactored the BotRunner a little bit, moving all adds and removes for the active and pending maps to specific methods. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1223 From erikj at openjdk.java.net Tue Sep 28 12:46:08 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 28 Sep 2021 12:46:08 GMT Subject: RFR: 1191: CommitCommentWorkItem overwhelms scheduler In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 20:35:13 GMT, Erik Joelsson wrote: > Main goal if this patch is to fix the scheduling issue caused by CommitCommentsWorkItems::concurrentWith always returning true. To solve this a little nicer, I decided to expand on the idea I introduced a while back with PullRequest::isSame, and add the corresponding method to HostedRepository. This made implementing the ::concurrentWith methods cleaner IMO. > > In addition to this, I decided to add two new gauges to the metrics collection, which would have made it much easier to discover this issue if we already had them. These gauges report the number of active and pending WorkItems we have respectively in the BotRunner, summarized per WorkItem type using labels. To achieve this as nicely as I could, I refactored the BotRunner a little bit, moving all adds and removes for the active and pending maps to specific methods. Thanks Kevin! ------------- PR: https://git.openjdk.java.net/skara/pull/1223 From erikj at openjdk.java.net Tue Sep 28 12:46:08 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 28 Sep 2021 12:46:08 GMT Subject: Integrated: 1191: CommitCommentWorkItem overwhelms scheduler In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 20:35:13 GMT, Erik Joelsson wrote: > Main goal if this patch is to fix the scheduling issue caused by CommitCommentsWorkItems::concurrentWith always returning true. To solve this a little nicer, I decided to expand on the idea I introduced a while back with PullRequest::isSame, and add the corresponding method to HostedRepository. This made implementing the ::concurrentWith methods cleaner IMO. > > In addition to this, I decided to add two new gauges to the metrics collection, which would have made it much easier to discover this issue if we already had them. These gauges report the number of active and pending WorkItems we have respectively in the BotRunner, summarized per WorkItem type using labels. To achieve this as nicely as I could, I refactored the BotRunner a little bit, moving all adds and removes for the active and pending maps to specific methods. This pull request has now been integrated. Changeset: 91be684a Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/91be684a5dec13840b9fba9d8dbb23c1a6dc0beb Stats: 78 lines in 6 files changed: 59 ins; 7 del; 12 mod 1191: CommitCommentWorkItem overwhelms scheduler Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1223 From shade at openjdk.java.net Tue Sep 28 14:08:12 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 28 Sep 2021 14:08:12 GMT Subject: RFR: SKARA-1194: Implement git webrev --no-comments option Message-ID: hg webrev had a `-C` / `--no-comments` option that skipped printing the comments for each file, i.e. commit messages. GitWebrev accepts the same option, but it does not seem to be implemented. Producing a webrev for a branch with a lot of commits looks badly then. For example, current report with `-C`: ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html 8065b5cc: 8270898: update panama_jextract.md and panama_jextract.html files bedc58a3: 8257892: long double not handled by jextract 2d966367: Consolidate all the various documents in the repository. 3dc23ea0: 8253419: jextract should generate RuntimeHelper as a package private class 52adf7f5: updating samples for CSupport->CLinker 33cba7a0: adding tensorflow sample 06675b1e: updating samples. changed constants class to use package constructor 6809ef51: Samples update after 8249879. Added opengl sample abb6e377: updating samples for recent MemoryAccess changes. ebba5406: 8248710: jextract should not generate Cstring, Cpointer, Cint C-X utility classes 45d41d75: * Fixed include path to be OS/SDK version independent ... 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg Fixed report with `-C`: ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg Additional testing: - [x] Eyeballing the reports with/without `-C` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/skara/pull/1224/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1224&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1194 Stats: 31 lines in 5 files changed: 15 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/skara/pull/1224.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1224/head:pull/1224 PR: https://git.openjdk.java.net/skara/pull/1224 From erikj at openjdk.java.net Tue Sep 28 16:07:15 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 28 Sep 2021 16:07:15 GMT Subject: RFR: SKARA-1194: Implement git webrev --no-comments option In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 14:03:23 GMT, Aleksey Shipilev wrote: > hg webrev had a `-C` / `--no-comments` option that skipped printing the comments for each file, i.e. commit messages. GitWebrev accepts the same option, but it does not seem to be implemented. Producing a webrev for a branch with a lot of commits looks badly then. > > For example, current report with `-C`: > > > ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html > > 8065b5cc: 8270898: update panama_jextract.md and panama_jextract.html files > bedc58a3: 8257892: long double not handled by jextract > 2d966367: Consolidate all the various documents in the repository. > 3dc23ea0: 8253419: jextract should generate RuntimeHelper as a package private class > 52adf7f5: updating samples for CSupport->CLinker > 33cba7a0: adding tensorflow sample > 06675b1e: updating samples. changed constants class to use package constructor > 6809ef51: Samples update after 8249879. Added opengl sample > abb6e377: updating samples for recent MemoryAccess changes. > ebba5406: 8248710: jextract should not generate Cstring, Cpointer, Cint C-X utility classes > 45d41d75: * Fixed include path to be OS/SDK version independent > ... > > 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg > > > Fixed report with `-C`: > > > ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html > > 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg > > > Additional testing: > - [x] Eyeballing the reports with/without `-C` It's unfortunate to have a field/variable with a negation in the name, but in this case it matches the argument so it could be ok. Maybe worth inverting the internal variable/field? What do you think? I'm approving this as it is if you don't want to. ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.java.net/skara/pull/1224 From shade at openjdk.java.net Wed Sep 29 05:54:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 29 Sep 2021 05:54:00 GMT Subject: RFR: SKARA-1194: Implement git webrev --no-comments option [v2] In-Reply-To: References: Message-ID: > hg webrev had a `-C` / `--no-comments` option that skipped printing the comments for each file, i.e. commit messages. GitWebrev accepts the same option, but it does not seem to be implemented. Producing a webrev for a branch with a lot of commits looks badly then. > > For example, current report with `-C`: > > > ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html > > 8065b5cc: 8270898: update panama_jextract.md and panama_jextract.html files > bedc58a3: 8257892: long double not handled by jextract > 2d966367: Consolidate all the various documents in the repository. > 3dc23ea0: 8253419: jextract should generate RuntimeHelper as a package private class > 52adf7f5: updating samples for CSupport->CLinker > 33cba7a0: adding tensorflow sample > 06675b1e: updating samples. changed constants class to use package constructor > 6809ef51: Samples update after 8249879. Added opengl sample > abb6e377: updating samples for recent MemoryAccess changes. > ebba5406: 8248710: jextract should not generate Cstring, Cpointer, Cint C-X utility classes > 45d41d75: * Fixed include path to be OS/SDK version independent > ... > > 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg > > > Fixed report with `-C`: > > > ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html > > 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg > > > Additional testing: > - [x] Eyeballing the reports with/without `-C` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into SKARA-1194-git-webrev-no-comments - Avoid negation in field names - Fix ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1224/files - new: https://git.openjdk.java.net/skara/pull/1224/files/88ccff0a..c5ea0f23 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1224&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1224&range=00-01 Stats: 84 lines in 8 files changed: 59 ins; 7 del; 18 mod Patch: https://git.openjdk.java.net/skara/pull/1224.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1224/head:pull/1224 PR: https://git.openjdk.java.net/skara/pull/1224 From shade at openjdk.java.net Wed Sep 29 05:54:01 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 29 Sep 2021 05:54:01 GMT Subject: RFR: SKARA-1194: Implement git webrev --no-comments option [v2] In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 16:04:37 GMT, Erik Joelsson wrote: > It's unfortunate to have a field/variable with a negation in the name, but in this case it matches the argument so it could be ok. Maybe worth inverting the internal variable/field? What do you think? I'm approving this as it is if you don't want to. OK, we can drop "no" from field names and negate it when reading from cli. See new commit. ------------- PR: https://git.openjdk.java.net/skara/pull/1224 From erikj at openjdk.java.net Wed Sep 29 13:04:20 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 29 Sep 2021 13:04:20 GMT Subject: RFR: SKARA-1194: Implement git webrev --no-comments option [v2] In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 05:54:00 GMT, Aleksey Shipilev wrote: >> hg webrev had a `-C` / `--no-comments` option that skipped printing the comments for each file, i.e. commit messages. GitWebrev accepts the same option, but it does not seem to be implemented. Producing a webrev for a branch with a lot of commits looks badly then. >> >> For example, current report with `-C`: >> >> >> ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html >> >> 8065b5cc: 8270898: update panama_jextract.md and panama_jextract.html files >> bedc58a3: 8257892: long double not handled by jextract >> 2d966367: Consolidate all the various documents in the repository. >> 3dc23ea0: 8253419: jextract should generate RuntimeHelper as a package private class >> 52adf7f5: updating samples for CSupport->CLinker >> 33cba7a0: adding tensorflow sample >> 06675b1e: updating samples. changed constants class to use package constructor >> 6809ef51: Samples update after 8249879. Added opengl sample >> abb6e377: updating samples for recent MemoryAccess changes. >> ebba5406: 8248710: jextract should not generate Cstring, Cpointer, Cint C-X utility classes >> 45d41d75: * Fixed include path to be OS/SDK version independent >> ... >> >> 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg >> >> >> Fixed report with `-C`: >> >> >> ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html >> >> 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg >> >> >> Additional testing: >> - [x] Eyeballing the reports with/without `-C` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into SKARA-1194-git-webrev-no-comments > - Avoid negation in field names > - Fix Looks good! Thanks for contributing to Skara! ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.java.net/skara/pull/1224 From shade at openjdk.java.net Wed Sep 29 15:06:36 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 29 Sep 2021 15:06:36 GMT Subject: RFR: SKARA-1194: Implement git webrev --no-comments option [v2] In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 05:54:00 GMT, Aleksey Shipilev wrote: >> hg webrev had a `-C` / `--no-comments` option that skipped printing the comments for each file, i.e. commit messages. GitWebrev accepts the same option, but it does not seem to be implemented. Producing a webrev for a branch with a lot of commits looks badly then. >> >> For example, current report with `-C`: >> >> >> ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html >> >> 8065b5cc: 8270898: update panama_jextract.md and panama_jextract.html files >> bedc58a3: 8257892: long double not handled by jextract >> 2d966367: Consolidate all the various documents in the repository. >> 3dc23ea0: 8253419: jextract should generate RuntimeHelper as a package private class >> 52adf7f5: updating samples for CSupport->CLinker >> 33cba7a0: adding tensorflow sample >> 06675b1e: updating samples. changed constants class to use package constructor >> 6809ef51: Samples update after 8249879. Added opengl sample >> abb6e377: updating samples for recent MemoryAccess changes. >> ebba5406: 8248710: jextract should not generate Cstring, Cpointer, Cint C-X utility classes >> 45d41d75: * Fixed include path to be OS/SDK version independent >> ... >> >> 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg >> >> >> Fixed report with `-C`: >> >> >> ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html >> >> 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg >> >> >> Additional testing: >> - [x] Eyeballing the reports with/without `-C` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into SKARA-1194-git-webrev-no-comments > - Avoid negation in field names > - Fix Thanks! ------------- PR: https://git.openjdk.java.net/skara/pull/1224 From ihse at openjdk.java.net Thu Sep 30 10:24:17 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 30 Sep 2021 10:24:17 GMT Subject: RFR: SKARA-1194: Implement git webrev --no-comments option [v2] In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 05:54:00 GMT, Aleksey Shipilev wrote: >> hg webrev had a `-C` / `--no-comments` option that skipped printing the comments for each file, i.e. commit messages. GitWebrev accepts the same option, but it does not seem to be implemented. Producing a webrev for a branch with a lot of commits looks badly then. >> >> For example, current report with `-C`: >> >> >> ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html >> >> 8065b5cc: 8270898: update panama_jextract.md and panama_jextract.html files >> bedc58a3: 8257892: long double not handled by jextract >> 2d966367: Consolidate all the various documents in the repository. >> 3dc23ea0: 8253419: jextract should generate RuntimeHelper as a package private class >> 52adf7f5: updating samples for CSupport->CLinker >> 33cba7a0: adding tensorflow sample >> 06675b1e: updating samples. changed constants class to use package constructor >> 6809ef51: Samples update after 8249879. Added opengl sample >> abb6e377: updating samples for recent MemoryAccess changes. >> ebba5406: 8248710: jextract should not generate Cstring, Cpointer, Cint C-X utility classes >> 45d41d75: * Fixed include path to be OS/SDK version independent >> ... >> >> 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg >> >> >> Fixed report with `-C`: >> >> >> ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html >> >> 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg >> >> >> Additional testing: >> - [x] Eyeballing the reports with/without `-C` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into SKARA-1194-git-webrev-no-comments > - Avoid negation in field names > - Fix Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1224 From shade at openjdk.java.net Thu Sep 30 10:24:17 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 30 Sep 2021 10:24:17 GMT Subject: Integrated: SKARA-1194: Implement git webrev --no-comments option In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 14:03:23 GMT, Aleksey Shipilev wrote: > hg webrev had a `-C` / `--no-comments` option that skipped printing the comments for each file, i.e. commit messages. GitWebrev accepts the same option, but it does not seem to be implemented. Producing a webrev for a branch with a lot of commits looks badly then. > > For example, current report with `-C`: > > > ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html > > 8065b5cc: 8270898: update panama_jextract.md and panama_jextract.html files > bedc58a3: 8257892: long double not handled by jextract > 2d966367: Consolidate all the various documents in the repository. > 3dc23ea0: 8253419: jextract should generate RuntimeHelper as a package private class > 52adf7f5: updating samples for CSupport->CLinker > 33cba7a0: adding tensorflow sample > 06675b1e: updating samples. changed constants class to use package constructor > 6809ef51: Samples update after 8249879. Added opengl sample > abb6e377: updating samples for recent MemoryAccess changes. > ebba5406: 8248710: jextract should not generate Cstring, Cpointer, Cint C-X utility classes > 45d41d75: * Fixed include path to be OS/SDK version independent > ... > > 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg > > > Fixed report with `-C`: > > > ------ ------ ------ ------ --- New Patch Raw doc/panama_jextract.html > > 992 lines changed; 992 ins; 0 del; 0 mod; 0 unchg > > > Additional testing: > - [x] Eyeballing the reports with/without `-C` This pull request has now been integrated. Changeset: 68872aa2 Author: Aleksey Shipilev Committer: Magnus Ihse Bursie URL: https://git.openjdk.java.net/skara/commit/68872aa293fc7ec21cfcd88a0b4fdd159e5546f8 Stats: 31 lines in 5 files changed: 15 ins; 0 del; 16 mod 1194: Implement git webrev --no-comments option Reviewed-by: erikj, ihse ------------- PR: https://git.openjdk.java.net/skara/pull/1224 From ihse at openjdk.java.net Thu Sep 30 10:29:00 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 30 Sep 2021 10:29:00 GMT Subject: RFR: 1079: Support ability to defer and delegate timing of an integration [v2] In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 22:07:28 GMT, Erik Joelsson wrote: >> Here is my first stab at implementing a way for a PR author to defer integration to another committer. The usecase for this is if the timing of the integration is important, but the author may not be available to issue the /integrate command at the desired time. >> >> Here is how it works: There are two new arguments to the /integrate command "defer" and "undefer". If the author of a PR issues "/integrate defer", the PR enters the deferred state (which is marked by the label "deferred"). This enables any committer to issue "/integrate" to actually perform the integration. When a PR is integrated by someone other than the author, then that person gets attributed in the Git committer field, just like when a change is sponsored. The author can revert this ability at any time before integration happens by issuing "/integrate undefer". >> >> This is similar to how sponsoring a change works, but not quite the same. When setting up for being sponsored, the /integrate command will run all the checks and record the specific hash that the author wishes to commit. I skipped this kind of rigorous book keeping here as I think it is more likely to get in the way in the desired usecase. The whole point is that timing is important and the author is not available, so better to leave things more open in my opinion. >> >> I'm open to informed suggestions on how this could potentially be improved on a conceptual level. >> >> When writing the test, I based it on the simpleMerge test already present. It took some work to properly understand what was happening in that test, and to make it clearer (at least to me), I have renamed and reorganized things a little bit. In these tests, the HostedRepository instances ("author", "integrator", "reviewer" etc) represent users and are used to create PR test instances (or views) which the test can use to interact with the PR as different users. To make this clearer, I introduced the botUser explicitly as that is also a user that sometimes issues commands and interacts with a PR, and used that for things that the bot is doing. I also changed some other users around so that they perform the role for which they are named (reviewer reviews, not the integrator). >> >> When composing the messages that the bot will print back in comments, I noticed that "PR" and "pull request" were used interchangeably. I decided to standardize on "pull request". > > Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: > > - Fix comment > - Adjusted for review comments Looks good. I think this fits well with the current model. I agree that we do not need to limit the set of eligible future integrators when deferring. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1221 From prappo at openjdk.java.net Thu Sep 30 10:34:59 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 30 Sep 2021 10:34:59 GMT Subject: RFR: 1197: Label changes from java.nio.** as nio Message-ID: Please review this PR which adds a mailing list rule for New I/O (NIO). The change was tested as per https://mail.openjdk.java.net/pipermail/jdk-dev/2020-August/004662.html ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/skara/pull/1225/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1225&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1197 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1225.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1225/head:pull/1225 PR: https://git.openjdk.java.net/skara/pull/1225 From ihse at openjdk.java.net Thu Sep 30 10:45:54 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 30 Sep 2021 10:45:54 GMT Subject: RFR: 1197: Label changes from java.nio.** as nio In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 10:31:18 GMT, Pavel Rappo wrote: > Please review this PR which adds a mailing list rule for New I/O (NIO). The change was tested as per https://mail.openjdk.java.net/pipermail/jdk-dev/2020-August/004662.html Looks good! ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1225 From prappo at openjdk.java.net Thu Sep 30 11:16:54 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 30 Sep 2021 11:16:54 GMT Subject: Integrated: 1197: Label changes from java.nio.** as nio In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 10:31:18 GMT, Pavel Rappo wrote: > Please review this PR which adds a mailing list rule for New I/O (NIO). The change was tested as per https://mail.openjdk.java.net/pipermail/jdk-dev/2020-August/004662.html This pull request has now been integrated. Changeset: acda2667 Author: Pavel Rappo Committer: Magnus Ihse Bursie URL: https://git.openjdk.java.net/skara/commit/acda266705b101b0905aa10de5f31670003ed2c4 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 1197: Label changes from java.nio.** as nio Reviewed-by: ihse ------------- PR: https://git.openjdk.java.net/skara/pull/1225 From ihse at openjdk.java.net Thu Sep 30 14:02:47 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 30 Sep 2021 14:02:47 GMT Subject: RFR: Improve "git sync" and "git fork" resilience Message-ID: The Skara CLI tools `git sync` and `git fork` are very much appreciated, but they are not fully designed to make sure you get the intended result. Part of this problem is that they are too general, and part is that they are too dumb. :-) These changes make sure that `git sync` always syncs between your personal fork, and the upstream repository (determined by the Git Forge provider as the "parent" repo you created your fork from), and `git fork` always sets up your repository for such `git sync` usage. If you really know what you are doing, you *can* still use `git sync` to sync between fully unrelated repos using the `--to` and `--from` arguments, but this is highly discouraged (and will require the `--force` flag as well, to be accepted). Before syncing, `git sync` will check that you have a proper `origin` and `upstream` remote configured, and that the upstream is consistent with what the Git Forge provider says. If the `upstream` remote is missing, it will be configured for you (unless `--no-remote` is given). `git fork` will now always set the `upstream` remote (unless given `--no-remote`). If these sounds like obvious behavior, it is worth noting what happened before. If `upstream` was missing, `git sync` had no idea what to do. `git fork` had a second, undocumented *) mode, in which you could run `git fork` without any arguments in a directory that already contained a checked out repo. That would create a personal fork of that repo on the Git Forge provider, but it would still keep `origin` as the upstream repo URI, and instead add a `fork` remote for the newly created personal fork. This mode of operation was barely supported (and broken) on `git sync`. The backwards way of naming the remotes could lead to no end of troubles. *) I say "undocumented" since there is no explicit documentation about this feature that I could found. However, the "upstream URI" argument to `git fork` is documented as "optional" (but all other documentation assumes that it is present, so the behavior when omitted is not specified). When implementing these fixes, it was clear that the code was in desperate need of a massive cleanup. There were dead code, code duplication, unclear logic, misleading names, etc... So in the end the code is so different from what I started from that a side-by-side comparison might be impossible. You can see individual changes in the separate commits, or you can review the new version of the files as were they new additions. These refactorings also uncovered a bug in `git fork`, where adding `--no-remote` would disable `--sync` and `--setup-pre-push-hooks`. I fixed that also. Unfortunately, we still don't have a testing story for our CLI tools. :-( I have however done extensive ad-hoc testing, with all possible combinations of flags, etc. ------------- Commit messages: - Improve verbose logging and normal output - Extracting all credential handlings into setupCredentials - Fix ssh vs https - -N does not match behavior in git fork; remove it - Refactorings and code improvements: - Rename for consistency - BUGFIX: Adding --no-remote would disable --sync and --setup-pre-push-hook - More readability refactoring - Restructure and extract to methods to increase readability - Remove support for undocumented mode of operation of "forking" into current directory with existing repo - ... and 16 more: https://git.openjdk.java.net/skara/compare/03e8d58d...255725ac Changes: https://git.openjdk.java.net/skara/pull/1226/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1226&range=00 Stats: 850 lines in 2 files changed: 386 ins; 222 del; 242 mod Patch: https://git.openjdk.java.net/skara/pull/1226.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1226/head:pull/1226 PR: https://git.openjdk.java.net/skara/pull/1226 From ihse at openjdk.java.net Thu Sep 30 14:11:44 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 30 Sep 2021 14:11:44 GMT Subject: RFR: Improve "git sync" and "git fork" resilience In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 13:57:52 GMT, Magnus Ihse Bursie wrote: > The Skara CLI tools `git sync` and `git fork` are very much appreciated, but they are not fully designed to make sure you get the intended result. Part of this problem is that they are too general, and part is that they are too dumb. :-) > > These changes make sure that `git sync` always syncs between your personal fork, and the upstream repository (determined by the Git Forge provider as the "parent" repo you created your fork from), and `git fork` always sets up your repository for such `git sync` usage. > > If you really know what you are doing, you *can* still use `git sync` to sync between fully unrelated repos using the `--to` and `--from` arguments, but this is highly discouraged (and will require the `--force` flag as well, to be accepted). > > Before syncing, `git sync` will check that you have a proper `origin` and `upstream` remote configured, and that the upstream is consistent with what the Git Forge provider says. If the `upstream` remote is missing, it will be configured for you (unless `--no-remote` is given). > > `git fork` will now always set the `upstream` remote (unless given `--no-remote`). > > If these sounds like obvious behavior, it is worth noting what happened before. If `upstream` was missing, `git sync` had no idea what to do. `git fork` had a second, undocumented *) mode, in which you could run `git fork` without any arguments in a directory that already contained a checked out repo. That would create a personal fork of that repo on the Git Forge provider, but it would still keep `origin` as the upstream repo URI, and instead add a `fork` remote for the newly created personal fork. This mode of operation was barely supported (and broken) on `git sync`. The backwards way of naming the remotes could lead to no end of troubles. > > *) I say "undocumented" since there is no explicit documentation about this feature that I could found. However, the "upstream URI" argument to `git fork` is documented as "optional" (but all other documentation assumes that it is present, so the behavior when omitted is not specified). > > When implementing these fixes, it was clear that the code was in desperate need of a massive cleanup. There were dead code, code duplication, unclear logic, misleading names, etc... So in the end the code is so different from what I started from that a side-by-side comparison might be impossible. You can see individual changes in the separate commits, or you can review the new version of the files as were they new additions. These refactorings also uncovered a bug in `git fork`, where adding `--no-remote` would disable `--sync` and `--setup-pre-push-hooks`. I fixed that also. > > Unfortunately, we still don't have a testing story for our CLI tools. :-( I have however done extensive ad-hoc testing, with all possible combinations of flags, etc. And oh, I added `--dry-run` to check behavior without doing any changes (mainly used it for my own debugging, but I think it can be useful in real-world scenarios as well), and improved `--verbose` logging. ------------- PR: https://git.openjdk.java.net/skara/pull/1226 From erikj at openjdk.java.net Thu Sep 30 18:36:44 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 30 Sep 2021 18:36:44 GMT Subject: RFR: Improve "git sync" and "git fork" resilience In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 13:57:52 GMT, Magnus Ihse Bursie wrote: > The Skara CLI tools `git sync` and `git fork` are very much appreciated, but they are not fully designed to make sure you get the intended result. Part of this problem is that they are too general, and part is that they are too dumb. :-) > > These changes make sure that `git sync` always syncs between your personal fork, and the upstream repository (determined by the Git Forge provider as the "parent" repo you created your fork from), and `git fork` always sets up your repository for such `git sync` usage. > > If you really know what you are doing, you *can* still use `git sync` to sync between fully unrelated repos using the `--to` and `--from` arguments, but this is highly discouraged (and will require the `--force` flag as well, to be accepted). > > Before syncing, `git sync` will check that you have a proper `origin` and `upstream` remote configured, and that the upstream is consistent with what the Git Forge provider says. If the `upstream` remote is missing, it will be configured for you (unless `--no-remote` is given). > > `git fork` will now always set the `upstream` remote (unless given `--no-remote`). > > If these sounds like obvious behavior, it is worth noting what happened before. If `upstream` was missing, `git sync` had no idea what to do. `git fork` had a second, undocumented *) mode, in which you could run `git fork` without any arguments in a directory that already contained a checked out repo. That would create a personal fork of that repo on the Git Forge provider, but it would still keep `origin` as the upstream repo URI, and instead add a `fork` remote for the newly created personal fork. This mode of operation was barely supported (and broken) on `git sync`. The backwards way of naming the remotes could lead to no end of troubles. > > *) I say "undocumented" since there is no explicit documentation about this feature that I could found. However, the "upstream URI" argument to `git fork` is documented as "optional" (but all other documentation assumes that it is present, so the behavior when omitted is not specified). > > When implementing these fixes, it was clear that the code was in desperate need of a massive cleanup. There were dead code, code duplication, unclear logic, misleading names, etc... So in the end the code is so different from what I started from that a side-by-side comparison might be impossible. You can see individual changes in the separate commits, or you can review the new version of the files as were they new additions. These refactorings also uncovered a bug in `git fork`, where adding `--no-remote` would disable `--sync` and `--setup-pre-push-hooks`. I fixed that also. > > Unfortunately, we still don't have a testing story for our CLI tools. :-( I have however done extensive ad-hoc testing, with all possible combinations of flags, etc. Looks good! I like the cleanups. ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.java.net/skara/pull/1226 From erikj at openjdk.java.net Thu Sep 30 19:01:40 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 30 Sep 2021 19:01:40 GMT Subject: Integrated: 1079: Support ability to defer and delegate timing of an integration In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 22:00:04 GMT, Erik Joelsson wrote: > Here is my first stab at implementing a way for a PR author to defer integration to another committer. The usecase for this is if the timing of the integration is important, but the author may not be available to issue the /integrate command at the desired time. > > Here is how it works: There are two new arguments to the /integrate command "defer" and "undefer". If the author of a PR issues "/integrate defer", the PR enters the deferred state (which is marked by the label "deferred"). This enables any committer to issue "/integrate" to actually perform the integration. When a PR is integrated by someone other than the author, then that person gets attributed in the Git committer field, just like when a change is sponsored. The author can revert this ability at any time before integration happens by issuing "/integrate undefer". > > This is similar to how sponsoring a change works, but not quite the same. When setting up for being sponsored, the /integrate command will run all the checks and record the specific hash that the author wishes to commit. I skipped this kind of rigorous book keeping here as I think it is more likely to get in the way in the desired usecase. The whole point is that timing is important and the author is not available, so better to leave things more open in my opinion. > > I'm open to informed suggestions on how this could potentially be improved on a conceptual level. > > When writing the test, I based it on the simpleMerge test already present. It took some work to properly understand what was happening in that test, and to make it clearer (at least to me), I have renamed and reorganized things a little bit. In these tests, the HostedRepository instances ("author", "integrator", "reviewer" etc) represent users and are used to create PR test instances (or views) which the test can use to interact with the PR as different users. To make this clearer, I introduced the botUser explicitly as that is also a user that sometimes issues commands and interacts with a PR, and used that for things that the bot is doing. I also changed some other users around so that they perform the role for which they are named (reviewer reviews, not the integrator). > > When composing the messages that the bot will print back in comments, I noticed that "PR" and "pull request" were used interchangeably. I decided to standardize on "pull request". This pull request has now been integrated. Changeset: 620f889d Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/620f889dfdc6d92ab5237be2088730c7012abed4 Stats: 223 lines in 5 files changed: 183 ins; 23 del; 17 mod 1079: Support ability to defer and delegate timing of an integration Reviewed-by: kcr, ihse ------------- PR: https://git.openjdk.java.net/skara/pull/1221 From kcr at openjdk.java.net Thu Sep 30 20:55:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 30 Sep 2021 20:55:09 GMT Subject: RFR: Improve "git sync" and "git fork" resilience In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 13:57:52 GMT, Magnus Ihse Bursie wrote: > The Skara CLI tools `git sync` and `git fork` are very much appreciated, but they are not fully designed to make sure you get the intended result. Part of this problem is that they are too general, and part is that they are too dumb. :-) > > These changes make sure that `git sync` always syncs between your personal fork, and the upstream repository (determined by the Git Forge provider as the "parent" repo you created your fork from), and `git fork` always sets up your repository for such `git sync` usage. > > If you really know what you are doing, you *can* still use `git sync` to sync between fully unrelated repos using the `--to` and `--from` arguments, but this is highly discouraged (and will require the `--force` flag as well, to be accepted). > > Before syncing, `git sync` will check that you have a proper `origin` and `upstream` remote configured, and that the upstream is consistent with what the Git Forge provider says. If the `upstream` remote is missing, it will be configured for you (unless `--no-remote` is given). > > `git fork` will now always set the `upstream` remote (unless given `--no-remote`). > > If these sounds like obvious behavior, it is worth noting what happened before. If `upstream` was missing, `git sync` had no idea what to do. `git fork` had a second, undocumented *) mode, in which you could run `git fork` without any arguments in a directory that already contained a checked out repo. That would create a personal fork of that repo on the Git Forge provider, but it would still keep `origin` as the upstream repo URI, and instead add a `fork` remote for the newly created personal fork. This mode of operation was barely supported (and broken) on `git sync`. The backwards way of naming the remotes could lead to no end of troubles. > > *) I say "undocumented" since there is no explicit documentation about this feature that I could found. However, the "upstream URI" argument to `git fork` is documented as "optional" (but all other documentation assumes that it is present, so the behavior when omitted is not specified). > > When implementing these fixes, it was clear that the code was in desperate need of a massive cleanup. There were dead code, code duplication, unclear logic, misleading names, etc... So in the end the code is so different from what I started from that a side-by-side comparison might be impossible. You can see individual changes in the separate commits, or you can review the new version of the files as were they new additions. These refactorings also uncovered a bug in `git fork`, where adding `--no-remote` would disable `--sync` and `--setup-pre-push-hooks`. I fixed that also. > > Unfortunately, we still don't have a testing story for our CLI tools. :-( I have however done extensive ad-hoc testing, with all possible combinations of flags, etc. Looks good to me, too. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1226 From erikj at openjdk.java.net Thu Sep 30 21:38:00 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 30 Sep 2021 21:38:00 GMT Subject: RFR: 1196: Add extension points on RestRequest to support more REST authorization methods Message-ID: This patch adds and extends some extension points in the RestRequest API. The immediate use of these extensions are being implemented in a custom extension to Skara. There are 3 main changes: 1. The optional lambda that handles authorization headers for a request now has access to the HttpRequest.Builder, so that it may inspect existing headers. This is causing a lot of small changes throughout the code base, just adding the new parameter to any lambda implementing the FunctionalInterface. 2. Adding a new optional field to the QueryBuilder, naming a header where a sha256 hash of the request body will be stored. Requiring such a hash seems common enough to have built in support for it in Skara, but the name of the header seems to differ between API providers. 3. Adding another optional lambda which can override how pagination is handled. This gets access to the HttpResponse to extract any necessary data to generate an HttpRequest.Builder for accessing the next page. ------------- Commit messages: - Make it possible to override logic for pagination next link - SKARA-1196 Changes: https://git.openjdk.java.net/skara/pull/1227/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1227&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1196 Stats: 91 lines in 11 files changed: 57 ins; 7 del; 27 mod Patch: https://git.openjdk.java.net/skara/pull/1227.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1227/head:pull/1227 PR: https://git.openjdk.java.net/skara/pull/1227 From kcr at openjdk.java.net Thu Sep 30 22:46:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 30 Sep 2021 22:46:31 GMT Subject: RFR: 1196: Add extension points on RestRequest to support more REST authorization methods In-Reply-To: References: Message-ID: <2EKYNdaQbDZVNBUoT4VfD4qbsuTjY1rygCIPDnd526U=.80cf8b36-3359-4b12-be3d-b6fce60bdc38@github.com> On Thu, 30 Sep 2021 21:34:30 GMT, Erik Joelsson wrote: > This patch adds and extends some extension points in the RestRequest API. The immediate use of these extensions are being implemented in a custom extension to Skara. There are 3 main changes: > > 1. The optional lambda that handles authorization headers for a request now has access to the HttpRequest.Builder, so that it may inspect existing headers. This is causing a lot of small changes throughout the code base, just adding the new parameter to any lambda implementing the FunctionalInterface. > 2. Adding a new optional field to the QueryBuilder, naming a header where a sha256 hash of the request body will be stored. Requiring such a hash seems common enough to have built in support for it in Skara, but the name of the header seems to differ between API providers. > 3. Adding another optional lambda which can override how pagination is handled. This gets access to the HttpResponse to extract any necessary data to generate an HttpRequest.Builder for accessing the next page. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1227 From erikj at openjdk.java.net Thu Sep 30 22:50:55 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 30 Sep 2021 22:50:55 GMT Subject: RFR: 1198: Stop using fake non existing from email addresses Message-ID: With this patch, Skara mlbridge will no longer construct fake email addresses for users not in the census. Instead mails will be sent with the configured do-not-reply address (which is currently duke at openjdk.java.net). The full name of the user will still be added, just like before, so it's still possible for a human to see who made the comment that triggered the email. Most of the changes are just adapting test cases that relied on this functionality. Those tests should still be valid as they are still verifying the full names correctly. ------------- Commit messages: - SKARA-1198 Changes: https://git.openjdk.java.net/skara/pull/1228/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1228&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1198 Stats: 22 lines in 2 files changed: 0 ins; 9 del; 13 mod Patch: https://git.openjdk.java.net/skara/pull/1228.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1228/head:pull/1228 PR: https://git.openjdk.java.net/skara/pull/1228 From kcr at openjdk.java.net Thu Sep 30 22:56:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 30 Sep 2021 22:56:06 GMT Subject: RFR: 1198: Stop using fake non existing from email addresses In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 22:47:28 GMT, Erik Joelsson wrote: > With this patch, Skara mlbridge will no longer construct fake email addresses for users not in the census. Instead mails will be sent with the configured do-not-reply address (which is currently duke at openjdk.java.net). The full name of the user will still be added, just like before, so it's still possible for a human to see who made the comment that triggered the email. > > Most of the changes are just adapting test cases that relied on this functionality. Those tests should still be valid as they are still verifying the full names correctly. Good cleanup. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1228