Re: [VOTE] Migrate all code remaining from ASF Subversion to GitHub
[x] +1 OK to move from ASF Subversion to GitHub On Fri, Jan 27, 2023 at 8:39 AM Peter Klügl wrote: > [x] +1 OK to move from ASF Subversion to GitHub > > Peter > > Am 27.01.2023 um 13:48 schrieb Richard Eckart de Castilho: > > Hi all, > > > > some time back, we have had some votes regarding moving individual > sub-projects of UIMA from Subversion to Git(Hub). > > I kind of ticked it off in my head that eventually we would move > everything over it being just a matter of time and > > resources to happen. In fact, in the mean time, I have moved various > parts of the code from subversion to GitHub such > > as the UIMA parent pom, build resources, etc. > > > > Today I found out that we have to projects on GitHub which we have no > write access to because they are still configured > > as mirrors of our subversion: > > > > * https://github.com/apache/uima-sandbox > > * https://github.com/apache/uima-ducc > > > > While at least DUCC has already had its vote to be retired, I would > prefer it being retired on Git than on Subversion. > > > > So I asked INFRA if they could switch those repos properly over to git. > They in turn asked for a discussion on our list. > > I actually thought we already had a general vote to move code over to > Git(Hub), but searching in the archives, I did not > > find one (only for individual sub-projects). > > > > So... tl;dr: I propose that we move any and all code of the Apache UIMA > project from subversion to Git(Hub). > > > > This will not happen immediately, but whenever I need to reference a > discussion to go ahead, this vote would be it. > > > > Note that per ASF policy, the project's GitHub repositories are mirrored > at the ASF using the ASF gitbox service: > > > >https://gitbox.apache.org/repos/asf > > > > So even when we use the repos on GitHub as the canonical point of > contact, ASF always keeps the official records. > > > > [ ] +1 OK to release > > [ ] 0 Don't care > > [ ] -1 Not OK to release, because ... > > > > The vote will remain open for at least 72h - please vote! > > > > Cheers, > > > > -- Richard > > > -- > Dr. Peter Klügl > Head of Text Mining/Machine Learning > > Averbis GmbH > Salzstr. 15 > 79098 Freiburg > Germany > > Fon: +49 761 708 394 0 > Fax: +49 761 708 394 10 > Email: peter.klu...@averbis.com > Web: https://averbis.com > > Headquarters: Freiburg im Breisgau > Register Court: Amtsgericht Freiburg im Breisgau, HRB 701080 > Managing Directors: Dr. med. Philipp Daumke, Dr. Kornél Markó > >
[jira] [Resolved] (UIMA-4089) make xml comparisons in test cases use xml unit
[ https://issues.apache.org/jira/browse/UIMA-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho resolved UIMA-4089. -- Assignee: (was: Marshall Schor) Resolution: Done Over time, we actually have migrated various tests over to XMLUnit. > make xml comparisons in test cases use xml unit > --- > > Key: UIMA-4089 > URL: https://issues.apache.org/jira/browse/UIMA-4089 > Project: UIMA > Issue Type: Test > Components: Core Java Framework >Affects Versions: 2.6.0SDK >Reporter: Marshall Schor >Priority: Minor > > Saw some errors being reported by Jenkins due to different styles of xml end > tags being compared for string equal. Use XML Unit to avoid these being > considered as errors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (UIMA-2546) Add author extraction service
[ https://issues.apache.org/jira/browse/UIMA-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho resolved UIMA-2546. -- Resolution: Abandoned Issue has received no attention over the last years - closing. > Add author extraction service > - > > Key: UIMA-2546 > URL: https://issues.apache.org/jira/browse/UIMA-2546 > Project: UIMA > Issue Type: Improvement > Components: addons >Affects Versions: 2.3.1Addons >Reporter: Tommaso Teofili >Priority: Major > > Add the 'author extraction service' (see > http://www.alchemyapi.com/api/author/) to AlchemyAPI Annotator. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (UIMA-1290) Need a Way to Determine if Two Type Systems Are Compatible
[
https://issues.apache.org/jira/browse/UIMA-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho resolved UIMA-1290.
--
Resolution: Not A Problem
Seems like the need for this has disappeared. That said, actually the core UIMA
Java SDK has an internal functionality to de-duplicate type systems to reduce
memory usage. Cf. system property {{uima.disable_typesystem_consolidation}}.
This functionality works by comparing type systems as to whether they are
identical. As far as I can tell, this is simply implemented through
{{TypeSystemImpl.equals(other)}}.
> Need a Way to Determine if Two Type Systems Are Compatible
> --
>
> Key: UIMA-1290
> URL: https://issues.apache.org/jira/browse/UIMA-1290
> Project: UIMA
> Issue Type: New Feature
> Components: Core Java Framework
>Affects Versions: 2.3
>Reporter: Jaroslaw Cwiklik
>Priority: Major
>
> Uima AS client needs to validate that the type system returned from a Uima AS
> service is compatible. In case when a binary serialization is used, the type
> systems *must* be identical. For XMI serialization, the type system of the
> delegate*must* be compatible but not necessarily identical. The core should
> provide an API which will enable the validation of type systems.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (UIMA-2546) Add author extraction service
[ https://issues.apache.org/jira/browse/UIMA-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho updated UIMA-2546: - Fix Version/s: (was: 2.4.0Addons) > Add author extraction service > - > > Key: UIMA-2546 > URL: https://issues.apache.org/jira/browse/UIMA-2546 > Project: UIMA > Issue Type: Improvement > Components: addons >Affects Versions: 2.3.1Addons >Reporter: Tommaso Teofili >Priority: Major > > Add the 'author extraction service' (see > http://www.alchemyapi.com/api/author/) to AlchemyAPI Annotator. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (UIMA-3004) Investigate memory consumption of TextRuler framework
[ https://issues.apache.org/jira/browse/UIMA-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Klügl closed UIMA-3004. - Resolution: Won't Fix > Investigate memory consumption of TextRuler framework > - > > Key: UIMA-3004 > URL: https://issues.apache.org/jira/browse/UIMA-3004 > Project: UIMA > Issue Type: Task > Components: Ruta >Affects Versions: 2.1.0ruta >Reporter: Peter Klügl >Assignee: Peter Klügl >Priority: Major > > Investigate memory consumption of TextRuler framework: Some rule induction > algorithms did not finish in a normal learning setting (java heap space). A > first simple profiling pointed to the maps in RutaBasic, which used about 1GB. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (UIMA-3132) uimaFIT maven plugins do not run on ASF Jenkins slave "windows1"
[
https://issues.apache.org/jira/browse/UIMA-3132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho resolved UIMA-3132.
--
Resolution: Works for Me
Never ran into this issue again...
> uimaFIT maven plugins do not run on ASF Jenkins slave "windows1"
>
>
> Key: UIMA-3132
> URL: https://issues.apache.org/jira/browse/UIMA-3132
> Project: UIMA
> Issue Type: Bug
> Components: uimaFIT-Maven-Plugin
>Affects Versions: 2.0.0uimaFIT
>Reporter: Richard Eckart de Castilho
>Assignee: Richard Eckart de Castilho
>Priority: Major
>
> Getting this error:
> {noformat}
> Caused by: java.lang.IllegalStateException: ${maven.home} is not specified as
> a directory: 'F:\hudson\tools\maven\latest3'.
> at
> org.apache.maven.shared.invoker.MavenCommandLineBuilder.findMavenExecutable(MavenCommandLineBuilder.java:475)
> at
> org.apache.maven.shared.invoker.MavenCommandLineBuilder.build(MavenCommandLineBuilder.java:68)
> at
> org.apache.maven.shared.invoker.DefaultInvoker.execute(DefaultInvoker.java:91)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1493)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1214)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuilds(AbstractInvokerMojo.java:1133)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.execute(AbstractInvokerMojo.java:670)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (UIMA-3004) Investigate memory consumption of TextRuler framework
[ https://issues.apache.org/jira/browse/UIMA-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681333#comment-17681333 ] Richard Eckart de Castilho commented on UIMA-3004: -- [~pkluegl] Can we close this one? The issue does not really describe how to reproduce the problem (e.g. which rule induction algorithms need to be investigated) and the issue didn't draw any more attention the last like 10 years... > Investigate memory consumption of TextRuler framework > - > > Key: UIMA-3004 > URL: https://issues.apache.org/jira/browse/UIMA-3004 > Project: UIMA > Issue Type: Task > Components: Ruta >Affects Versions: 2.1.0ruta >Reporter: Peter Klügl >Assignee: Peter Klügl >Priority: Major > > Investigate memory consumption of TextRuler framework: Some rule induction > algorithms did not finish in a normal learning setting (java heap space). A > first simple profiling pointed to the maps in RutaBasic, which used about 1GB. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (UIMA-5520) Fix docs for job descriptor overrides
[ https://issues.apache.org/jira/browse/UIMA-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho resolved UIMA-5520. -- Resolution: Abandoned DUCC is being retired. > Fix docs for job descriptor overrides > - > > Key: UIMA-5520 > URL: https://issues.apache.org/jira/browse/UIMA-5520 > Project: UIMA > Issue Type: Bug >Reporter: Rong Li >Priority: Major > > Overrides are blank not comma separated -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [VOTE] Migrate all code remaining from ASF Subversion to GitHub
[x] +1 OK to move from ASF Subversion to GitHub Peter Am 27.01.2023 um 13:48 schrieb Richard Eckart de Castilho: Hi all, some time back, we have had some votes regarding moving individual sub-projects of UIMA from Subversion to Git(Hub). I kind of ticked it off in my head that eventually we would move everything over it being just a matter of time and resources to happen. In fact, in the mean time, I have moved various parts of the code from subversion to GitHub such as the UIMA parent pom, build resources, etc. Today I found out that we have to projects on GitHub which we have no write access to because they are still configured as mirrors of our subversion: * https://github.com/apache/uima-sandbox * https://github.com/apache/uima-ducc While at least DUCC has already had its vote to be retired, I would prefer it being retired on Git than on Subversion. So I asked INFRA if they could switch those repos properly over to git. They in turn asked for a discussion on our list. I actually thought we already had a general vote to move code over to Git(Hub), but searching in the archives, I did not find one (only for individual sub-projects). So... tl;dr: I propose that we move any and all code of the Apache UIMA project from subversion to Git(Hub). This will not happen immediately, but whenever I need to reference a discussion to go ahead, this vote would be it. Note that per ASF policy, the project's GitHub repositories are mirrored at the ASF using the ASF gitbox service: https://gitbox.apache.org/repos/asf So even when we use the repos on GitHub as the canonical point of contact, ASF always keeps the official records. [ ] +1 OK to release [ ] 0 Don't care [ ] -1 Not OK to release, because ... The vote will remain open for at least 72h - please vote! Cheers, -- Richard -- Dr. Peter Klügl Head of Text Mining/Machine Learning Averbis GmbH Salzstr. 15 79098 Freiburg Germany Fon: +49 761 708 394 0 Fax: +49 761 708 394 10 Email: peter.klu...@averbis.com Web: https://averbis.com Headquarters: Freiburg im Breisgau Register Court: Amtsgericht Freiburg im Breisgau, HRB 701080 Managing Directors: Dr. med. Philipp Daumke, Dr. Kornél Markó
[jira] [Resolved] (UIMA-5900) SM should delay starting custom service pingers
[ https://issues.apache.org/jira/browse/UIMA-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho resolved UIMA-5900. -- Resolution: Abandoned DUCC is being retired. > SM should delay starting custom service pingers > --- > > Key: UIMA-5900 > URL: https://issues.apache.org/jira/browse/UIMA-5900 > Project: UIMA > Issue Type: Bug > Components: DUCC >Affects Versions: 2.2.2-Ducc >Reporter: Eddie Epstein >Priority: Major > > in v2.2.2 custom services can connect to the agent and report states = > initializing and running. This may take several seconds after the service > instance is started. Currently the SM starts a custom service pinger as soon > as it is notified that the first instance is started. A delay is needed to > detect that the instance has reported itself as initializing in which case > the pinger should not be started until an instance reports itself running. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (UIMA-5862) RM can fail with a comparator violating its general contract
[ https://issues.apache.org/jira/browse/UIMA-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho resolved UIMA-5862. -- Resolution: Abandoned DUCC is being retired. > RM can fail with a comparator violating its general contract > > > Key: UIMA-5862 > URL: https://issues.apache.org/jira/browse/UIMA-5862 > Project: UIMA > Issue Type: Bug > Components: DUCC >Reporter: Burn L. Lewis >Priority: Major > > Problem is JobByTimeSorter in NodepoolScheduler -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (UIMA-6114) Add the experiments page code
[ https://issues.apache.org/jira/browse/UIMA-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho resolved UIMA-6114. -- Resolution: Abandoned DUCC is being retired. > Add the experiments page code > - > > Key: UIMA-6114 > URL: https://issues.apache.org/jira/browse/UIMA-6114 > Project: UIMA > Issue Type: Improvement > Components: DUCC >Reporter: Burn L. Lewis >Assignee: Burn L. Lewis >Priority: Major > > Adds the Experiments button ... could be made optional. > Code checks if each Job or AP is a child of an experiment ... will display an > empty page if none found. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (UIMA-6201) Analysis engine Enhancement
[ https://issues.apache.org/jira/browse/UIMA-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho resolved UIMA-6201. -- Assignee: Richard Eckart de Castilho Resolution: Information Provided > Analysis engine Enhancement > --- > > Key: UIMA-6201 > URL: https://issues.apache.org/jira/browse/UIMA-6201 > Project: UIMA > Issue Type: Question > Components: UIMA >Reporter: dhinesh >Assignee: Richard Eckart de Castilho >Priority: Major > > Hi Friends, > can any one suggest me how to filter specific class annotations from the > chunk of annotations. > For Example > I am getting output as > org.apache.ctakes.typesystem.type.syntax.PRT > org.apache.ctakes.typesystem.type.syntax.PP > org.apache.ctakes.typesystem.type.OntologyConcept > etc > I need output only as > org.apache.ctakes.typesystem.type.OntologyConcept > Where do I restrict for my specific class annotations in analysis engine. > Thanks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (UIMA-6442) Avoid artifactory.openntf.org being used outside Eclipse modules
[ https://issues.apache.org/jira/browse/UIMA-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho resolved UIMA-6442. -- Resolution: Not A Problem This being a problem was just a hypothesis. Recently, I did not notice slowness due to openntf, so I'm closing this. If necessary, re-open on GitHub. > Avoid artifactory.openntf.org being used outside Eclipse modules > > > Key: UIMA-6442 > URL: https://issues.apache.org/jira/browse/UIMA-6442 > Project: UIMA > Issue Type: Improvement > Components: Build, Packaging and Test >Reporter: Richard Eckart de Castilho >Assignee: Richard Eckart de Castilho >Priority: Major > > Avoid artifactory.openntf.org being used outside Eclipse modules - this could > speed up the build and the P2 repos are not needed outside the Eclipse > modules. Either move to an intermediate parent pom or move into a profile. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (UIMA-6442) Avoid artifactory.openntf.org being used outside Eclipse modules
[ https://issues.apache.org/jira/browse/UIMA-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho updated UIMA-6442: - Fix Version/s: (was: 3.4.1SDK) > Avoid artifactory.openntf.org being used outside Eclipse modules > > > Key: UIMA-6442 > URL: https://issues.apache.org/jira/browse/UIMA-6442 > Project: UIMA > Issue Type: Improvement > Components: Build, Packaging and Test >Reporter: Richard Eckart de Castilho >Assignee: Richard Eckart de Castilho >Priority: Major > > Avoid artifactory.openntf.org being used outside Eclipse modules - this could > speed up the build and the P2 repos are not needed outside the Eclipse > modules. Either move to an intermediate parent pom or move into a profile. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (UIMA-4563) Traffic monitoring using Google Analytics
[ https://issues.apache.org/jira/browse/UIMA-4563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho resolved UIMA-4563. -- Resolution: Done > Traffic monitoring using Google Analytics > - > > Key: UIMA-4563 > URL: https://issues.apache.org/jira/browse/UIMA-4563 > Project: UIMA > Issue Type: Improvement > Components: Website >Reporter: Richard Eckart de Castilho >Priority: Major > > Apparently, the ASF main page uses Google Analytics now as well, so I think > we can also do that - they have privacy statement that we can simply reuse. > http://www.apache.org/foundation/policies/privacy.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (UIMA-6335) Optimize release process
[
https://issues.apache.org/jira/browse/UIMA-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho resolved UIMA-6335.
--
Resolution: Done
Most points have been addressed. If the remaining open points remain pain
points, open new issues for them on the GitHub issue tracker.
> Optimize release process
>
>
> Key: UIMA-6335
> URL: https://issues.apache.org/jira/browse/UIMA-6335
> Project: UIMA
> Issue Type: Improvement
>Reporter: Richard Eckart de Castilho
>Assignee: Richard Eckart de Castilho
>Priority: Major
>
> The release checklist is pretty long. To facilitate releases, we should see
> what can be optimized / cut.
> - (/) {{README.md}} becomes version-independent and contains a proper project
> description suitable as a GitHub repo landing page
> - (/) {{RELEASE_NOTES.md}} contains only version-specific release notes and
> can be largely copy/pasted to the release announcments mail/website/etc.
> - (/) [uimaFIT] Drop the binary release package of uimaFIT - the source
> release and obtaining the artifacts via Maven Central should be sufficient
> (UIMA-6448)
> - (/) [UIMAJ] Integrate building of Eclipse update sites into the build
> (UIMA-6443)
> - (/) [RUTA] Integrate building of Eclipse update sites into the build (part
> of UIMA-6447)
> - (/) [UIMAJ] Use RC-auto-staging from Parent POM 15
> - (/) [uimaFIT] Use RC-auto-staging from Parent POM 15
> - (/) [RUTA] Use RC-auto-staging from Parent POM 15
> - (x) [UIMAJ] Put the examples in the UIMA Java SDK into a form where they
> are convenient to use form the source distribution or find some other way of
> providing them which does not require binary release package. In particular,
> they should not be Eclipse projects but rather regular Maven projects
> - (x) [UIMAJ] Drop the binary release package of UIMA Java SDK - the source
> release and obtaining the artifacts via Maven Central should be sufficient -
> will safe us from having to maintain the LICENSE/NOTICE files for binary
> releases
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (UIMA-6428) cas.select(TOP.class).count() has unexpected result
[ https://issues.apache.org/jira/browse/UIMA-6428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho resolved UIMA-6428. -- Fix Version/s: (was: 3.4.1SDK) Resolution: Duplicate > cas.select(TOP.class).count() has unexpected result > --- > > Key: UIMA-6428 > URL: https://issues.apache.org/jira/browse/UIMA-6428 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Richard Eckart de Castilho >Priority: Major > > Calling cas.select(TOP.class).count() returns a very large long number - > probably Long.MAX_VALUE. It is a bit unexpected... To get an accurate number, > one has to call cas.select(TOP.class).asList().size(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (UIMA-6428) cas.select(TOP.class).count() has unexpected result
[ https://issues.apache.org/jira/browse/UIMA-6428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681321#comment-17681321 ] Richard Eckart de Castilho commented on UIMA-6428: -- Issue has moved here and has been resolved: https://github.com/apache/uima-uimaj/issues/272 > cas.select(TOP.class).count() has unexpected result > --- > > Key: UIMA-6428 > URL: https://issues.apache.org/jira/browse/UIMA-6428 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Richard Eckart de Castilho >Priority: Major > Fix For: 3.4.1SDK > > > Calling cas.select(TOP.class).count() returns a very large long number - > probably Long.MAX_VALUE. It is a bit unexpected... To get an accurate number, > one has to call cas.select(TOP.class).asList().size(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
Invitation to vote on UIMA Java SDK 3.4.0 release candidate(s) - anybody can do it!
Hi everybody, a vote for a release candidate of the UIMA Java SDK has been started on the developers mailing list: https://lists.apache.org/thread/vdpgxdymso9mbph68qj44zjdzvthc60f NOTE: that post also includes a list of changes in the upcoming release, so check it out! Anybody can test the release candidate and vote on it! While only PMC members have a binding vote of which we need at least 3 to make a release, anybody can download the release candidate and test their own projects against it. Testing your own projects against new release candidates is a good idea because doing releases is taking some effort and if your setup has a problem with the release candidate, it would be useful to know it so that the issue can be fixed before the final release. You testing upcoming releases is a useful contribution to quality testing! Some tips on voting can be found in our new maintainers guide: https://nightlies.apache.org/uima/draft-guides/uima-doc-v3-maintainers-guide/version_3_maintainers_guide.html#_voting Note that the items listed under "Voting" can be expanded by clicking on the black triangle at the start of the line! Release votes remain open at least 72h and until at least 3 PMC members have cast their vote. So if you want to make absolutely sure your voice is heard before the release candidate is promoted, best try to weigh in within 72h of the voting process being started. But usually it takes way longer until 3 PMC members have finally cast their vote, so do not stress yourself :) It would be great if you (unbindingly) voted, in particular if you are not a PMC member or committer! Cheers, -- Richard (PMC Chair of the Apache UIMA project)
Re: [VOTE] Migrate all code remaining from ASF Subversion to GitHub
Hi, [x] +1 OK to move from ASF Subversion to GitHub Best, Viorel On Fri, Jan 27, 2023 at 1:50 PM Richard Eckart de Castilho wrote: > Sorry, I copy-pasted the voting template from an RC vote :) here a better > one: > > [ ] +1 OK to move from ASF Subversion to GitHub > [ ] 0 Don't care > [ ] -1 Not OK to move from ASF Subversion to GitHub, because ... > > Cheers, > > -- Richard > > > On 27. Jan 2023, at 13:48, Richard Eckart de Castilho > wrote: > > > > Hi all, > > > > some time back, we have had some votes regarding moving individual > sub-projects of UIMA from Subversion to Git(Hub). > > I kind of ticked it off in my head that eventually we would move > everything over it being just a matter of time and > > resources to happen. In fact, in the mean time, I have moved various > parts of the code from subversion to GitHub such > > as the UIMA parent pom, build resources, etc. > > > > Today I found out that we have to projects on GitHub which we have no > write access to because they are still configured > > as mirrors of our subversion: > > > > * https://github.com/apache/uima-sandbox > > * https://github.com/apache/uima-ducc > > > > While at least DUCC has already had its vote to be retired, I would > prefer it being retired on Git than on Subversion. > > > > So I asked INFRA if they could switch those repos properly over to git. > They in turn asked for a discussion on our list. > > I actually thought we already had a general vote to move code over to > Git(Hub), but searching in the archives, I did not > > find one (only for individual sub-projects). > > > > So... tl;dr: I propose that we move any and all code of the Apache UIMA > project from subversion to Git(Hub). > > > > This will not happen immediately, but whenever I need to reference a > discussion to go ahead, this vote would be it. > > > > Note that per ASF policy, the project's GitHub repositories are mirrored > at the ASF using the ASF gitbox service: > > > > https://gitbox.apache.org/repos/asf > > > > So even when we use the repos on GitHub as the canonical point of > contact, ASF always keeps the official records. > > > > [ ] +1 OK to release > > [ ] 0 Don't care > > [ ] -1 Not OK to release, because ... > > > > The vote will remain open for at least 72h - please vote! > > > > Cheers, > > > > -- Richard > > > >
Re: [VOTE] Migrate all code remaining from ASF Subversion to GitHub
Also, for reference, here is the INFRA ticket related to this vote: https://issues.apache.org/jira/browse/INFRA-24143 Cheers, -- Richard
Re: [VOTE] Migrate all code remaining from ASF Subversion to GitHub
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [X] +1 OK to move from ASF Subversion to GitHub Let's make the move. - -- Richard -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEPY2MKJLmMo4NDQCrO8wPPFbjAA4FAmPTyKxfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNE OEQ4QzI4OTJFNjMyOEUwRDBEMDBBQjNCQ0MwRjNDNTZFMzAwMEUACgkQO8wPPFbj AA43tQ//XflXZ5HezVfiimCMTrEXSXR/cGoE0LPQh2OV8br52cln4PVogA95E3CV AwmnLDQZgJcIDIEKZXFBWdLTeWTuTg0KZlDwfbGOQmCEAPGat7K6kzAA3f31pk5f 9rJ6pW7ctm3VzozU3BmL0nc7lOmamdw2nXkowy1mwVlXXnb3+UVXmB/O2Zj+XNTr Yt+/Lw61xD4y8KuyRczfsLIPG2AnluAp+u5XnF/gdgNPYyKIUXQBHItTJSHTSuTU VbMuyikiS6Evld/AkXtF/qacq2fLdHgoQkzcg2NacHbC/SsKSz9q+OIqC7lQ2CA3 rm4HAqFbkjBT8I62r2F1xpVJJV6tCOz6lX91FRt0HOZWqu0BOMPkkXsEV6hrHZms Y2nXdjmcrcqUXcDt8ttisG9POJ+tHcYha39hdzHKFU7W85M5RzwKLkUq67CfLlq5 iTbCsAnNwcznSFcHaakSjk9tgjD6gedi2XAutVGmAxvifk82ovZoaEb9ZeitPXuY injYiF107tuu2nOv3CGXW8CGq8wYtwoiNxPFeVhLgNWFbm0vC89F6vZA0xEj97wP OmpnyduhCOoh7pG2E66/uUnvQgWD6XIeExWl+U/t5O/OgHUvyFZ1pz+wWqdndhnF z8/gkwb8Kmx0xz97s4BaOGD78Dg19BPu6lufUwH5HEhDz3XF1OM= =EmLa -END PGP SIGNATURE-
Re: [VOTE] Migrate all code remaining from ASF Subversion to GitHub
Sorry, I copy-pasted the voting template from an RC vote :) here a better one: [ ] +1 OK to move from ASF Subversion to GitHub [ ] 0 Don't care [ ] -1 Not OK to move from ASF Subversion to GitHub, because ... Cheers, -- Richard > On 27. Jan 2023, at 13:48, Richard Eckart de Castilho wrote: > > Hi all, > > some time back, we have had some votes regarding moving individual > sub-projects of UIMA from Subversion to Git(Hub). > I kind of ticked it off in my head that eventually we would move everything > over it being just a matter of time and > resources to happen. In fact, in the mean time, I have moved various parts of > the code from subversion to GitHub such > as the UIMA parent pom, build resources, etc. > > Today I found out that we have to projects on GitHub which we have no write > access to because they are still configured > as mirrors of our subversion: > > * https://github.com/apache/uima-sandbox > * https://github.com/apache/uima-ducc > > While at least DUCC has already had its vote to be retired, I would prefer it > being retired on Git than on Subversion. > > So I asked INFRA if they could switch those repos properly over to git. They > in turn asked for a discussion on our list. > I actually thought we already had a general vote to move code over to > Git(Hub), but searching in the archives, I did not > find one (only for individual sub-projects). > > So... tl;dr: I propose that we move any and all code of the Apache UIMA > project from subversion to Git(Hub). > > This will not happen immediately, but whenever I need to reference a > discussion to go ahead, this vote would be it. > > Note that per ASF policy, the project's GitHub repositories are mirrored at > the ASF using the ASF gitbox service: > > https://gitbox.apache.org/repos/asf > > So even when we use the repos on GitHub as the canonical point of contact, > ASF always keeps the official records. > > [ ] +1 OK to release > [ ] 0 Don't care > [ ] -1 Not OK to release, because ... > > The vote will remain open for at least 72h - please vote! > > Cheers, > > -- Richard >
[VOTE] Migrate all code remaining from ASF Subversion to GitHub
Hi all, some time back, we have had some votes regarding moving individual sub-projects of UIMA from Subversion to Git(Hub). I kind of ticked it off in my head that eventually we would move everything over it being just a matter of time and resources to happen. In fact, in the mean time, I have moved various parts of the code from subversion to GitHub such as the UIMA parent pom, build resources, etc. Today I found out that we have to projects on GitHub which we have no write access to because they are still configured as mirrors of our subversion: * https://github.com/apache/uima-sandbox * https://github.com/apache/uima-ducc While at least DUCC has already had its vote to be retired, I would prefer it being retired on Git than on Subversion. So I asked INFRA if they could switch those repos properly over to git. They in turn asked for a discussion on our list. I actually thought we already had a general vote to move code over to Git(Hub), but searching in the archives, I did not find one (only for individual sub-projects). So... tl;dr: I propose that we move any and all code of the Apache UIMA project from subversion to Git(Hub). This will not happen immediately, but whenever I need to reference a discussion to go ahead, this vote would be it. Note that per ASF policy, the project's GitHub repositories are mirrored at the ASF using the ASF gitbox service: https://gitbox.apache.org/repos/asf So even when we use the repos on GitHub as the canonical point of contact, ASF always keeps the official records. [ ] +1 OK to release [ ] 0 Don't care [ ] -1 Not OK to release, because ... The vote will remain open for at least 72h - please vote! Cheers, -- Richard
Requested delete or archive https://github.com/apache/uima-as_old
Hi all, I have opened an issue with INFRA to delete or archive https://github.com/apache/uima-as_old https://issues.apache.org/jira/browse/INFRA-24142 This repository seems to be an old duplicate of https://github.com/apache/uima-async-scaleout (which itself is pending archival, but I did not yet request it). Cheers, -- Richard
