Re: [VOTE] Release Apache Sling Testing Clients 3.0.22
+1 On Mon, Jan 15, 2024 at 2:09 AM Andrei Dulvac wrote: > Hi, > > We solved 5 issues in this release: > https://issues.apache.org/jira/projects/SLING/versions/12353709 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2829/ > > You can use this UNIX script to download the release and verify the > signatures: > > https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh > > Usage: > sh check_staged_release.sh 2829 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > - Andrei >
Re: [PR] Various improvements for the webconsole plugin [sling-org-apache-sling-resourceresolver]
sonarcloud[bot] commented on PR #78: URL: https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/78#issuecomment-1896570829 ## [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-resourceresolver=78) **Quality Gate failed** Failed conditions [2.1% Coverage on New Code](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-resourceresolver=78=new_coverage=list) (required ≥ 80%) [See analysis details on SonarCloud](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-resourceresolver=78) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] SLING-11352 - Fix parsing of path-only mappings [sling-org-apache-sling-resourceresolver]
sonarcloud[bot] commented on PR #84: URL: https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/84#issuecomment-1896563047 ## [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-resourceresolver=84) **Quality Gate passed** Kudos, no new issues were introduced! [0 New issues](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-resourceresolver=84=false=true) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-resourceresolver=84=false=true) [100.0% Coverage on New Code](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-resourceresolver=84=new_coverage=list) [0.0% Duplication on New Code](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-resourceresolver=84=new_duplicated_lines_density=list) [See analysis details on SonarCloud](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-resourceresolver=84) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [VOTE] Release Apache Resource Resolver 1.11.6
On 17.01.2024 13:44, Bertrand Delacretaz wrote: [X ] +1 Approve the release Julian's signature 44F4797A52C336FA666CD9271DE461528F1F1B2A was missing from https://downloads.apache.org/sling/KEYS , I have added it [1] from [0], it should appear in a few minutes. ::: Ups. Thanks. Best regards, Julian
Re: [VOTE] Release Apache Resource Resolver 1.11.6
On Wed, 2024-01-17 at 07:51 +0100, Julian Reschke wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache Resource Resolver 1.11.6
[X ] +1 Approve the release Julian's signature 44F4797A52C336FA666CD9271DE461528F1F1B2A was missing from https://downloads.apache.org/sling/KEYS , I have added it [1] from [0], it should appear in a few minutes. -Bertrand [0] https://downloads.apache.org/jackrabbit/KEYS [1] FWIW, here's how to add a key svn co https://dist.apache.org/repos/dist/release/sling --depth empty cd sling svn up KEYS # edit KEYS as needed svn diff svn commit -m ...
Re: Order of steps in https://sling.apache.org/documentation/development/release-management.html
Sounds good, can you make a proposal in a PR for https://github.com/apache/sling-site/blob/master/src/main/jbake/content/documentation/development/release-management.md? Thanks, Konrad > On 17. Jan 2024, at 11:36, Julian Reschke > wrote: > > On 17.01.2024 11:14, Carsten Ziegeler wrote: >> I think there is no perfect solution. We are operating this way for many >> years :) which of course doesn't mean there is no room for improvement. >> >> I think the scenario you describe happened at least once. but it was >> detected when the version was released, the jira issue corrected and all >> was good. This requires a little care of the release manager. but it >> really is more a theoretical issue. We have all the notifications flying >> around and usually if you are working on something you know that there >> is a vote for it going on. >> >> The Oak way shows a version as released although it is not, and might >> never be - which at least in theory can create confusion to users. >> >> So I prefer potentially confused release managers over potentially >> confused users :) >> >> Regards >> Carsten > > > In that case how about adding some precise instructions to check > fixVersion consistency after the release? > > Best regards, Julian >
Re: Order of steps in https://sling.apache.org/documentation/development/release-management.html
On 17.01.2024 11:14, Carsten Ziegeler wrote: I think there is no perfect solution. We are operating this way for many years :) which of course doesn't mean there is no room for improvement. I think the scenario you describe happened at least once. but it was detected when the version was released, the jira issue corrected and all was good. This requires a little care of the release manager. but it really is more a theoretical issue. We have all the notifications flying around and usually if you are working on something you know that there is a vote for it going on. The Oak way shows a version as released although it is not, and might never be - which at least in theory can create confusion to users. So I prefer potentially confused release managers over potentially confused users :) Regards Carsten In that case how about adding some precise instructions to check fixVersion consistency after the release? Best regards, Julian
Re: Order of steps in https://sling.apache.org/documentation/development/release-management.html
I agree with Carsten here. I consider the outside view of JIRA being consistent more important here than to ease the work for committers in those hours while the release vote is ongoing (because every committer should be aware, at least theoretically). Konrad > On 17. Jan 2024, at 11:14, Carsten Ziegeler wrote: > > I think there is no perfect solution. We are operating this way for many > years :) which of course doesn't mean there is no room for improvement. > > I think the scenario you describe happened at least once. but it was detected > when the version was released, the jira issue corrected and all was good. > This requires a little care of the release manager. but it really is more a > theoretical issue. We have all the notifications flying around and usually if > you are working on something you know that there is a vote for it going on. > > The Oak way shows a version as released although it is not, and might never > be - which at least in theory can create confusion to users. > > So I prefer potentially confused release managers over potentially confused > users :) > > Regards > Carsten > > On 17.01.2024 11:02, Julian Reschke wrote: >> Hi there, >> the "Release Management" document suggests adding a new (next) release >> should happen after the release vote, and that the release being voted >> on remains "unreleased" in the meantime. >> Doesn't that leave us with a time windos of 72h+ hours in which issue >> tracking in Jira will be extremely ... awkward? What happens if somebody >> resolves an issue and enters the release currently under vote as >> "fixVersion"? >> (In Oak land, we do it the other way around; we create the "next" >> release first, and make the release being voted on as "released" when >> the vote starts). >> Best regards, Julian > > -- > Carsten Ziegeler > Adobe > cziege...@apache.org
Re: Order of steps in https://sling.apache.org/documentation/development/release-management.html
I think there is no perfect solution. We are operating this way for many years :) which of course doesn't mean there is no room for improvement. I think the scenario you describe happened at least once. but it was detected when the version was released, the jira issue corrected and all was good. This requires a little care of the release manager. but it really is more a theoretical issue. We have all the notifications flying around and usually if you are working on something you know that there is a vote for it going on. The Oak way shows a version as released although it is not, and might never be - which at least in theory can create confusion to users. So I prefer potentially confused release managers over potentially confused users :) Regards Carsten On 17.01.2024 11:02, Julian Reschke wrote: Hi there, the "Release Management" document suggests adding a new (next) release should happen after the release vote, and that the release being voted on remains "unreleased" in the meantime. Doesn't that leave us with a time windos of 72h+ hours in which issue tracking in Jira will be extremely ... awkward? What happens if somebody resolves an issue and enters the release currently under vote as "fixVersion"? (In Oak land, we do it the other way around; we create the "next" release first, and make the release being voted on as "released" when the vote starts). Best regards, Julian -- Carsten Ziegeler Adobe cziege...@apache.org
Order of steps in https://sling.apache.org/documentation/development/release-management.html
Hi there, the "Release Management" document suggests adding a new (next) release should happen after the release vote, and that the release being voted on remains "unreleased" in the meantime. Doesn't that leave us with a time windos of 72h+ hours in which issue tracking in Jira will be extremely ... awkward? What happens if somebody resolves an issue and enters the release currently under vote as "fixVersion"? (In Oak land, we do it the other way around; we create the "next" release first, and make the release being voted on as "released" when the vote starts). Best regards, Julian
